quoted

quoted

Jeremy Fitzhardinge [off-list ref] 14.02.07 02:36 >>>

Dan Hecht wrote:

quoted

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