On Mon, Jun 15, 2020 at 12:39:40PM +0000, Liu, Yi L wrote: > > From: Stefan Hajnoczi <stefanha@xxxxxxxxx> > > Sent: Monday, June 15, 2020 6:02 PM > > > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote: > > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on > > > Intel platforms allows address space sharing between device DMA and > > > applications. SVA can reduce programming complexity and enhance security. > > > > > > This VFIO series is intended to expose SVA usage to VMs. i.e. Sharing > > > guest application address space with passthru devices. This is called > > > vSVA in this series. The whole vSVA enabling requires QEMU/VFIO/IOMMU > > > changes. For IOMMU and QEMU changes, they are in separate series (listed > > > in the "Related series"). > > > > > > The high-level architecture for SVA virtualization is as below, the key > > > design of vSVA support is to utilize the dual-stage IOMMU translation ( > > > also known as IOMMU nesting translation) capability in host IOMMU. > > > > > > > > > .-------------. .---------------------------. > > > | vIOMMU | | Guest process CR3, FL only| > > > | | '---------------------------' > > > .----------------/ > > > | PASID Entry |--- PASID cache flush - > > > '-------------' | > > > | | V > > > | | CR3 in GPA > > > '-------------' > > > Guest > > > ------| Shadow |--------------------------|-------- > > > v v v > > > Host > > > .-------------. .----------------------. > > > | pIOMMU | | Bind FL for GVA-GPA | > > > | | '----------------------' > > > .----------------/ | > > > | PASID Entry | V (Nested xlate) > > > '----------------\.------------------------------. > > > | | |SL for GPA-HPA, default domain| > > > | | '------------------------------' > > > '-------------' > > > Where: > > > - FL = First level/stage one page tables > > > - SL = Second level/stage two page tables > > > > Hi, > > Looks like an interesting feature! > > thanks for the interest. Stefan :-) > > > To check I understand this feature: can applications now pass virtual > > addresses to devices instead of translating to IOVAs? > > yes, application could pass virtual addresses to device directly. As > long as the virtual address is mapped in cpu page table, then IOMMU > would get it translated to physical address. > > > If yes, can guest applications restrict the vSVA address space so the > > device only has access to certain regions? > > do you mean restrict the access of certain virtual address regions of > guest application ? or certain guest memory? :-) Your reply below answered my question. I was wondering if applications can protect parts of their virtual memory space that should not be accessed by the device. It makes sense that there is a trade-off to simplify the programming model and performance might also be better if the application doesn't need to DMA map/unmap buffers frequently. Stefan
Attachment:
signature.asc
Description: PGP signature
