search for: iommu_platform

...r whether it's easier to just support modern device? >>>> >>>> Thanks >>> Well hardware vendors are I think interested in supporting legacy >>> guests. Limiting vdpa to modern only would make it uncompetitive. >> >> My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to >> work. > Hmm I don't really see why. Assume host maps guest memory properly, > VM does not have an IOMMU, legacy guest can just work. Yes, guest may not set IOMMU_PLATFORM. > > Care explaining what's wrong with this picture? The pr...

...r whether it's easier to just support modern device? >>>> >>>> Thanks >>> Well hardware vendors are I think interested in supporting legacy >>> guests. Limiting vdpa to modern only would make it uncompetitive. >> >> My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to >> work. > Hmm I don't really see why. Assume host maps guest memory properly, > VM does not have an IOMMU, legacy guest can just work. Yes, guest may not set IOMMU_PLATFORM. > > Care explaining what's wrong with this picture? The pr...

...> @@ -6,6 +6,12 @@ config VIRTIO > bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG > or CONFIG_S390_GUEST. > > +config ARCH_HAS_RESTRICTED_MEMORY_ACCESS > + bool > + help > + This option is selected by any architecture enforcing > + VIRTIO_F_IOMMU_PLATFORM This option is only for a very specific case of "restricted memory access", namely the kind that requires IOMMU_PLATFORM for virtio devices. ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS? Or is this intended to cover cases outside of virtio as well? > + > menuconfig VIRTIO_MENU >...

...> @@ -6,6 +6,12 @@ config VIRTIO > bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG > or CONFIG_S390_GUEST. > > +config ARCH_HAS_RESTRICTED_MEMORY_ACCESS > + bool > + help > + This option is selected by any architecture enforcing > + VIRTIO_F_IOMMU_PLATFORM This option is only for a very specific case of "restricted memory access", namely the kind that requires IOMMU_PLATFORM for virtio devices. ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS? Or is this intended to cover cases outside of virtio as well? > + > menuconfig VIRTIO_MENU >...

...o catch a kick to handle these. >> I wonder whether it's easier to just support modern device? >> >> Thanks > Well hardware vendors are I think interested in supporting legacy > guests. Limiting vdpa to modern only would make it uncompetitive. My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to work. So it can only work for modern device ... Thanks > > >

...o catch a kick to handle these. >> I wonder whether it's easier to just support modern device? >> >> Thanks > Well hardware vendors are I think interested in supporting legacy > guests. Limiting vdpa to modern only would make it uncompetitive. My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to work. So it can only work for modern device ... Thanks > > >

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >> Recently, EDKII introduced IOMMU protocol d1fddc4533bf. SEV patch > >> series introduced > >> a IoMmu protocol driver f9d129e68a45 to set a DMA acce...

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >> Recently, EDKII introduced IOMMU protocol d1fddc4533bf. SEV patch > >> series introduced > >> a IoMmu protocol driver f9d129e68a45 to set a DMA acce...

...n entry to reject the features on the transport basis. Transport is not architecture so I send a separate series in which we fail the feature negociation inside virtio_ccw_finalize_features, the virtio_config_ops.finalize_features for S390 CCW transport, when the device do not propose the VIRTIO_F_IOMMU_PLATFORM. This solves the problem of crashing QEMU when this one is not using a CCW device with iommu_platform=on in S390. Regards, Pierre Regards, Pierre Pierre Morel (1): s390: virtio-ccw: PV needs VIRTIO I/O device protection drivers/s390/virtio/virtio_ccw.c | 24 +++++++++++++++++++----- 1 file...

...n entry to reject the features on the transport basis. Transport is not architecture so I send a separate series in which we fail the feature negociation inside virtio_ccw_finalize_features, the virtio_config_ops.finalize_features for S390 CCW transport, when the device do not propose the VIRTIO_F_IOMMU_PLATFORM. This solves the problem of crashing QEMU when this one is not using a CCW device with iommu_platform=on in S390. Regards, Pierre Regards, Pierre Pierre Morel (1): s390: virtio-ccw: PV needs VIRTIO I/O device protection drivers/s390/virtio/virtio_ccw.c | 24 +++++++++++++++++++----- 1 file...

...dern device? > > > > > > > > > > Thanks > > > > Well hardware vendors are I think interested in supporting legacy > > > > guests. Limiting vdpa to modern only would make it uncompetitive. > > > > > > My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to > > > work. > > Hmm I don't really see why. Assume host maps guest memory properly, > > VM does not have an IOMMU, legacy guest can just work. > > > Yes, guest may not set IOMMU_PLATFORM. > > > > > > Care exp...

