Re: [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
On Wed, Feb 14, 2007 at 08:37:26AM +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
>>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
On Wed, Feb 14, 2007 at 08:37:26AM +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
