Re: [Xen-devel] linux/i386: variable hypervisor hole not really variable?

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 10.11.06 15:59 >>>
>On 10/11/06 14:54, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>>> So long as you make the hole *smaller* there's obviously no need for a
>>> compat flag.
>> 
>> I'm not sure I understand you reasoning here. I do make the hole smaller
>> (i.e. move the beginning up), and the kernel dies miserably with that. With
>> that observation I surely think a flag is needed, as otherwise no older
>> kernels will ever be able to boot on a hv with a respective change.
>
>Ah yes, the page fault handler looks at HYPERVISOR_VIRT_START. Ah well. So
>yes, a capability flag is needed.

More importantly, the early page table setup also depends on this (as it needs
to avoid trying to change the Xen mappings). This is where it crashes right
away.

>This doesn't stop you relocating the m2p table though -- you can do that
>regardless. You'll just have to lie about hypervisor_virt_start unless the
>guest exports this new capability. So at least you don't have to vary the
>m2p start address across different guests.

Relocating the m2p table makes sense only if I can move the hv base address
as well - otherwise I win nothing, as it's the first thing in the address map
anyway. The only thing that I get for free here is that I don't have to limit
memory to 16Gb when allowing compatibility mode guests, I can rather set
the limit at 166Gb.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel