Xen 2.6.25 dom0 kernel ebuild

[GD]

Hello... I'm also getting errors compiling xen-sources-2.6.30-r2:

Code: Select all

  LD      drivers/xen/evtchn/built-in.o
  LD      drivers/xen/gntdev/built-in.o
  CC [M]  drivers/xen/gntdev/gntdev.o
  CC      drivers/xen/netback/netback.o
  CC      drivers/xen/netback/xenbus.o
  CC      drivers/xen/netback/interface.o
drivers/xen/netback/interface.c: In function 'netif_alloc':
drivers/xen/netback/interface.c:212: error: 'struct net_device' has no member named 'hard_start_xmit'
drivers/xen/netback/interface.c:213: error: 'struct net_device' has no member named 'get_stats'
drivers/xen/netback/interface.c:214: error: 'struct net_device' has no member named 'open'
drivers/xen/netback/interface.c:215: error: 'struct net_device' has no member named 'stop'
drivers/xen/netback/interface.c:216: error: 'struct net_device' has no member named 'change_mtu'
make[3]: *** [drivers/xen/netback/interface.o] Error 1
make[2]: *** [drivers/xen/netback] Error 2
make[1]: *** [drivers/xen] Error 2
make: *** [drivers] Error 2

Is this the same as the one mentioned above?
Any chances we get an ebuild for 2.6.31-rc5? Thanks

[_Razorblade_]

If I remember correctly you have to enable
CONFIG_COMPAT_NET_DEV_OPS=y
to get this to compile. Nevertheless I havent' got this kernel booting on any of my system at all...

[GD]

thanks it compiled fine...

i get error: invalid magic number though immediately after selecting the kernel in grub

[GD]

Having made the list of patches I have a script which extracts the vanilla kernel source and attempts to apply the patches, when it fails it stops and drops to bash so that I can fix the problem manually, to give you an idea of the changes here is the diff output between the original and my updated patches:
Andy

can you post that script you're using so i can see whether i can get some patches to apply too?

thanks...

[andylyon]

Having made the list of patches I have a script which extracts the vanilla kernel source and attempts to apply the patches, when it fails it stops and drops to bash so that I can fix the problem manually, to give you an idea of the changes here is the diff output between the original and my updated patches:
Andy

can you post that script you're using so i can see whether i can get some patches to apply too?

thanks...

The script I use is only useful in my development environment so I am not going to post it, but I will explain the process you need to follow:

First you need to unpack the suse rpm, I usually convert it using rpm2targz then extract the contents, then there is a script you can run which will output the list of patches that would be applied by the rpm build process, it takes the architecture as an argument (x86_64 or i386/i686) and you need to pipe in the series.conf which lists all patches, then just grep for patches.xen , e.g.:

ubermicro suse-kernel-source-2.6.30-55.1 # ./guards x86_64 <series.conf | grep patches.xen

patches.xen/add-console-use-vt
patches.xen/linux-2.6.19-rc1-kexec-move_segment_code-i386.patch
patches.xen/linux-2.6.19-rc1-kexec-move_segment_code-x86_64.patch
patches.xen/ipv6-no-autoconf
patches.xen/pci-guestdev
patches.xen/pci-reserve
patches.xen/sfc-driverlink
patches.xen/sfc-resource-driver
patches.xen/sfc-driverlink-conditional
patches.xen/sfc-external-sram
patches.xen/tmem
patches.xen/xen3-auto-xen-arch.diff
patches.xen/xen3-auto-xen-drivers.diff
patches.xen/xen3-auto-include-xen-interface.diff
patches.xen/xen3-auto-xen-kconfig.diff
patches.xen/xen3-auto-common.diff
patches.xen/xen3-auto-arch-x86.diff

<snip>


Some of the patches are required only if the kernel has already been patched, I use the following command to identify them:

