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] [PATCH 0/5] VT-d support for PV guests

To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>, "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 21 May 2008 13:56:13 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 22:56:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <DD74FBB8EE28D441903D56487861CD9D2EC9E0B3@xxxxxxxxxxxxxxxxxxxxxx>
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: <18481.58026.284129.700801@xxxxxxxxxxxxxxxxxx><C4583ED4.18C1B%keir.fraser@xxxxxxxxxxxxx><18482.43836.546105.964056@xxxxxxxxxxxxxxxxxx><DD74FBB8EE28D441903D56487861CD9D2EBE0017@xxxxxxxxxxxxxxxxxxxxxx><18482.56286.735593.611302@xxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D2EBE052B@xxxxxxxxxxxxxxxxxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F024D92DD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D2EC9E093@xxxxxxxxxxxxxxxxxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F024D92E3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D2EC9E0B3@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6g3hUxhZrPrFkQBC7vi1rbgSYSAACfeIQABLbWwAACYrWsAAAWI8QAACihvAAAFxA4A==
Thread-topic: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: 2008年5月21日 13:32
>
>The IOMMU TLB doesn't cache not_present entries, hence you 
>don't need to
>do a flush when transitioning an entry from not_present to 
>present. Some
>IOMMUs will also re-walk the pagetable if they find a TLB entry that is
>read-only and the operation is a write, but I can't recall whether VTd
>is like this.

You're right, though VT-d spec defines a capability bit to indicate
whether VT-d may cache non-present entry or not. In reality it
doesn't make sense to do that.

For promotion from non-present to present, then no flush is required.
But for promotion from read-only to read-write, I guess flush has to
be forced. Not sure whether currently such grant entry exists to
switch RO/RW permission on demand.

>
>> 'batch' IOTLB flush is good direction, which requires some 
>cooperation
>> from guest, e.g. as long as guest driver doesn't attempt to 
>use set of
>> frames in changing. So to me it's more like some change in guest side
>> to batch grant/m2p request together. Or else Xen itself doesn't know
>> when one changed mapping will be used by guest and thus has to
>> force flush for each change before resuming back to guest
>
>For ballooned frames, Xen should be able to put them on a 
>'pending' list
>awaiting completion of a flush (hence the flush is typically not
>synchronous).

It seems so. Just one security concern: it's possible to have decreased
frames allocated to another VM before completion of async flush. In this
case, the IOMMU still caches old mapping and thus it leaks a window
for mallicious domain/device to touch those frames...

But we may force a delayed completion check when a free page is 
allocated to a new VM or inserted to other p2m table. Then I agree upon 
page's specific usage, async flush is possible. :-)

>
>Frames that transition to pagetable frames are more problematic. It's
>probably better to modify the guest to create a separate quicklist for
>pagetable frames, so they get recycled and remain out of the 
>IOMMU until
>they return to the free list.
>

So you're already talking about one more step from current implentation,
to selectively insert mapping as device really requires. Create a PV iommu
interface may serve this purpose more accurately.

Thanks,
Kevin

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