All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>
Cc: linux-s390@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	Cornelia Huck <cohuck@redhat.com>, Ram Pai <linuxram@us.ibm.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	iommu@lists.linux-foundation.org,
	Michael Mueller <mimu@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM
Date: Thu, 20 Feb 2020 17:06:04 +0100	[thread overview]
Message-ID: <20200220160606.53156-1-pasic@linux.ibm.com> (raw)

Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
linux use the DMA API, which in turn handles the memory
encryption/protection stuff if the guest decides to turn itself into
a protected one. This however makes no sense due to multiple reasons:
* The device is not changed by the fact that the guest RAM is
protected. The so called IOMMU bypass quirk is not affected.
* This usage is not congruent with  standardised semantics of
VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal reason
for using DMA API in virtio (orthogonal with respect to what is
expressed by VIRTIO_F_IOMMU_PLATFORM). 

This series aims to decouple 'have to use DMA API because my (guest) RAM
is protected' and 'have to use DMA API because the device told me
VIRTIO_F_IOMMU_PLATFORM'.

Please find more detailed explanations about the conceptual aspects in
the individual patches. There is however also a very practical problem
that is addressed by this series. 

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.

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

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>
Cc: Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>, Ram Pai <linuxram@us.ibm.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	Michael Mueller <mimu@linux.ibm.com>
Subject: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM
Date: Thu, 20 Feb 2020 17:06:04 +0100	[thread overview]
Message-ID: <20200220160606.53156-1-pasic@linux.ibm.com> (raw)

Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
linux use the DMA API, which in turn handles the memory
encryption/protection stuff if the guest decides to turn itself into
a protected one. This however makes no sense due to multiple reasons:
* The device is not changed by the fact that the guest RAM is
protected. The so called IOMMU bypass quirk is not affected.
* This usage is not congruent with  standardised semantics of
VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal reason
for using DMA API in virtio (orthogonal with respect to what is
expressed by VIRTIO_F_IOMMU_PLATFORM). 

This series aims to decouple 'have to use DMA API because my (guest) RAM
is protected' and 'have to use DMA API because the device told me
VIRTIO_F_IOMMU_PLATFORM'.

