lkml.org 
[lkml]   [2012]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot
    From
    On 10/07/2012 19:09, "Olaf Hering" <olaf@aepfle.de> wrote:

    >>> Are there more shared areas or is it just the shared info page?
    >>>
    >>>> And I am kind of worried that moving it to the .data section won't
    >>>> be completly safe - as the decompressor might blow away that part too.
    >>>
    >>> The decompressor may just clear the area, but since there is no way to
    >>> tell where the shared pages are its always a risk to allocate them at
    >>> compile time.
    >>
    >> Yeah, and with the hypervisor potentially still updating the "old"
    >> MFN before the new kernel has registered the new MFN, we can end up
    >> corrupting the new kernel. Ouch.
    >>
    >> Would all of these issues disappear if the hypervisor had a hypercall
    >> that would stop updating the shared info? or just deregister the MFN?
    >> What if you ripped the GMFN out using 'decrease_reservation' hypercall?
    >> Would that eliminate the pesky GMFN?
    >
    > I'm not sure, most likely the gfn will just disappear from the guest,
    > like a ballooned page disappears. Accessing it will likely cause a
    > crash.

    Best thing to do, is possible, is map the shared-info page in the
    xen-platform pci device's BAR memory range. Then it will not conflict with
    any RAM.

    If you do map it over the top of an existing RAM page, you will have to
    repopulate that RAM page before kexec, using populate_physmap hypercall. The
    good news is that the populate_physmap hypercall will have the side effect
    of unmapping the shared-info page, reayd to be mapped wherever the new
    kernel would like it to reside :)

    Hope this clears up some of the confusion. ;)

    -- Keir




    \
     
     \ /
      Last update: 2012-07-10 22:01    [W:2.907 / U:1.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site