Kernel patches to support direct load of bzImage under Xen - Debian

This is a discussion on Kernel patches to support direct load of bzImage under Xen - Debian ; Hi, I'd like to enquire about the possibility of the patches filed in #473645 being applied to the Debian kernel packages. The bug report was closed and had the patch tag removed. However I think this was a misunderstanding since ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Kernel patches to support direct load of bzImage under Xen

  1. Kernel patches to support direct load of bzImage under Xen

    Hi,

    I'd like to enquire about the possibility of the patches filed in
    #473645 being applied to the Debian kernel packages.

    The bug report was closed and had the patch tag removed. However I think
    this was a misunderstanding since one the patches ("v2.08") directly
    addresses the issue which Bastian cited, he said:
    Because of several shortcommings in the maintainer scripts and
    the image loader, this currently needs an extra image, which is
    built.

    The v2.08 patch eliminates the need special image in domU by allowing
    the image loader to load the bzImage file directly. Together with the
    "enable-xen" patch and the Xen patches in #474509 it is possible to boot
    any of the kernels from the regular (i.e. non-xen) packages in a Xen
    guest domain (subject to compatibility with the hypervisor).

    The v2.08 patch has been applied upstream [0,1&2] and will be in the
    2.6.26-rc1. Is there any reason not to apply a backport to the 2.6.25
    kernel? Having these patches applied to the kernel would be a big step
    forward in my project of making the Debian installer fully
    usable/compatible with paravirtualised guests as originally discussed at
    [3].

    I'm not sure what the shortcomings of the maintainer scripts that
    Bastian also refers too are since the packages work fine for me in domU
    (note that dom0 is still a special case). There is a bug in update-grub
    WRT handing pvops kernels which I am investigating separately. If there
    are any other known issues me I'm more than happy to work on resolving
    them if they are brought to my attention.

    The third patch in the ticket
    xen-modules-autoprobing-support-for-frontend-drivers.patch is queued up
    in the x86 tree but isn't in mainline yet[4]. Compared with the other
    patches it's just a "nice to have" patch since it stops d-i from needing
    to prompt separately for the Xen frontend drivers to find network and
    disks.

    Thanks,
    Ian.

    [0] http://git.kernel.org/?p=linux/kerne...001988e5bcaa9c
    [1] http://git.kernel.org/?p=linux/kerne...3fdf7d417b448c
    [2] http://git.kernel.org/?p=linux/kerne...fb52a47d72df64
    [3] http://lists.debian.org/debian-boot/.../msg00269.html
    [4] http://git.kernel.org/?p=linux/kerne...63d7b4990904bf
    --
    Ian Campbell

    BOFH excuse #144:

    Too few computrons available.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIDmEIM0+0qS9rzVkRAt1gAJ4jO8wCCv60UC99RrLpCd CCQCatBACg12WS
    tDFmCdrNrwiAXe6OR/bd/RM=
    =7l2b
    -----END PGP SIGNATURE-----


  2. Re: Kernel patches to support direct load of bzImage under Xen

    On Tue, 22 Apr 2008, Ian Campbell wrote:

    > The v2.08 patch has been applied upstream [0,1&2] and will be in the
    > 2.6.26-rc1. Is there any reason not to apply a backport to the 2.6.25
    > kernel? Having these patches applied to the kernel would be a big step
    > forward in my project of making the Debian installer fully
    > usable/compatible with paravirtualised guests as originally discussed at
    > [3].


    i'd see tomorrow if the patch is easily appliable to 2.6.25,
    anyway shouldn't be a show stopper for Lenny as applied upstream.

    the trouble i remember is that we still can't disable the separate Xen
    images due to X86_PAE, which is not wanted in the generic 686.

    > I'm not sure what the shortcomings of the maintainer scripts that
    > Bastian also refers too are since the packages work fine for me in domU
    > (note that dom0 is still a special case). There is a bug in update-grub
    > WRT handing pvops kernels which I am investigating separately. If there
    > are any other known issues me I'm more than happy to work on resolving
    > them if they are brought to my attention.


    how far is the 2.6.26 domU amd64 support?

    > The third patch in the ticket
    > xen-modules-autoprobing-support-for-frontend-drivers.patch is queued up
    > in the x86 tree but isn't in mainline yet[4]. Compared with the other
    > patches it's just a "nice to have" patch since it stops d-i from needing
    > to prompt separately for the Xen frontend drivers to find network and
    > disks.


    ack i'll see also if that one applies fine.

    thanks

    --
    maks


    --
    To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Kernel patches to support direct load of bzImage under Xen

    (dropping Bastian from CC since the original was just a courtesy copy
    and I doubt he wants CC'ing on list traffic per normal Debian
    etiquette).

    On Wed, 2008-04-23 at 01:45 +0200, maximilian attems wrote:
    > On Tue, 22 Apr 2008, Ian Campbell wrote:
    >
    > > The v2.08 patch has been applied upstream [0,1&2] and will be in the
    > > 2.6.26-rc1. Is there any reason not to apply a backport to the 2.6.25
    > > kernel? Having these patches applied to the kernel would be a big step
    > > forward in my project of making the Debian installer fully
    > > usable/compatible with paravirtualised guests as originally discussed at
    > > [3].

    >
    > i'd see tomorrow if the patch is easily appliable to 2.6.25,
    > anyway shouldn't be a show stopper for Lenny as applied upstream.
    >
    > the trouble i remember is that we still can't disable the separate Xen
    > images due to X86_PAE, which is not wanted in the generic 686.


    In practise it is the 686-bigmem package which you are likely to want
    for Xen usage since that has PAE enabled.

    However I think we might as well just enable CONFIG_XEN in all packages
    which have CONFIG_PARAVIRT enabled, people with non-PAE hypervisors do
    exist e.g. none of the BSD ports support PAE IIRC, and there's no
    benefit to shutting them out of running Debian as a guest.

    For the time being the separate Xen images are still useful for dom0
    since (last I heard) some of those patches are currently damaging to the
    native mode of the pvops stuff.

    >
    > > I'm not sure what the shortcomings of the maintainer scripts that
    > > Bastian also refers too are since the packages work fine for me in domU
    > > (note that dom0 is still a special case). There is a bug in update-grub
    > > WRT handing pvops kernels which I am investigating separately. If there
    > > are any other known issues me I'm more than happy to work on resolving
    > > them if they are brought to my attention.

    >
    > how far is the 2.6.26 domU amd64 support?


    Last status update I saw was
    http://marc.info/?l=xen-devel&m=120783897830044&w=2 (and some other
    little bits in that thread)

    Looks like Fedora has mostly working with a few known issues but I don't
    think any patches have been put forward for 2.6.26 yet.

    I can have a look at extracting a patch from one of Red Hat's trees if
    you would like.

    >
    > > The third patch in the ticket
    > > xen-modules-autoprobing-support-for-frontend-drivers.patch is queued up
    > > in the x86 tree but isn't in mainline yet[4]. Compared with the other
    > > patches it's just a "nice to have" patch since it stops d-i from needing
    > > to prompt separately for the Xen frontend drivers to find network and
    > > disks.

    >
    > ack i'll see also if that one applies fine.


    Thanks very much,

    Ian.
    --
    Ian Campbell

    I smell like a wet reducing clinic on Columbus Day!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIDuJcM0+0qS9rzVkRAjjEAJ9ZdxneK11w1P9C0oOhIc nfeu1/FgCgp1B4
    f6l9x9pRdPjkwR47eEt7xwM=
    =mSof
    -----END PGP SIGNATURE-----


+ Reply to Thread