From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC PATCH 0/7] Implement Xen PV-IOMMU interface Date: Wed, 17 Feb 2016 15:12:46 -0500 Message-ID: <20160217201246.GB25726@char.us.oracle.com> References: <1455099035-17649-1-git-send-email-malcolm.crossley@citrix.com> <56BB11F4.8080905@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <56BB11F4.8080905@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Malcolm Crossley Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, tim@xen.org, "xen-devel@lists.xen.org" , jbeulich@suse.com, feng.wu@intel.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On Wed, Feb 10, 2016 at 10:33:24AM +0000, Malcolm Crossley wrote: > This RFC series implements the PV-IOMMU interface according to the PV-IOMMU > design draft D. > > The PV-IOMMU interface is currently restricted to being used by the hardware > domain only as non hardware domain callers have not been fully tested yet. > > Significant effort was put into implementing a m2b tracking structure without > increasing the size of struct page but no union was found that could be safely > used in all cases when a page is allocated to an HVM domain. Comments and > feedback on the m2b design are most welcome. > > The hardware domain specific IOMMU pre map mechanism was implemented in order > to keep performance parity with current out of tree mechanisms to obtain BFNs > for foreign guest owned memory. The pre map mechanism is not a weakening of > the current security model of Xen and is only allowed when the hardware domain > is allowed relaxed IOMMU mappings. I would recommend you add to this patchset: - docs/misc/pv-iommu.txt describing the design of this. - Add yourself to the maintainers file for this code: xen/common/pv_iommu? perhaps? - Compile this under ARM as well - and figure out what is missing there? - Add an KConfig entry so folks have the option of not compiling the Xen hypervisor with this? - Have these patches in a git tree for easier testing. > > > Malcolm Crossley (7): > common/pv-iommu: Add stub hypercall for PV-IOMMU > iommu: add iommu_lookup_page to lookup guest gfn for a particular > IOMMU mapping > VT-d: Add iommu_lookup_page support > common/pv-iommu: Add query, map and unmap ops > x86/m2b: Add a tracking structure for mfn to bfn mappings per page > common/pv-iommu: Add foreign ops to PV-IOMMU interface > common/pv-iommu: Allow hardware_domain to pre IOMMU map foreign > memory > > xen/arch/x86/domain.c | 12 +- > xen/arch/x86/mm/Makefile | 1 + > xen/arch/x86/mm/m2b.c | 211 ++++++++++++ > xen/arch/x86/x86_64/compat/entry.S | 2 + > xen/arch/x86/x86_64/entry.S | 2 + > xen/common/Makefile | 1 + > xen/common/memory.c | 11 + > xen/common/pv_iommu.c | 633 ++++++++++++++++++++++++++++++++++++ > xen/drivers/passthrough/iommu.c | 21 ++ > xen/drivers/passthrough/vtd/iommu.c | 31 ++ > xen/drivers/passthrough/vtd/iommu.h | 1 + > xen/include/asm-x86/domain.h | 1 + > xen/include/asm-x86/m2b.h | 65 ++++ > xen/include/asm-x86/mm.h | 12 +- > xen/include/public/hvm/ioreq.h | 1 + > xen/include/public/pv-iommu.h | 93 ++++++ > xen/include/public/xen.h | 1 + > xen/include/xen/iommu.h | 2 + > xen/include/xen/sched.h | 4 + > xen/include/xsm/dummy.h | 6 + > xen/include/xsm/xsm.h | 6 + > xen/xsm/dummy.c | 1 + > 22 files changed, 1116 insertions(+), 2 deletions(-) > create mode 100644 xen/arch/x86/mm/m2b.c > create mode 100644 xen/common/pv_iommu.c > create mode 100644 xen/include/asm-x86/m2b.h > create mode 100644 xen/include/public/pv-iommu.h > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel