Xen devel - Nov 2006 - linux/i386: variable hypervisor hole not really variable?

Anything said in the past about the hypervisor address space hole
being variable led me to believe this address range is really variable,
meaning that namely under a 64-bit hv I could shrink the hole to just
the space needed for the m2p table. Have I mis-interpreted what I
heard, or is there really a problem here? In any case, the kernel has
a number of references to HYPERVISOR_VIRT_START, which
continues to be provided in the public headers.

In any case, I will want to fix this - my understanding is that I''d
have
to introduce a new guest-specified feature identification (in the .note
section) telling the hv that it is okay to provide a non-default
HYPERVISOR_VIRT_START and, implicitly, a non-default m2p table
base.

Thanks, Jan

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

>>> Keir Fraser <keir@xensource.com> 10.11.06 15:59 >>>
>On 10/11/06 14:54, "Jan Beulich" <jbeulich@novell.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <keir@xensource.com> 10.11.06 16:09 >>>
>On 10/11/06 15:05, "Jan Beulich" <jbeulich@novell.com>
wrote:
>
>>> 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.
>
>I''d do that anyway, if we had that amount of memory in the machine.
Nicer
>than limiting guests to a range of the machine address space.
Sure, I want both - if the system has (and today it typically will have) less
than
166Gb, then I want to move the boundary up (to allow the guest to have more
lowmem). Otherwise I''ll keep it at its original place.

Jan

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