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: "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>
Date: Tue, 20 May 2008 14:21:08 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 06:21:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18482.43836.546105.964056@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6Zo9xhNBMBfTGQtm3yMrmT1L8aAAE9Lsg
Thread-topic: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
> The patchset does, as you guessed, enable isolation for PV guests with
> direct hardware access.  If you assign a PCI device to a guest you are
> guaranteed that the assigned device can't access the memory of other
> guests or Xen itself.  The patchseet allows the device to access all
> its own memory which it has write access to, and memory which is
> granted to it.

Not that I particularly think it matters, but does the patch configure
the IOMMU to distinguish between read-only and read-write access to a
guest's own memory or granted memory? If not, we should at least clearly
document that we're being a little more permissive. 

Have you got any with-and-without performance results with a decent
high-throughput device (e.g. a HBA or 10Gb/s NIC)? 

It would be good if you could provide a bit more detail on when the
patch populates IOMMU entries, and how it keeps them in sync. For
example, does the IOMMU map all the guest's memory, or just that which
will soon be the subject of a DMA? How synchronous is the patch in
removing mappings, e.g. due to page type changes (pagetable pages,
balloon driver) or due to unmapping grants?  

There's been a lot of discussion at various xen summits about different
IOMMU optimizations (e.g. for IBM Summit, Power etc) and I'd like to
understand exactly what tradeoffs your implementation makes. Anyhow,
good stuff, thanks!

Thanks,
Ian
 
 



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