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
 
   
 

xense-devel

Re: [Xense-devel] Xen memory management

To: Travis Johnson <tjohnson@xxxxxxxxxxxxxxxx>
Subject: Re: [Xense-devel] Xen memory management
From: "M.A. Williamson" <maw48@xxxxxxxxx>
Date: 07 Mar 2006 17:26:49 +0000
Cc: mark.williamson@xxxxxxxxxxxx, Xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Mar 2006 17:28:05 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <440DC007.6030407@xxxxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
References: <440DC007.6030407@xxxxxxxxxxxxxxxx>
Reply-to: mark.williamson@xxxxxxxxxxxx
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
So with full virtualization using HVM's Xen is responsible for maintaining shadow page tables for each HVM. So does that mean Xen has to trap every write _and read_ to the HVM page table and do address translation from P2M(write) and M2P(read)?

Pacifica has an optional feature which allows the processor to walk the guest page table and do physical-to-machine translation from a host table before filling the TLB. I don't think the initial wave of CPUs implements this (?) but I guess it'll appear later - at which point you get the effect of shadow PTs implemented in hardware.

Reads are an interesting question... The guest will be reading its own pagetables, which will have physical addresses in (which it will therefore understand). The only thing you might want to emulate are accesses to the accessed/dirty bits, since these won't be directly updated by the hardware. I believe Xen somehow propagates these back from the host pagetables into the guest's pagetables, but I'm not clear on exactly when this happens...

I assume if that's true the global tables go away, a HVM wouldn't know they existed anyway.

HVM systems don't see the global tables. They're only needed for paravirtualised guests, because those guests need to do the M2P mapping efficiently themselves.

Are there any other strategies for safe page table access that don't involve Xen (writable page tables with HVM)? It seems like the full virtualization strategy could be quite expensive, although it seems pretty safe.

What exactly do you mean by "safe" here? Do you mean "without the global M2P table"? You *could* implement a per-domain M2P table that'd otherwise work the same. It'd just be a bit memory hungry. Or you could get the guest to maintain its own M2P table, again having a per-guest cost.

Thanks for the clarification.

Did that help some?

P.S. Is it safe to send pictures to the list? I don't know if that's kosher or not so I'm holding off.

I think they've been sent before without any major explosions occurring... I'm not sure if it'll need moderator approval.

Cheers,
Mark

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel

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