From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang2 Subject: Re: [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu Date: Mon, 23 May 2011 18:13:23 +0200 Message-ID: <201105231813.23873.wei.wang2@amd.com> References: <4D8C6F13.6020208@amd.com> <201105231408.50575.wei.wang2@amd.com> <20110523131922.GF12801@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110523131922.GF12801@whitby.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "Zhang, Yang Z" , "xen-devel@lists.xensource.com" , "Kay, Allen M" List-Id: xen-devel@lists.xenproject.org > 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? Thanks, Wei > Tim.