[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] linux/i386: variable hypervisor hole not really variable?
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |