Re: [for-6.0 v5 12/13] securable guest memory: Alter virtio default properties for protected guests

From: Christian Borntraeger <borntraeger@de.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Halil Pasic <pasic@linux.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	pair@us.ibm.com, brijesh.singh@amd.com, frankja@linux.ibm.com,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	david@redhat.com, dgilbert@redhat.com,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	qemu-ppc@nongnu.org, berrange@redhat.com, thuth@redhat.com,
	pbonzini@redhat.com, rth@twiddle.net, mdroth@linux.vnet.ibm.com
Subject: Re: [for-6.0 v5 12/13] securable guest memory: Alter virtio default properties for protected guests
Date: Tue, 8 Dec 2020 09:16:28 +0100	[thread overview]
Message-ID: <54a86780-4ee2-089c-397a-83601ec1daec@de.ibm.com> (raw)
In-Reply-To: <20201208015403.GB2555@yekko.fritz.box>

On 08.12.20 02:54, David Gibson wrote:
> On Fri, Dec 04, 2020 at 03:43:10PM +0100, Halil Pasic wrote:
>> On Fri, 4 Dec 2020 09:29:59 +0100
>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>
>>> On 04.12.20 09:17, Cornelia Huck wrote:
>>>> On Fri, 4 Dec 2020 09:10:36 +0100
>>>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>>>
>>>>> On 04.12.20 06:44, David Gibson wrote:
>>>>>> The default behaviour for virtio devices is not to use the platforms normal
>>>>>> DMA paths, but instead to use the fact that it's running in a hypervisor
>>>>>> to directly access guest memory.  That doesn't work if the guest's memory
>>>>>> is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
>>>>>>
>>>>>> So, if a securable guest memory mechanism is enabled, then apply the
>>>>>> iommu_platform=on option so it will go through normal DMA mechanisms.
>>>>>> Those will presumably have some way of marking memory as shared with
>>>>>> the hypervisor or hardware so that DMA will work.
>>>>>>
>>>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>>>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>>>>> ---
>>>>>>  hw/core/machine.c | 13 +++++++++++++
>>>>>>  1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>>>>> index a67a27d03c..d16273d75d 100644
>>>>>> --- a/hw/core/machine.c
>>>>>> +++ b/hw/core/machine.c
>>>>>> @@ -28,6 +28,8 @@
>>>>>>  #include "hw/mem/nvdimm.h"
>>>>>>  #include "migration/vmstate.h"
>>>>>>  #include "exec/securable-guest-memory.h"
>>>>>> +#include "hw/virtio/virtio.h"
>>>>>> +#include "hw/virtio/virtio-pci.h"
>>>>>>  
>>>>>>  GlobalProperty hw_compat_5_1[] = {
>>>>>>      { "vhost-scsi", "num_queues", "1"},
>>>>>> @@ -1169,6 +1171,17 @@ void machine_run_board_init(MachineState *machine)
>>>>>>           * areas.
>>>>>>           */
>>>>>>          machine_set_mem_merge(OBJECT(machine), false, &error_abort);
>>>>>> +
>>>>>> +        /*
>>>>>> +         * Virtio devices can't count on directly accessing guest
>>>>>> +         * memory, so they need iommu_platform=on to use normal DMA
>>>>>> +         * mechanisms.  That requires also disabling legacy virtio
>>>>>> +         * support for those virtio pci devices which allow it.
>>>>>> +         */
>>>>>> +        object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy",
>>>>>> +                                   "on", true);
>>>>>> +        object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform",
>>>>>> +                                   "on", false);  
>>>>>
>>>>> I have not followed all the history (sorry). Should we also set iommu_platform
>>>>> for virtio-ccw? Halil?
>>>>>
>>>>
>>>> That line should add iommu_platform for all virtio devices, shouldn't
>>>> it?
>>>
>>> Yes, sorry. Was misreading that with the line above. 
>>>
>>
>> I believe this is the best we can get. In a sense it is still a
>> pessimization,
> 
> I'm not really clear on what you're getting at here.

I think Halils point is that somebody might come up with a solution where things would
work even without iommu_platform. But as he said, still the best setting we can get
to cover all cases.