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] V2E tree on xenbits update

To: Anthony Liguori <aliguori@xxxxxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] V2E tree on xenbits update
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 16 Jan 2007 09:56:21 +0000
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Daniel Stekloff <dsteklof@xxxxxxxxxx>, Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Tue, 16 Jan 2007 01:56:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45ABDE3F.1000805@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc5VJMF0biYKKVHEdurKQANk04WTA==
Thread-topic: [Xen-devel] V2E tree on xenbits update
User-agent: Microsoft-Entourage/11.3.2.061213
On 15/1/07 8:04 pm, "Anthony Liguori" <aliguori@xxxxxxxxxxxxxxxxxx> wrote:

>  * There's no guarantee ATM that QEMU's dynamic translator will preserve
> the atomicity of instructions.  For SMP guests, this would be a problem
> if one VCPU is running on bare metal while another VCPU is running in
> the emulator.
> 
>  * It's unclear what the best strategy is for addressing page table
> updates while in the emulator.  There has to be some notification to the
> hypervisor so that the shadow code knows to invalidate any PT changes
> made during emulation.

My suspicion is that we may need to make shadow mode aware of this foreign
mapping of HVM pages, and allow it (somehow) to keep write protection in
sync. Other techniques are likely to either be racey or slow in the common
case. We have to be able to do atomic RMW instructions on shadowed
pagetables which as you say is troublesome in two ways: qemu doesn't do true
atomic instructions and, even if it did, the update would not synchronise
with other vcpus on the shadow_lock (consider XCHG(ptep, 0) racing with
another vcpu about to dirty the mapped page for the first time -- we could
lose the dirty bit and/or fail to remove the ptep mapping).

I wonder if shadow awareness would be easier if we had the 'stub domain'
functionality, so a tighter binding between HVM and qemu, recognised by Xen.

 -- Keir


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

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