RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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