From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wei Wang2" Subject: [XEN-IOMMU] Proposal of DMA protection/isolation support Date: Thu, 10 Jan 2008 16:48:24 +0100 Message-ID: <1199980104.4405.122.camel@gran.amd.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, iommu@lists.linux-foundation.org Cc: muli@il.ibm.com, Uwe.Dannowski@amd.com, Michael.Hohmuth@amd.com, thomas.woller@amd.com List-Id: xen-devel@lists.xenproject.org hi list, I am considering adding DMA protection/isolation support for iommu machine: Below are the suggested approaches to be discussed: 1) Para-virtualized IOMMU If it is possible to integrate IOMMU driver into guest kernel, we can just implement a set of para-virtualized interface to forward hardware operations from guest to HV. Guest kernel will allocation IO page table for itself, but IO-PTE updating is verified by HV through hypercall. 2) IOMMU-aware dma layer. Currently, driver domain utilizes swiotlb to get dma_address below 4G, which is an additional overhead to IOMMU machine. For IOMMU machine, we can implement a new dma layer which takes "guest_domain-id", "device_bdf", and "guest_page" information as parameters and returns virtual io address to guest OS. Guest OS only have very limited knowledge/control to IOMMU. In this case, HV will allocate and update IO page table for guest domain. 3) Hooking guest memory changes No guest OS modification is needed in this approach. All we need is to update IO page table when guest physical memory changes triggered by domain initialization, ballooning, and grant reference mapping... Thanks for any comments, ideas, corrections... to this thread. -Wei