similar to: [PATCH v3] virtio: new feature to detect IOMMU device quirk

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have

The interaction between virtio and IOMMUs is messy. On most systems with virtio, physical addresses match bus addresses, and it doesn't particularly matter which one we use to program the device. On some systems, including Xen and any system with a physical device that speaks virtio behind a physical IOMMU, we must program the IOMMU for virtio DMA to work at all. On other systems, including

The interaction between virtio and IOMMUs is messy. On most systems with virtio, physical addresses match bus addresses, and it doesn't particularly matter which one we use to program the device. On some systems, including Xen and any system with a physical device that speaks virtio behind a physical IOMMU, we must program the IOMMU for virtio DMA to work at all. On other systems, including

Use generic names for the quirks to make it clear it is not just about the IOMMU, it's about DMA access in general. changes from v1: added patch 2 Michael S. Tsirkin (2): virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk arch/um/drivers/virtio_uml.c | 2 +- drivers/gpu/drm/virtio/virtgpu_object.c | 2

Rename the bit to match latest virtio spec. Add a compat macro to avoid breaking existing userspace. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/um/drivers/virtio_uml.c | 2 +- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++-- drivers/vhost/net.c | 4 ++-- drivers/vhost/vdpa.c | 2 +-

On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote: > > This patch doesn't change DMAR tables, it creates a way for virtio > device to tell guest "I obey what DMAR tables tell you, you can stop > doing hacks". > > And as PPC guys seem adamant that platform tools there are no good for > that purpose, there's another bit that says "ignore what

On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote: > > This patch doesn't change DMAR tables, it creates a way for virtio > device to tell guest "I obey what DMAR tables tell you, you can stop > doing hacks". > > And as PPC guys seem adamant that platform tools there are no good for > that purpose, there's another bit that says "ignore what

The interaction between virtio and IOMMUs is messy. On most systems with virtio, physical addresses match bus addresses, and it doesn't particularly matter which one we use to program the device. On some systems, including Xen and any system with a physical device that speaks virtio behind a physical IOMMU, we must program the IOMMU for virtio DMA to work at all. On other systems, including

The interaction between virtio and IOMMUs is messy. On most systems with virtio, physical addresses match bus addresses, and it doesn't particularly matter which one we use to program the device. On some systems, including Xen and any system with a physical device that speaks virtio behind a physical IOMMU, we must program the IOMMU for virtio DMA to work at all. On other systems, including

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side sufficient? I thought I had replied to this... There are a couple of reasons: -

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side sufficient? I thought I had replied to this... There are a couple of reasons: -

On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > I'm not sure I understand the issue.??The public API is not about how > the driver works.??It doesn't say "don't use DMA API" anywhere, does it? > It's about telling device whether to obey the IOMMU and > about discovering whether a device is in fact under the IOMMU. Apologies, I was wrongly

On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

On 2020-06-10 15:24, Cornelia Huck wrote: > On Wed, 10 Jun 2020 15:11:51 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> Protected Virtualisation protects the memory of the guest and >> do not allow a the host to access all of its memory. >> >> Let's refuse a VIRTIO device which does not use IOMMU >> protected access. >> >>

On 2020-06-10 15:24, Cornelia Huck wrote: > On Wed, 10 Jun 2020 15:11:51 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> Protected Virtualisation protects the memory of the guest and >> do not allow a the host to access all of its memory. >> >> Let's refuse a VIRTIO device which does not use IOMMU >> protected access. >> >>

There are certian platforms which would like to use SWIOTLB based DMA API for bouncing purpose without actually requiring an IOMMU back end. But the virtio core does not allow such mechanism. Right now DMA MAP API is only selected for devices which have an IOMMU and then the QEMU/host back end will process all incoming SG buffer addresses as IOVA instead of simple GPA which is the case for simple

There are certian platforms which would like to use SWIOTLB based DMA API for bouncing purpose without actually requiring an IOMMU back end. But the virtio core does not allow such mechanism. Right now DMA MAP API is only selected for devices which have an IOMMU and then the QEMU/host back end will process all incoming SG buffer addresses as IOVA instead of simple GPA which is the case for simple

From: Thiago Jung Bauermann <bauerman at linux.ibm.com> Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must be set by both device and guest driver. However, as a hack, when DMA API returns physical addresses, guest driver can use the DMA API; even though device does not set VIRTIO_F_IOMMU_PLATFORM and just uses physical addresses. Doing this works-around POWER secure