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

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>]

> >You are talking about 'promtion' (adding more permissions). Demotion
> >required flushing entries in the TLB and is typically more expensive,
> >hence the desire to 'batch' the synchronization.
> 
> So you're talking about TLB inside CPU? IMO, both demotion/promotion
> requires IOTLB flush. Even for promotion, it's not like instruction
> access to trigger fault for Xen to promote lazily and then restart the
> exection...

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.

> '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).

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.

Ian


 


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