On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
> Allocate a fixmap slot for use by a paravirt_ops implementation. Xen
> uses this to map the hypervisor's shared info page, which doesn't have
> a pseudo-physical page number, and therefore can't be mapped
> ordinarily.
>
Why doesn't Xen allocate the shared_info page from the pseudo-physical
space? Doesn't it already have to steal pages from the pseudo-physical
space for e.g. initial page tables, console, etc? Why not do the same
for shared_info, and then you don't need a reserve the fixmap slot.
Dan
Dan Hecht wrote:
> Why doesn't Xen allocate the shared_info page from the pseudo-physical
> space? Doesn't it already have to steal pages from the
> pseudo-physical space for e.g. initial page tables, console, etc? Why
> not do the same for shared_info, and then you don't need a reserve the
> fixmap slot.
Unlike the pagetable pages or the console page, the shared info page
doesn't have a pseudo-physical address, so in order to map it we need to
directly construct a pte containing the mfn for that page. Inserting
this mapping into the fixmap space seems like the easiest way to do
this. It's not like a fixmap slot costs anything.
J
On 02/13/2007 05:36 PM, Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
>> Why doesn't Xen allocate the shared_info page from the pseudo-physical
>> space? Doesn't it already have to steal pages from the
>> pseudo-physical space for e.g. initial page tables, console, etc? Why
>> not do the same for shared_info, and then you don't need a reserve the
>> fixmap slot.
>
> Unlike the pagetable pages or the console page, the shared info page
> doesn't have a pseudo-physical address, so in order to map it we need to
> directly construct a pte containing the mfn for that page.
Right. But that is only because Xen decides to allocate the page from
the (machine) physical space, rather than from the pseudo-physical
space. My question is: why doesn't Xen allocate shared_info from the
pseudo-physical space? If it had, then this page wouldn't need to be
treated specially. I'm not sure, but I seem to remember on 64-bit
Xen/XenLinux allocated shared_info from pseudo-physical space already...
Inserting
> this mapping into the fixmap space seems like the easiest way to do
> this. It's not like a fixmap slot costs anything.
>
>
I don't really have an objection to stealing a fixmap slot, just seems
cleaner if you didn't have to special case the shared_info.
Dan
>>> Jeremy Fitzhardinge <[email protected]> 14.02.07 02:36 >>>
>Dan Hecht wrote:
>> Why doesn't Xen allocate the shared_info page from the pseudo-physical
>> space? Doesn't it already have to steal pages from the
>> pseudo-physical space for e.g. initial page tables, console, etc? Why
>> not do the same for shared_info, and then you don't need a reserve the
>> fixmap slot.
>
>Unlike the pagetable pages or the console page, the shared info page
>doesn't have a pseudo-physical address, so in order to map it we need to
>directly construct a pte containing the mfn for that page. Inserting
>this mapping into the fixmap space seems like the easiest way to do
>this. It's not like a fixmap slot costs anything.
Otoh there are many fixmap slots not used under Xen, perhaps it would
be possible to use one of those... One slot certainly doesn't cost a lot,
but many (like the IO-APIC group) may already matter, especially on
PAE systems with lots of memory). Consequently, if these can't be
squeezed out as needed, re-using would seem more appropriate than
adding.
(I would certainly favor [conditionally] removing them, but can't easily
see how to do this under CONFIG_PARAVIRT. Background being that
we've already been hit by those [namely the LAPIC one] remaining
present, hence the build not being able to detect that accesses to the
LAPIC page can't work. While no such access was ever left in the base
kernel, modules are more susceptible to this, and in our case it was
the [native, i.e. pre-xenoprof] oprofile driver that had been forgotten
to be disabled.)
Jan
Dan Hecht wrote:
> Right. But that is only because Xen decides to allocate the page from
> the (machine) physical space, rather than from the pseudo-physical
> space. My question is: why doesn't Xen allocate shared_info from the
> pseudo-physical space?
Historical reasons ...
> If it had, then this page wouldn't need to be
> treated specially. I'm not sure, but I seem to remember on 64-bit
> Xen/XenLinux allocated shared_info from pseudo-physical space already...
Yep, the ia64 port which came later handles some things differently,
specifically some "magic" pages are allocated more clever ;)
Changing that for x86 would break existing guests though.
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
On Wed, Feb 14, 2007 at 08:37:26AM +0000, Jan Beulich wrote:
> >>> Jeremy Fitzhardinge <[email protected]> 14.02.07 02:36 >>>
> >Dan Hecht wrote:
> >> Why doesn't Xen allocate the shared_info page from the pseudo-physical
> >> space? Doesn't it already have to steal pages from the
> >> pseudo-physical space for e.g. initial page tables, console, etc? Why
> >> not do the same for shared_info, and then you don't need a reserve the
> >> fixmap slot.
> >
> >Unlike the pagetable pages or the console page, the shared info page
> >doesn't have a pseudo-physical address, so in order to map it we need to
> >directly construct a pte containing the mfn for that page. Inserting
> >this mapping into the fixmap space seems like the easiest way to do
> >this. It's not like a fixmap slot costs anything.
>
> Otoh there are many fixmap slots not used under Xen, perhaps it would
> be possible to use one of those... One slot certainly doesn't cost a lot,
I don't have a problem with reserving one page for this.
-Andi