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] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
From: Wei Wang2 <wei.wang2@xxxxxxx>
Date: Mon, 23 May 2011 18:13:23 +0200
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Delivery-date: Mon, 23 May 2011 09:16:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110523131922.GF12801@xxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D8C6F13.6020208@xxxxxxx> <201105231408.50575.wei.wang2@xxxxxxx> <20110523131922.GF12801@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 20070904.708012)
> Hi,
> At 13:08 +0100 on 23 May (1306156129), Wei Wang2 wrote:
> > > Unfortunately this change seems to be necessary for AMD IOMMU to share
> > > pagetables with the p2m.  I'd rather we didn't have it, because it
> > > means empty ptes look like RAM mappings of frame 0. :(
> > >
> > > Wei, is there any way we can reorganise the AMD IOMMU pagetables so we
> > > can store the p2m type somewhere that's not required to be zero?  If
> > > not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at
> > > the very least we'd like to be able to handle types other than ram_rw
> > > (e.g. ram_ro).
> >
> > Theoretically, we just need to keep bit 52 - bit 58 all zero for valid
> > dma translation entry. Probably we could  define ram_rw as 11000000000b,
> > which is the valid r/w permission for iommu and leaves bit 52 - 58 zero?
> Ugh; no, that will break EPT as well, and restricts us to only one
> accessible type.  It looks like there are no bits that are available in
> both normal pagetable and IOMMU pagetables.  How inconvenient.
OK, understand. Indeed there are no bits available to use. I am not strictly 
against reversing this patch,  if this causes too much changes for vtd. 
> So our only options are to harden the rest of the p2m code against
> blank entries looking like RAM, or to avoid sharing pagetables between
> p2m and AMD IOMMU. :(  I guess that depends on how much of a PITA it'll
> be to track down the rest of the places where EPT code trips over
> itself.  Maybe we should replace the clear_page() in allocating p2m
> pages with a loop that explicitly makes everything p2m_invalid.  It's
> not a terribly hot path, after all.

> But even if we do that, don't you want read-only and grant-mapped memory
> to work with the IOMMU? 

Ture, we lose grant mapping and RO here. But what is the use case of iommu 
using RO and grant-mapping in hvm? For hvm, since we could not know which 
parts of memory are actually used by dma transaction, should it be more safe 
that only r/w pages are accessed by iommu through p2m? 
> Tim.

Xen-devel mailing list

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