On Tue, Feb 25, 2020 at 07:08:02PM +0100, Cornelia Huck wrote:

On Mon, 24 Feb 2020 19:49:53 +0100
Halil Pasic [off-list ref] wrote:

quoted

On Mon, 24 Feb 2020 14:33:14 +1100
David Gibson [off-list ref] wrote:

quoted

On Fri, Feb 21, 2020 at 07:07:02PM +0100, Halil Pasic wrote:  

quoted

On Fri, 21 Feb 2020 10:48:15 -0500
"Michael S. Tsirkin" [off-list ref] wrote:
  

quoted

On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic wrote:  

quoted

On Fri, 21 Feb 2020 14:27:27 +1100
David Gibson [off-list ref] wrote:
  

quoted

On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote:  

quoted

On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote:  

quoted

quoted

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).  

I very much agree!
  

quoted

quoted

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.  

We could default to iommu_platform=on on s390 when the host has active
support for protected virtualization... but that's just another kind of
horrible, so let's just pretend I didn't suggest it.

Yeah, that would break migration between hosts with the feature and
hosts without - for everything, not just protected guests.  In general
any kind of guest visible configuration change based on host
properties is incompatible with the qemu/KVM migration model.

-- 
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