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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>
Date: Wed, 21 May 2008 06:32:21 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 22:33:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D92E3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6g3hUxhZrPrFkQBC7vi1rbgSYSAACfeIQABLbWwAACYrWsAAAWI8QAACihvA=
Thread-topic: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
> >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

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.



Xen-devel mailing list