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/
Home Products Support Community News


RE: [Xen-devel] [PATCH][UPDATE]Provide fast write emulation path

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][UPDATE]Provide fast write emulation path
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 15 Feb 2008 20:21:19 +0800
Cc: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Feb 2008 04:22:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080215113616.GB2847@xxxxxxxxxxxxxxxxxxxxx>
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: <D470B4E54465E3469E2ABBC5AFAC390F024D8F7A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C3DB138A.1C731%Keir.Fraser@xxxxxxxxxxxx> <20080215113616.GB2847@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achvx3H/EqOU1FvyQtC4ogiADaSZ6AABO9OQ
Thread-topic: [Xen-devel] [PATCH][UPDATE]Provide fast write emulation path
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] 
>Sent: 2008年2月15日 19:36
>At 10:01 +0000 on 15 Feb (1203069706), Keir Fraser wrote:
>> I'd like a final ack from Tim on this one before applying.
>I read through again and the only thing I can see is a risk that on SMP
>guests, a foreign vcpu might change the guest pagetable under our feet,
>leading to a risk of using inconsistent mappings for reads and writes.
>I think that's OK, though, because
> - we already have similar exposure from vTLB &c, and will do from OOS;
> - a guest with good TLB flush discipline should be entirely safe.

Yep. This is actually same as physical cpu behavior, as long as
inconsistent mappings are not stamped into shadow page table.

Thanks for comments,

Xen-devel mailing list