[lkml]   [2007]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
    Eric W. Biederman wrote:
    >> I think I'd prefer to have the domain builder decompress/relocate the
    >> kernel from the bzImage and start it directly, rather than have it
    >> decompress/relocate itself, but I'm not really set on that.
    > We can change a lot more implementation details arbitrarily if you don't
    > know what needs to happen for decompression and relocation.

    Yes, and if it can be made to work, it ultimately means less work for me ;)

    > We have to avoid the writes decompressor-prinnt routines

    At worst, we could set up chunk of memory as a dummy framebuffer. That
    might be useful for debugging anyway.

    > and
    > possibly the reload of the segment registers. But otherwise
    > we should be fine. I don't see any other privileged instructions
    > in arch/i386/boot/compressed/{head.S, misc.c}

    Xen will start the domain with a GDT loaded, and all the segment
    registers loaded with flat segments. I guess boot/compressed/head.S
    could do the %cs ring check before deciding to do privileged operations.

    I presume bzImage jumps straight to startup_32 on the newly decompressed

    >> It depends
    >> on how well it can deal with having paging enabled and being in ring 1.
    >> Looks like it might just be a matter of starting up with "enough" memory
    >> mapped.
    > Yes. I think so. There is an additional issue of exactly how do we
    > get the fixmap region allocated so we can use it but that is minor.

    I haven't checked if it already has this, but it would be nice if the
    bzImage had a memory range/list of memory ranges it needs mapped to get
    the kernel on its feet, so that the domain builder can just go and map
    those areas for it (either P==V mappings, or with a constant offset;
    whichever is more useful).

    Also, if its a PAE kernel, Xen will start with PAE mode enabled, so
    bzImage will have to deal with that. But if its not touching
    pagetables, it won't matter.

    > What I really want to do is go back to sticking an ELF header on the
    > bzImage. We still can't support multiple entry points that way but we
    > can include ELF notes fairly easily.

    That's OK. We'll be able to use the boot info to go into the
    Xen-specific path shortly after startup_32 anyway.

    BTW, the test for a non-ring 0 %cs won't always be a good test for
    paravirtualization; we're likely to start seeing hybrid execution models
    where we run a largely paravirtualized kernel in a SVM/VT container. If
    we can just unconditionally use the bootloader arch definition to
    determine the entry path into the kernel, it will clean things up nicely.

    > It looks like for the next version of booting lguest and Xen are
    > actually coming closer together again. Yea.
    > For boot protocol. 2.0.7 We currently need a subarchitecture field (16bits?).
    > default == 0, Xen, lguest, voyager?, visws?, numaq?, efi?
    > We need a subarchitecture data pointer field (32bits).

    Do we want to support starting a 64-bit guest in 64-bit mode?

    > We need to target .23 because it is to late for .22.

    Yes. I'll need to do a moderate amount of work on the Xen side to make
    this work, I think.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-01 00:45    [W:0.023 / U:15.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site