>>> Magnus Damm <magnus.damm@xxxxxxxxx> 16.03.09 12:19 >>>
>So the code assumes that PA_.. are even and VA_.. are odd. The defines
>could have been copied over to make more readable code, yes, or we
>could have shared header files somehow. In the end the hypervisor
>assumes the interface remains unchanged. The addresses are modified so
>the assembly snipped can run from hypervisor address space.
>
>What is the real problem? Just that the interface has changed?
The issue is that the Linux side changed without having any way to
recognize resulting problems apart from running into them. If a lower
software layer gets designed based on implementation details of a higher
layer, there should at least be build time checks that make sure the upper
layer doesn't change in incompatible ways (and yes, a few checks are
in that code, but their coverage is rather limited).
But I view the issue as broader: Any other OS wanting to make use of
the kexec hypercall interface would be required to match the Linux
implementation in various respects. This is what I consider a design flaw,
which makes me think that the current kexec sub-hypercalls should be
urgently deprecated in favor of a clean interface.
>>> 3) machine_kexec_load() blindly iterates over all page_list[] entries,
>>> regardless of whether any of them is zero, and hence establishes
>>> (currently on 32-bit only) numerous bogus page table entries mapping
>>> mfn 0.
>
>I don't remember if this was how things were in our original
>implementation, or if it is a side effect of upstream linux moving.
>Are the page table mappings bad? They may be a side effect of a shared
>implementation between 32-bit and 64-bit x86..
I don't think they're bad - they're just superfluous and as such latently
dangerous.
>> On Thu, Mar 12, 2009 at 02:49:50PM +0000, Jan Beulich wrote:
>>> 2) KEXEC_XEN_NO_PAGES is set to the apparently arbitrary value of 17.
>>> While a build error would clearly show any incompatible Linux side change
>>> in this case, it still seems bogus to hard-code this Linux defined value
>>> into
>>> the hypercall interface.
>
>> In reference to question 2), the number 17 is derived from
>> include/asm-x86_64/kexec.h in the linux-xen 2.6.18 tree as x86_64 has the
>> highest value for PAGES_NR. I agree that having this number included in
>> the hypercall interface isn't ideal.
>
>I remember that the KEXEC_XEN_NO_PAGES value is related to fixmap().
>We use virtual addresses from the fixmap to map in the pages coming
>from dom0. The fixmap is static by definition. So i think a static
>number comes from there.
But what if x86-64 decides to add PA_SWAP_PAGE (as i386 did in 2.6.27)?
While at least we'd get a build-time error on the kernel side, there will be no
way to get this to work with the current interface, unless they also drop
the middle level page table pointers (as i386 did in 2.6.29). That number
should have been chosen at least to leave some head room, but really
it shouldn't be a fixed number at all (after all, at the time the respective
mappings are needed, almost the entire Xen address space is available,
so there seems little reason to constrain them to the fixmap space).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home