From: David Gibson <david@gibson.dropbear.id.au> To: Christoph Hellwig <hch@lst.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com>, Halil Pasic <pasic@linux.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy <robin.murphy@arm.com>, linux-s390@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, 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>, "Lendacky, Thomas" <Thomas.Lendacky@amd.com>, Michael Mueller <mimu@linux.ibm.com> Subject: Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h Date: Fri, 21 Feb 2020 14:27:27 +1100 [thread overview] Message-ID: <20200221032727.GC2298@umbus.fritz.box> (raw) In-Reply-To: <20200220163135.GA13192@lst.de> [-- Attachment #1: Type: text/plain, Size: 2284 bytes --] On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote: > > >From a users perspective it makes absolutely perfect sense to use the > > bounce buffers when they are NEEDED. > > Forcing the user to specify iommu_platform just because you need bounce buffers > > really feels wrong. And obviously we have a severe performance issue > > because of the indirections. > > The point is that the user should not have to specify iommu_platform. > We need to make sure any new hypervisor (especially one that might require > bounce buffering) always sets it, So, I have draft qemu patches which enable iommu_platform by default. But that's really because of other problems with !iommu_platform, not anything to do with bounce buffering or secure VMs. The thing is that the hypervisor *doesn't* require bounce buffering. In the POWER (and maybe s390 as well) models for Secure VMs, it's the *guest*'s choice to enter secure mode, so the hypervisor has no reason to know whether the guest needs bounce buffering. As far as the hypervisor and qemu are concerned that's a guest internal detail, it just expects to get addresses it can access whether those are GPAs (iommu_platform=off) or IOVAs (iommu_platform=on). > as was a rather bogus legacy hack It was certainly a bad idea, but it was a bad idea that went into a public spec and has been widely deployed for many years. We can't just pretend it didn't happen and move on. Turning iommu_platform=on by default breaks old guests, some of which we still care about. We can't (automatically) do it only for guests that need bounce buffering, because the hypervisor doesn't know that ahead of time. > that isn't extensibe for cases that for example require bounce buffering. In fact bounce buffering isn't really the issue from the hypervisor (or spec's) point of view. It's the fact that not all of guest memory is accessible to the hypervisor. Bounce buffering is just one way the guest might deal with that. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au> To: Christoph Hellwig <hch@lst.de> Cc: linux-s390@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.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>, "Lendacky, Thomas" <Thomas.Lendacky@amd.com>, Viktor Mihajlovski <mihajlov@linux.ibm.com>, Robin Murphy <robin.murphy@arm.com> Subject: Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h Date: Fri, 21 Feb 2020 14:27:27 +1100 [thread overview] Message-ID: <20200221032727.GC2298@umbus.fritz.box> (raw) In-Reply-To: <20200220163135.GA13192@lst.de> [-- Attachment #1.1: Type: text/plain, Size: 2284 bytes --] On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote: > > >From a users perspective it makes absolutely perfect sense to use the > > bounce buffers when they are NEEDED. > > Forcing the user to specify iommu_platform just because you need bounce buffers > > really feels wrong. And obviously we have a severe performance issue > > because of the indirections. > > The point is that the user should not have to specify iommu_platform. > We need to make sure any new hypervisor (especially one that might require > bounce buffering) always sets it, So, I have draft qemu patches which enable iommu_platform by default. But that's really because of other problems with !iommu_platform, not anything to do with bounce buffering or secure VMs. The thing is that the hypervisor *doesn't* require bounce buffering. In the POWER (and maybe s390 as well) models for Secure VMs, it's the *guest*'s choice to enter secure mode, so the hypervisor has no reason to know whether the guest needs bounce buffering. As far as the hypervisor and qemu are concerned that's a guest internal detail, it just expects to get addresses it can access whether those are GPAs (iommu_platform=off) or IOVAs (iommu_platform=on). > as was a rather bogus legacy hack It was certainly a bad idea, but it was a bad idea that went into a public spec and has been widely deployed for many years. We can't just pretend it didn't happen and move on. Turning iommu_platform=on by default breaks old guests, some of which we still care about. We can't (automatically) do it only for guests that need bounce buffering, because the hypervisor doesn't know that ahead of time. > that isn't extensibe for cases that for example require bounce buffering. In fact bounce buffering isn't really the issue from the hypervisor (or spec's) point of view. It's the fact that not all of guest memory is accessible to the hypervisor. Bounce buffering is just one way the guest might deal with that. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-02-21 3:27 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 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 ` 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 [this message] 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=20200221032727.GC2298@umbus.fritz.box \ --to=david@gibson.dropbear.id.au \ --cc=Thomas.Lendacky@amd.com \ --cc=bauerman@linux.ibm.com \ --cc=borntraeger@de.ibm.com \ --cc=cohuck@redhat.com \ --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=pasic@linux.ibm.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: linkBe 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.