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/
Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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]> - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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] - 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/
Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
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 - 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/