Please find more detailed explanations about the conceptual aspects in
the individual patches. There is however also a very practical problem
that is addressed by this series. 

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.

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

             reply	other threads:[~2020-02-20 16:08 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 16:06 Halil Pasic [this message]
2020-02-20 16:06 ` [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM Halil Pasic
2020-02-20 16:06 ` [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h Halil Pasic
2020-02-20 16:06   ` Halil Pasic
2020-02-20 16:11   ` Christoph Hellwig
2020-02-20 16:11     ` Christoph Hellwig
2020-02-20 16:23     ` Christian Borntraeger
2020-02-20 16:23       ` Christian Borntraeger
2020-02-20 16:31       ` Christoph Hellwig
2020-02-20 16:31         ` Christoph Hellwig
2020-02-20 16:31         ` Christoph Hellwig
2020-02-20 17:00         ` Christian Borntraeger
2020-02-20 17:00           ` Christian Borntraeger
2020-02-21  3:27         ` David Gibson
2020-02-21  3:27           ` David Gibson
2020-02-21 13:06           ` Halil Pasic
2020-02-21 13:06             ` Halil Pasic
2020-02-21 15:48             ` Michael S. Tsirkin
2020-02-21 15:48               ` Michael S. Tsirkin
2020-02-21 18:07               ` Halil Pasic
2020-02-21 18:07                 ` Halil Pasic
2020-02-24  3:33                 ` David Gibson
2020-02-24  3:33                   ` David Gibson
2020-02-24 18:49                   ` Halil Pasic
2020-02-24 18:49                     ` Halil Pasic
2020-02-25 18:08                     ` Cornelia Huck
2020-02-25 18:08                       ` Cornelia Huck
2020-02-28  0:23                       ` David Gibson
2020-02-28  0:23                         ` David Gibson
2020-02-20 16:06 ` [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected Halil Pasic
2020-02-20 16:06   ` Halil Pasic
2020-02-20 16:13   ` Christoph Hellwig
2020-02-20 16:13     ` Christoph Hellwig
2020-02-21  2:59     ` David Gibson
2020-02-21  2:59       ` David Gibson
2020-02-21  3:41       ` Jason Wang
2020-02-21  3:41         ` Jason Wang
2020-02-21 13:31         ` Halil Pasic
2020-02-21 13:31           ` Halil Pasic
2020-02-21 13:27       ` Halil Pasic
2020-02-21 13:27         ` Halil Pasic
2020-02-21 16:36       ` Christoph Hellwig
2020-02-21 16:36         ` Christoph Hellwig
2020-02-24  6:50         ` David Gibson
2020-02-24  6:50           ` David Gibson
2020-02-24 18:59         ` Halil Pasic
2020-02-24 18:59           ` Halil Pasic
2020-02-24 18:59           ` Halil Pasic
2020-02-21 14:33     ` Halil Pasic
2020-02-21 14:33       ` Halil Pasic
2020-02-21 16:39       ` Christoph Hellwig
2020-02-21 16:39         ` Christoph Hellwig
2020-02-21 18:16         ` Halil Pasic
2020-02-21 18:16           ` Halil Pasic
2020-02-21 18:16           ` Halil Pasic
2020-02-22 19:07       ` Michael S. Tsirkin
2020-02-22 19:07         ` Michael S. Tsirkin
2020-02-24 17:16         ` Christoph Hellwig
2020-02-24 17:16           ` Christoph Hellwig
2020-10-28 14:24           ` Alexander Graf via iommu
2020-10-28 18:01             ` Michael S. Tsirkin
2020-10-28 18:01               ` Michael S. Tsirkin
2020-10-28 18:01               ` Michael S. Tsirkin
2020-02-20 20:55   ` Michael S. Tsirkin
2020-02-20 20:55     ` Michael S. Tsirkin
2020-02-21  1:17     ` Ram Pai
2020-02-21  1:17       ` Ram Pai
2020-02-21  1:17       ` Ram Pai
2020-02-21  3:29       ` David Gibson
2020-02-21  3:29         ` David Gibson
2020-02-21 13:12     ` Halil Pasic
2020-02-21 13:12       ` Halil Pasic
2020-02-21 15:39       ` Tom Lendacky
2020-02-21 15:39         ` Tom Lendacky
2020-02-24  6:40         ` David Gibson
2020-02-24  6:40           ` David Gibson
2020-02-24  6:40           ` David Gibson
2020-02-21 15:56       ` Michael S. Tsirkin
2020-02-21 15:56         ` Michael S. Tsirkin
2020-02-21 16:35         ` Christoph Hellwig
2020-02-21 16:35           ` Christoph Hellwig
2020-02-21 18:03         ` Halil Pasic
2020-02-21 18:03           ` Halil Pasic
2020-02-20 20:48 ` [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM Michael S. Tsirkin
2020-02-20 20:48   ` Michael S. Tsirkin
2020-02-20 21:29 ` Michael S. Tsirkin
2020-02-20 21:29   ` Michael S. Tsirkin
2020-02-21 13:37   ` Halil Pasic
2020-02-21 13:37     ` Halil Pasic
2020-02-20 21:33 ` Michael S. Tsirkin
2020-02-20 21:33   ` Michael S. Tsirkin
2020-02-21 13:49   ` Halil Pasic
2020-02-21 13:49     ` Halil Pasic
2020-02-21 16:41   ` Christoph Hellwig
2020-02-21 16:41     ` Christoph Hellwig
2020-02-24  5:44     ` David Gibson
2020-02-24  5:44       ` David Gibson
2020-02-24  5:44       ` David Gibson
2020-02-21  6:22 ` Jason Wang
2020-02-21  6:22   ` Jason Wang
2020-02-21 14:56   ` Halil Pasic
2020-02-21 14:56     ` Halil Pasic
2020-02-24  3:38     ` David Gibson
2020-02-24  3:38       ` David Gibson
2020-02-24  4:01     ` Jason Wang
2020-02-24  4:01       ` Jason Wang
2020-02-24  4:01       ` Jason Wang
2020-02-24  6:06       ` Michael S. Tsirkin
2020-02-24  6:06         ` Michael S. Tsirkin
2020-02-24  6:45         ` Jason Wang
2020-02-24  6:45           ` Jason Wang
2020-02-24  7:48           ` Michael S. Tsirkin
2020-02-24  7:48             ` Michael S. Tsirkin
2020-02-24  9:26             ` Jason Wang
2020-02-24  9:26               ` Jason Wang
2020-02-24 13:40               ` Michael S. Tsirkin
2020-02-24 13:40                 ` Michael S. Tsirkin
2020-02-25  3:38                 ` Jason Wang
2020-02-25  3:38                   ` Jason Wang
2020-02-24 13:56               ` Halil Pasic
2020-02-24 13:56                 ` Halil Pasic
2020-02-25  3:30                 ` Jason Wang
2020-02-25  3:30                   ` Jason Wang
2020-02-25  3:30                   ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200220160606.53156-1-pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=frankja@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mihajlov@linux.ibm.com \
    --cc=mimu@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.