WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fix

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 14 Feb 2007 08:37:26 +0000
Cc: Andrew Morton <akpm@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx
Delivery-date: Wed, 14 Feb 2007 00:36:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45D26797.5090600@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070213221729.772002682@xxxxxxxx> <20070213221829.845132535@xxxxxxxx> <45D2649D.4080508@xxxxxxxxxx> <45D26797.5090600@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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

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

<Prev in Thread] Current Thread [Next in Thread>