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: "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:05:05 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 22:05:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D92DD@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6g3hUxhZrPrFkQBC7vi1rbgSYSAACfeIQABLbWwAACYrWsA==
Thread-topic: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
> >Is "demotion" of access handled synchronously, or do you have some
> >tricks to mitigate the synchronization?
> 
> All changes need be handled synchronously, as DMA request is not
> restartable with VT-d fault as async event notification. Hardware bits
> are designed in such way that all expected permission controls have
> to exist before device actually issues access request.

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.

> >kmap-style area of physical address space to cycle the mappings
> through
> >to avoid having to do so many synchronous invalidates (at the
> >expense of
> >allowing a driver domain to be able to DMA to a page for a
> >little longer
> >than it strictly ought to).
> 
> Could you elaborate a bit how kmap-style area helps here? The key
> point is whether frequency of p2m mapping can be reduced...

A window of guest physical address space is created that is used to
create mappings to granted pages. The next available free slot is used
when creating a mapping. When the end of the window is reached, flush
the IOMMU. (Actually, you can do better by issuing a flush at the
halfway point and then synchronizing against the flush at the end if the
window, effectively double buffering).

This typically avoids the churn that would happen with grant mappings
where the same guest physical address region is used to map different
pages (requiring a synchronous flush).

Ian



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

<Prev in Thread] Current Thread [Next in Thread>