From: Wei Wang2 <wei.wang2@amd.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Kay, Allen M" <allen.m.kay@intel.com>
Subject: Re: [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
Date: Mon, 23 May 2011 18:13:23 +0200 [thread overview]
Message-ID: <201105231813.23873.wei.wang2@amd.com> (raw)
In-Reply-To: <20110523131922.GF12801@whitby.uk.xensource.com>
> 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.
next prev parent reply other threads:[~2011-05-23 16:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-25 10:31 [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu Wei Wang
2011-05-16 1:42 ` Zhang, Yang Z
2011-05-16 8:27 ` Tim Deegan
2011-05-16 8:36 ` Zhang, Yang Z
2011-05-16 8:43 ` Tim Deegan
2011-05-16 8:50 ` Zhang, Yang Z
2011-05-17 0:13 ` Kay, Allen M
2011-05-17 7:55 ` Keir Fraser
2011-05-17 2:21 ` Kay, Allen M
2011-05-17 7:51 ` Keir Fraser
2011-05-21 0:51 ` Kay, Allen M
2011-05-23 10:58 ` Tim Deegan
2011-05-23 12:08 ` Wei Wang2
2011-05-23 13:19 ` Tim Deegan
2011-05-23 16:13 ` Wei Wang2 [this message]
2011-05-23 13:33 ` Zhang, Yang Z
2011-05-23 13:40 ` Tim Deegan
2011-05-23 13:46 ` Zhang, Yang Z
2011-05-23 14:27 ` Tim Deegan
2011-05-24 0:21 ` Kay, Allen M
2011-05-24 9:13 ` Tim Deegan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105231813.23873.wei.wang2@amd.com \
--to=wei.wang2@amd.com \
--cc=Tim.Deegan@citrix.com \
--cc=allen.m.kay@intel.com \
--cc=xen-devel@lists.xensource.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.