...Cornelia Huck wrote: > On Tue, 18 Aug 2020 16:58:30 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > ... >> +config ARCH_HAS_RESTRICTED_MEMORY_ACCESS >> + bool >> + help >> + This option is selected by any architecture enforcing >> + VIRTIO_F_IOMMU_PLATFORM > > This option is only for a very specific case of "restricted memory > access", namely the kind that requires IOMMU_PLATFORM for virtio > devices. ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS? Or is this intended > to cover cases outside of virtio as well? AFAIK we did not...

...s = mlx_to_vritio_features(dev_features); >>> + if (MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, virtio_version_1_0)) >>> + ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1); >> >> This is interesting. This suggests !VIRTIO_F_VERSION_1 && >> VIRTIO_F_IOMMU_PLATFORM is valid. But virito spec doesn't allow such >> configuration. > Will fix >> So I think you need either: >> >> 1) Fail vDPA device probe when VERSION_1 is not supported >> 2) clear IOMMU_PLATFORM if VERSION_1 is not negotiated >> >> For 2) I guess it...

On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: >>> In this specific case, because that would make qemu expect an iommu, >>> and there isn't one. >> >> >> I think that you can set iommu_platform in qemu without an iommu. > > No I mean the platform has one but it's not desirable for it to be used > due to the performance hit. Also the only requirement is to bounce the I/O buffers through SWIOTLB implemented as DMA API which the virtio core understands. There is no need for an...

On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: >>> In this specific case, because that would make qemu expect an iommu, >>> and there isn't one. >> >> >> I think that you can set iommu_platform in qemu without an iommu. > > No I mean the platform has one but it's not desirable for it to be used > due to the performance hit. Also the only requirement is to bounce the I/O buffers through SWIOTLB implemented as DMA API which the virtio core understands. There is no need for an...

...a >>>>simple issue: >>>>??? $ qemu -M q35,accel=kvm,kernel-irqchip=split \ >>>>?????????? -drive file=fedora.qcow2,format=qcow2,if=virtio \ >>>>?????????? -device intel-iommu,intremap=on \ >>>>?????????? -device vhost-vsock-pci,guest-cid=3,iommu_platform=on >>> >>> >>>Patch looks good, but a question: >>> >>>It looks to me you don't enable ATS which means vhost won't get >>>any invalidation request or did I miss anything? >>> >> >>You're right, I didn't see...

...> > > > > I'm confused by this. > > > > static bool vring_use_dma_api(struct virtio_device *vdev) > > { > > if (!virtio_has_iommu_quirk(vdev)) > > return true; > > > > > > Why doesn't setting VIRTIO_F_IOMMU_PLATFORM on the > > hypervisor side sufficient? > > In this specific case, because that would make qemu expect an iommu, > and there isn't one. I think that you can set iommu_platform in qemu without an iommu. > Anshuman, you need to provide more background here. I don't have...

...> > > > > I'm confused by this. > > > > static bool vring_use_dma_api(struct virtio_device *vdev) > > { > > if (!virtio_has_iommu_quirk(vdev)) > > return true; > > > > > > Why doesn't setting VIRTIO_F_IOMMU_PLATFORM on the > > hypervisor side sufficient? > > In this specific case, because that would make qemu expect an iommu, > and there isn't one. I think that you can set iommu_platform in qemu without an iommu. > Anshuman, you need to provide more background here. I don't have...

...hether we use the DMA API. > > > > On some systems, including Xen and any system with a physical device > > that speaks virtio behind a physical IOMMU, we must use the DMA API > > for virtio DMA to work at all. > > > > Add a feature bit to detect that: VIRTIO_F_IOMMU_PLATFORM. > > > > If not there, we preserve historic behavior and bypass the DMA > > API unless within Xen guest. This is actually required for > > systems, including SPARC and PPC64, where virtio-pci devices are > > enumerated as though they are behind an IOMMU, but the virti...

...hether we use the DMA API. > > > > On some systems, including Xen and any system with a physical device > > that speaks virtio behind a physical IOMMU, we must use the DMA API > > for virtio DMA to work at all. > > > > Add a feature bit to detect that: VIRTIO_F_IOMMU_PLATFORM. > > > > If not there, we preserve historic behavior and bypass the DMA > > API unless within Xen guest. This is actually required for > > systems, including SPARC and PPC64, where virtio-pci devices are > > enumerated as though they are behind an IOMMU, but the virti...