grep "Automatically created from" patches.xen/* | grep -v "kernel.org"

patches.xen/xen3-driver-core-misc-add-nodename-support-for-misc-devices.patch:Automatically created from "patches.suse/driver-core-misc-add-nodename-support-for-misc-devices.patch" by xen-port-patches.py
patches.xen/xen3-kdb-x86:Automatically created from "patches.suse/kdb-x86" by xen-port-patches.py
patches.xen/xen3-panic-on-io-nmi.diff:Automatically created from "patches.suse/panic-on-io-nmi.diff" by xen-port-patches.py
patches.xen/xen3-seccomp-disable-tsc-option:Automatically created from "patches.fixes/seccomp-disable-tsc-option" by xen-port-patches.py
patches.xen/xen3-stack-unwind:Automatically created from "patches.suse/stack-unwind" by xen-port-patches.py
patches.xen/xen3-x86-mark_rodata_rw.patch:Automatically created from "patches.suse/x86-mark_rodata_rw.patch" by xen-port-patches.py
patches.xen/xen3-x86_64-unwind-annotations:Automatically created from "patches.arch/x86_64-unwind-annotations" by xen-port-patches.py


Unless you plan to include the other suse patches you should not try to apply these, having removed them I review the list and read the top of each patch to understand what it does, FYI my current list of patches to exclude for 2.6.30 is:


#patches.xen/xen3-seccomp-disable-tsc-option
#patches.xen/xen3-driver-core-misc-add-nodename-support-for-misc-devices.patch
#patches.xen/xen3-kdb-x86
#patches.xen/xen3-stack-unwind
#patches.xen/xen3-panic-on-io-nmi.diff
#patches.xen/xen3-x86_64-unwind-annotations
#patches.xen/xen-modular-blktap
#patches.xen/xen-blkback-bimodal-suse
#patches.xen/xen-blkif-protocol-fallback-hack
#patches.xen/xen-swiotlb-heuristics


Having trimmed the list it is simply a matter of applying the patches in order, some will fail but the changes required to fix are usually quite minor.

Good luck, if you have any luck with 2.6.31-rc5 please do post your results and I will upload the ebuild to the usual place, I will also try to find time to have a look at 2.6.31-rc5 myself this week.

Andy

[GD]

Hello all

I think I sort of made it. Most of the patches apply fine. Those that don't only need minor changes. However, even though I edited opensuse's patches whenever it was evident what changes should be made, the patches would still fail to apply properly (I have no idea why). I ended up editing kernel sources manually copying and pasting from the .rej files. I managed to get the kernel to compile (2.6.31-rc5-git3), configured for a dom0 instance.

However, I still get the same error after selecting the newly xen-enabled kernel in grub: invalid magic number.

After googling around a bit, I came across a forum post (http://www.mail-archive.com/grub-devel@ ... 05538.html) where it is mentioned that "multiboot" should be used instead of "linux" when booting a dom0 image in grub2. I tried that too, but then I get a different error: "multiboot header not found". Any ideas on where to go from here?

Thanks

[andylyon]

Hello all

I think I sort of made it. Most of the patches apply fine. Those that don't only need minor changes. However, even though I edited opensuse's patches whenever it was evident what changes should be made, the patches would still fail to apply properly (I have no idea why). I ended up editing kernel sources manually copying and pasting from the .rej files. I managed to get the kernel to compile (2.6.31-rc5-git3), configured for a dom0 instance.

However, I still get the same error after selecting the newly xen-enabled kernel in grub: invalid magic number.

After googling around a bit, I came across a forum post (http://www.mail-archive.com/grub-devel@ ... 05538.html) where it is mentioned that "multiboot" should be used instead of "linux" when booting a dom0 image in grub2. I tried that too, but then I get a different error: "multiboot header not found". Any ideas on where to go from here?

Thanks

When you say fail, what error did you get? if it was malformed patch then you need to edit the patch header, if you read up on the patch/diff format you should be able to figure it out.

invalid magic number.. what does this return: file <kernel>, e.g. file /boot/vmlinuz-2.6.29-xen-r4

/boot/vmlinuz-2.6.29-xen-r4: gzip compressed data, from Unix, last modified: Tue Jul 28 12:10:04 2009, max compression


Andy

[GD]

When you say fail, what error did you get? if it was malformed patch then you need to edit the patch header, if you read up on the patch/diff format you should be able to figure it out.

invalid magic number.. what does this return: file <kernel>, e.g. file /boot/vmlinuz-2.6.29-xen-r4

/boot/vmlinuz-2.6.29-xen-r4: gzip compressed data, from Unix, last modified: Tue Jul 28 12:10:04 2009, max compression


Andy

I get errors like "1 out of 4 HUNKS failed" and here is an example from a .rej file:

Code: Select all

***************
*** 388,393 ****
  config X86_TSC
         def_bool y
         depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2 || MATOM) && !X86_NUMAQ) || X86_64

  config X86_CMPXCHG64
         def_bool y
--- 388,394 ----
  config X86_TSC
         def_bool y
         depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2 || MATOM) && !X86_NUMAQ) || X86_64
+       depends on !XEN

  config X86_CMPXCHG64
         def_bool y[/quote]

Anyway I finally overcame the grub2 problem. It seems the proper syntax for xen dom0 when booting via grub2 is:

Code: Select all

menuentry "Gentoo Linux - Xen" {
    set root=(hd0,1)
    multiboot /xen-3.4.1.gz dom0_mem=1024M
    module /kernel-2.6.31-xen root=/dev/sda2
}

Dom0 is up now... Let's see if I can manage to boot a guest OS

[Chuck Dand]

Just noticed that on http://code.google.com/p/gentoo-xen-ker ... loads/list the 2.6.30 patches/ebuild are marked very obviously as buggy, I've got a test machine running this right now and in the process of building another. Can I ask why they've been marked as buggy? I've not had any problems with them, scanned through this thread and couldn't see anything mentioning this version in particular.

Kind regards.

--
Chuck Dand

[trikolon]

On the Xen Users Mailinglist are a lot o people having problems with version 30. in my personal case, as long as i use it with amd64 30 is working without any problems. on x86 i get a lot of errors, even kernel panics with this version. so andy mentioned somewhere that he would suggest using version 29 because it is working much more stable.

ben

[Chuck Dand]

as long as i use it with amd64 30 is working without any problems.

That's what I've been using it on so I guess that's why I've not been having any problems.

Just for my own peace of mind, when using a kernel built from these 2.6.30 sources I'm getting the following notices on bootup.

"platform microcode: firmware: requesting amd-ucode/microcode_amd.bin"

I'm presuming this isn't specifically related to the patches that andylyon has applied but can anyone advise me as to how to get this sorted? The suggestions I've seen recommend putting a file obtained from http://www.amd64.org/support/microcode.html in /etc/firmware or /lib/firmware but despite where I've put it, still no success. I guess what I'd like to know is that this modified kernel source isn't looking anywhere strange or if this is something that isn't working in this kernel source?

Kind regards.

--
Chuck

[_Razorblade_]

Even in dom0 you only have access to a vcpu, so I think you cannot use microcode updates from dom0. So if you want to get rid of the error message unselect the kernel option for microcode updates.

[_Razorblade_]

Anyway I finally overcame the grub2 problem. It seems the proper syntax for xen dom0 when booting via grub2 is:

Code: Select all

menuentry "Gentoo Linux - Xen" {
    set root=(hd0,1)
    multiboot /xen-3.4.1.gz dom0_mem=1024M
    module /kernel-2.6.31-xen root=/dev/sda2
}

Dom0 is up now... Let's see if I can manage to boot a guest OS

Does this actually work for you? I also started to fiddle around with grub2 and found that the root= statement on a module line is not being passed through (in this case to the linux kernel) while using multiboot. Have you embedded the path to the root filesystem or did you patch grub2?

Razor

[GD]

Does this actually work for you? I also started to fiddle around with grub2 and found that the root= statement on a module line is not being passed through (in this case to the linux kernel) while using multiboot. Have you embedded the path to the root filesystem or did you patch grub2?

Razor

Well it seems to be working although i'm not really sure what the symptoms would be if it weren't... I haven't patched grub or anything although I am using a live ebuild for it...
What do you mean by embedding the path to the root filesystem? Is there such an option in the kernel config?

[xpetex]

hi,

the current pvops tree runs fine on my machines...i will provide daily tarballs for the lazy ones...

http://x17.eu/xen/
http://x17.eu/xen/linux-2.6.31_pvops-xe ... 20.tar.bz2
http://x17.eu/xen/linux-2.6.31_pvops-xe ... ar.bz2.md5

repo is:
http://git.kernel.org/?p=linux/kernel/g ... ;a=summary

-
xpetex

[trikolon]

hi, great work!
do you know when will pci passthrough will be available on the pv_ops kernel?

greets ben

[microcosm]

as long as i use it with amd64 30 is working without any problems.

That's what I've been using it on so I guess that's why I've not been having any problems.

Just for my own peace of mind, when using a kernel built from these 2.6.30 sources I'm getting the following notices on bootup.

"platform microcode: firmware: requesting amd-ucode/microcode_amd.bin"

I'm presuming this isn't specifically related to the patches that andylyon has applied but can anyone advise me as to how to get this sorted? The suggestions I've seen recommend putting a file obtained from http://www.amd64.org/support/microcode.html in /etc/firmware or /lib/firmware but despite where I've put it, still no success. I guess what I'd like to know is that this modified kernel source isn't looking anywhere strange or if this is something that isn't working in this kernel source?

I suggest you visit the following link

http://en.gentoo-wiki.com/wiki/Intel_Microcode

and that you set the microcode as a module, otherwise it will bug you every startup. (That's what it did for me)

/Mikael

[Floppe]

Hi!

I've some issues with xen-sources-2.6.29-r4. I've been running with this version for many months now with no problems until now.

I did install a mail server as domU a couple a weeks ago and it seems like Courier-IMAP goes into a horror loop making duplicates of emails when someone copies a large set (about 10 or more) of emails between folders. I tested the 2.6.18 kernel and everything works great so it seems to be related to the kernel version. I do not want to run 2.6.18 as it's very old.

Any ideas or new releases I can test?

Config file at http://pastebin.ca/1541318

EDIT: Courier-IMAP works if I disable custom keywords when using newer xen kernels, wonder why.

// Floppe

[Nossie]

Can someone tell me what pvops stands for, and how is a pvops xen kernel different from a normal xen kernel?

thanks.

[Scorpion265]

Can someone tell me what pvops stands for, and how is a pvops xen kernel different from a normal xen kernel?

thanks.

Quote from here

pv_ops itself is a set of hooks in the kernel so that support for running on different hypervisors can be cleanly added to the kernel, with the added bonus that the kernel can detect at runtime which hypervisor it is running on and adapt itself accordingly. This means that, in the long run, Xen support should be more akin to a device driver than a huge fork of the kernel.

[gaima]

Hey guys,

Does anyone happen to have the latest 2.6.27 Xen patches lying around?
I got 2.6.27-1 from rapidshare, and after a minor change of one hunk of fs/aio.c it applied and built. But I've seen reference to 2.6.27-4 that was posted to the google code repository, which isn't available anymore.
Basically a Xen patched 2.6.29 isn't buildable by gcc 3.4.6 (the stable version available to hardened) due to some asm stuff I don't even vaguely understand, so I need to stick with something slightly older.

Thanks
Mike

[trikolon]

one way would be to download the latest kernel sources incl patches from here http://download.opensuse.org/repositori ... _11.1/src/ and extract them as andy mentioned in this post...

[vr13]

hi,

i'm trying to migrate existing xen gentoo installation to rebased 2.6.29-xen. dom0 seems to work: at least for two weeks the server using xen 3.4.1 and 2.6.29-r4-xen0 works stable. at this time it runs 2 heavily loaded PV domains and 1 win hvm domain with PV drivers (used mostly for fun)

existing domUs were built using sys-kernel/xen-sourses-2.6.21 (from portage). when starting freshly built domU kernlel built using 2.6.29-xen it crashes immediately
here is domU conlose output: http://pastebin.com/m7263b966
this is domU kernel config: http://pastebin.com/d281b7705

any ideas how to make it working?

* update: solved with deconfiguration of HIGHPTE parameter. domU has started up and seems to work. anyway there are number of issues with domU. and a question remains:

has anyone succeded with self-created 2.6.29 domU?

[andylyon]

I have uploaded 2.6.31 patches and ebuild to http://code.google.com/p/gentoo-xen-ker ... loads/list

Very few changes were required and opensuse will be using 2.6.31 as a distro release kernel , so this version should work well and be supported for longer than the other versions.

Tested on x86_64 as dom0 and domU, hvm guest also tested but no 32 bit testing done yet.

Good luck .

Andy

[2bbionic]

Hi,

ich just tried the new patchset on a 32bit-system with i686-pc-linux-gnu-3.4.6. The following error occurs:

Code: Select all

 CC [M]  arch/x86/kernel/microcode_core.o
arch/x86/kernel/microcode_core-xen.c: In function `microcode_write':
arch/x86/kernel/microcode_core-xen.c:100: Fehler: »totalram_pages« nicht deklariert (erste Benutzung in dieser Funktion)
arch/x86/kernel/microcode_core-xen.c:100: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
arch/x86/kernel/microcode_core-xen.c:100: Fehler: für jede Funktion in der er auftritt.)
make[2]: *** [arch/x86/kernel/microcode_core.o] Fehler 1
make[1]: *** [arch/x86/kernel] Fehler 2
make: *** [arch/x86] Fehler 2

Deactivating the microcode update helped to compile successfully. It seem's there's missed something....

2bbionic

EDIT: Booting the kernel end to a kernel panic in smp-related stuff...