> -----Original Message----- > From: Bhushan Bharat-R65777 > Sent: Wednesday, April 24, 2013 6:04 AM > To: Joerg Roedel; Yoder Stuart-B08248 > Cc: [email protected] > Subject: RE: RFC: vfio / iommu driver for hardware with no iommu > > > > > -----Original Message----- > > From: [email protected] [mailto:iommu- > > [email protected]] On Behalf Of Joerg Roedel > > Sent: Wednesday, April 24, 2013 4:27 PM > > To: Yoder Stuart-B08248 > > Cc: [email protected] > > Subject: Re: RFC: vfio / iommu driver for hardware with no iommu > > > > On Tue, Apr 23, 2013 at 04:13:00PM +0000, Yoder Stuart-B08248 wrote: > > > We're aware of the obvious limitations-- no protection, DMA'able > > > memory must be physically contiguous and will have no iova->phy > > > translation. But there are use cases where all OSes involved are > > > trusted and customers can > > > live with those limitations. Virtualization is used > > > here not to sandbox untrusted code, but to consolidate multiple OSes. > > > > One of the major points of VFIO is to provide a userspace interface for > > hardware > > IOMMUs. So if you have a platform without an IOMMU why do you care about > > VFIO at > > all? > > We want to do direct device assignment to user space. > So if the device is behind iommu then it will be a secure interface. > if device is not behind a iommu then it is insecure. But the user space can > access the device. This way > we can be consistent with one mechanism to do direct device assignment.
And more specifically, there's the desire to assign things like a PCI device to a KVM virtual machine on a platform without an iommu. QEMU uses vfio-pci and we don't want to implement a completely separate user space approach to do this. We want QEMU to stay (mostly) unchanged. Stuart _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
