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

Re: [Xen-devel] Essay on an important Xen decision (long)

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Essay on an important Xen decision (long)
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 10 Jan 2006 17:02:54 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 10 Jan 2006 23:09:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD59030F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: IBM Linux Technology Center
References: <516F50407E01324991DD6D07B0531AD59030F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-01-10 at 11:26 -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> 
> 1) P==M: The guest is given a subset of machine memory that it
>    can access "directly".  Accesses to machine memory addresses
>    outside of this range must somehow be restricted (but not
>    necessarily disallowed) by Xen.
> 
> 2) guest-aware p!=m (P2M): The guest is given max_pages of
>    contiguous physical memory starting at zero and the knowledge
>    that physical addresses are different than machine addresses.
>    The guest must understand the difference between a physical
>    address and a machine address and utilize the correct one in
>    different situations.
> 
> 3) virtual physical (VP): The guest is given max_pages of
>    contiguous physical memory starting at zero.  Xen provides
>    the illusion to the guest that this is machine memory;
>    any physical-to-machine translation required for functional
>    correctness is handled invisibly by Xen.  VP cannot be used
>    by guests that directly program DMA-based I/O devices
>    because a DMA device requires a machine address and, by
>    definition, the guest knows only about physical addresses.
> 
> Xen/x86 and Xen/x86_64 use P2M, but switch to VP (aka "shadow
> mode") for an unprivileged guest when a migration is underway.
> Xen/ia64 currently uses P==M for domain0 and VP for unprivileged
> guests.  Xen/ppc intends to use VP only.
> 
> There is an architectural proposal to change Xen/ia64 so that
> domain0 uses P2M instead of P==M.  We will call this choice P2M
> and the choice to stay on the current path P==M.

So ia64 dom0 physical 0 is machine 0? Where does Xen live in machine
space?

PowerPC exception handlers are architecturally hardcoded to the first
couple pages of memory, so Xen needs to live there. Linux expects it is
booting at 0 of course, so dom0 runs in an offset physical address
space.

The trouble then comes when dom0 needs to access IO or domU memory;
obviously dom0 must have some awareness of the machine space.
Accordingly, I'm thinking I'm going to need to install p2m tables in
dom0, and once they're there, why not have domU use them too?

-- 
Hollis Blanchard
IBM Linux Technology Center


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

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