On Thu, 20 Feb 2020 16:33:35 -0500 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote: > > For vhost-net the feature VIRTIO_F_IOMMU_PLATFORM has the following side > > effect The vhost code assumes it the addresses on the virtio descriptor > > ring are not guest physical addresses but iova's, and insists on doing a > > translation of these regardless of what transport is used (e.g. whether > > we emulate a PCI or a CCW device). (For details see commit 6b1e6cc7855b > > "vhost: new device IOTLB API".) On s390 this results in severe > > performance degradation (c.a. factor 10). BTW with ccw I/O there is > > (architecturally) no IOMMU, so the whole address translation makes no > > sense in the context of virtio-ccw. > > So it sounds like a host issue: the emulation of s390 unnecessarily complicated. > Working around it by the guest looks wrong ... While do think that forcing IOMMU_PLATFORM on devices that do not want or need it, just to trigger DMA API usage in guest is conceptually wrong, I do agree, that we might have a host issue. Namely, unlike PCI, CCW does not have an IOMMU, and the spec clearly states that "Whether accesses are actually limited or translated is described by platform-specific means.". With CCW devices we don't have address translation by IOMMU, and in that sense vhost is probably wrong about trying to do the translation. That is why I mentioned the patch, and that it's done regardless of the transport/platform. Regards, Halil > > > Halil Pasic (2): > > mm: move force_dma_unencrypted() to mem_encrypt.h > > virtio: let virtio use DMA API when guest RAM is protected > > > > drivers/virtio/virtio_ring.c | 3 +++ > > include/linux/dma-direct.h | 9 --------- > > include/linux/mem_encrypt.h | 10 ++++++++++ > > 3 files changed, 13 insertions(+), 9 deletions(-) > > > > > > base-commit: ca7e1fd1026c5af6a533b4b5447e1d2f153e28f2 > > -- > > 2.17.1 >