search for: virtio_f_iommu_platform

...tio_uml.c b/arch/um/drivers/virtio_uml.c index 351aee52aca6..a6c4bb6c2c01 100644 --- a/arch/um/drivers/virtio_uml.c +++ b/arch/um/drivers/virtio_uml.c @@ -385,7 +385,7 @@ static irqreturn_t vu_req_interrupt(int irq, void *data) } break; case VHOST_USER_SLAVE_IOTLB_MSG: - /* not supported - VIRTIO_F_IOMMU_PLATFORM */ + /* not supported - VIRTIO_F_ACCESS_PLATFORM */ case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG: /* not supported - VHOST_USER_PROTOCOL_F_HOST_NOTIFIER */ default: diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h index f4554412e607..24af422b5a3e 100644 --- a/...

...tio_uml.c b/arch/um/drivers/virtio_uml.c index 351aee52aca6..a6c4bb6c2c01 100644 --- a/arch/um/drivers/virtio_uml.c +++ b/arch/um/drivers/virtio_uml.c @@ -385,7 +385,7 @@ static irqreturn_t vu_req_interrupt(int irq, void *data) } break; case VHOST_USER_SLAVE_IOTLB_MSG: - /* not supported - VIRTIO_F_IOMMU_PLATFORM */ + /* not supported - VIRTIO_F_ACCESS_PLATFORM */ case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG: /* not supported - VHOST_USER_PROTOCOL_F_HOST_NOTIFIER */ default: diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h index f4554412e607..24af422b5a3e 100644 --- a/...

...the > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > disabled, it is not required. > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > Xen was there first, but everyone else is using that now. > > > > Unfortunately it is complicated and it is not related to > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate...

...the > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > disabled, it is not required. > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > Xen was there first, but everyone else is using that now. > > > > Unfortunately it is complicated and it is not related to > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate...

...enabled the dma API is required. When it is > > > > > > disabled, it is not required. > > > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > Unfortunately it is complicated and it is not related to > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > &gt...

...enabled the dma API is required. When it is > > > > > > disabled, it is not required. > > > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > Unfortunately it is complicated and it is not related to > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > &gt...

On Tue, 7 Jul 2020 10:44:37 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. Hm... what about: "If protected virtualization is active on s390, the virtio queues are not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been negotiated. Use the new arch_validate_virtio_features() interface to enforce this." > > Signed-off-by: Pierre Morel <pm...

On Tue, 7 Jul 2020 10:44:37 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. Hm... what about: "If protected virtualization is active on s390, the virtio queues are not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been negotiated. Use the new arch_validate_virtio_features() interface to enforce this." > > Signed-off-by: Pierre Morel <pm...

..._swiotlb to determine when vring should use dma APIs to map the > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > disabled, it is not required. > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > Xen was there first, but everyone else is using that now. Unfortunately it is complicated and it is not related to VIRTIO_F_IOMMU_PLATFORM :-( The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate foreign mappings (memory coming from other VMs) to physical addresses...

..._swiotlb to determine when vring should use dma APIs to map the > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > disabled, it is not required. > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > Xen was there first, but everyone else is using that now. Unfortunately it is complicated and it is not related to VIRTIO_F_IOMMU_PLATFORM :-( The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate foreign mappings (memory coming from other VMs) to physical addresses...

An architecture protecting the guest memory against unauthorized host access may want to enforce VIRTIO I/O device protection through the use of VIRTIO_F_IOMMU_PLATFORM. Let's give a chance to the architecture to accept or not devices without VIRTIO_F_IOMMU_PLATFORM. Pierre Morel (1): s390: virtio: let arch accept devices without IOMMU feature arch/s390/mm/init.c | 6 ++++++ drivers/virtio/virtio.c | 22 ++++++++++++++++++++++ include/linux/virtio.h...

On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: > An architecture protecting the guest memory against unauthorized host > access may want to enforce VIRTIO I/O device protection through the > use of VIRTIO_F_IOMMU_PLATFORM. > > Let's give a chance to the architecture to accept or not devices > without VIRTIO_F_IOMMU_PLATFORM. > > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > Acked-by: Jason Wang <jasowang at redhat.com> > Acked-by: Christian Borntraeger <borntraeger...

On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: > An architecture protecting the guest memory against unauthorized host > access may want to enforce VIRTIO I/O device protection through the > use of VIRTIO_F_IOMMU_PLATFORM. > > Let's give a chance to the architecture to accept or not devices > without VIRTIO_F_IOMMU_PLATFORM. > > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > Acked-by: Jason Wang <jasowang at redhat.com> > Acked-by: Christian Borntraeger <borntraeger...

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 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/...

On Thu, 9 Jul 2020 10:39:19 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt > > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > --- > arch/s390/mm/init.c | 27 ++++++++++++++...

On Thu, 9 Jul 2020 10:39:19 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt > > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > --- > arch/s390/mm/init.c | 27 ++++++++++++++...

...quot; <mst at redhat.com> wrote: > >> On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: >>> An architecture protecting the guest memory against unauthorized host >>> access may want to enforce VIRTIO I/O device protection through the >>> use of VIRTIO_F_IOMMU_PLATFORM. >>> >>> Let's give a chance to the architecture to accept or not devices >>> without VIRTIO_F_IOMMU_PLATFORM. >>> >>> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> >>> Acked-by: Jason Wang <jasowang at redhat.com> >&g...

...quot; <mst at redhat.com> wrote: > >> On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: >>> An architecture protecting the guest memory against unauthorized host >>> access may want to enforce VIRTIO I/O device protection through the >>> use of VIRTIO_F_IOMMU_PLATFORM. >>> >>> Let's give a chance to the architecture to accept or not devices >>> without VIRTIO_F_IOMMU_PLATFORM. >>> >>> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> >>> Acked-by: Jason Wang <jasowang at redhat.com> >&g...

...> > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > this? > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > &...

...> > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com> > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > this? > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > &...