Add support for enabling Secure Encrypted Virtualization in the GUI

[Charles Arnold]

On 4/20/22 7:17 AM, Daniel P. Berrangé wrote:
> On Wed, Apr 20, 2022 at 09:11:27AM -0400, Cole Robinson wrote:
>> On 4/19/22 1:21 PM, Daniel P. Berrangé wrote:
>>> On Tue, Apr 19, 2022 at 12:05:29PM -0400, Cole Robinson wrote:
>>>> On 4/4/22 11:49 AM, Charles Arnold wrote:
>>>>>
>>>>> On 4/4/22 6:50 AM, Daniel P. Berrangé wrote:
>>>>>> On Fri, Apr 01, 2022 at 12:13:17PM -0600, Charles Arnold wrote:
>>>>>>>   From d700e8cee7cd525c0022b5a9a440f64c4ab149f0 Mon Sep 17 00:00:00 2001
>>>>>>> From: Charles Arnold <carnold at suse.com>
>>>>>>> Date: Fri, 1 Apr 2022 12:01:21 -0600
>>>>>>> Subject: [PATCH 1/1] Add support for enabling Secure Encrypted
>>>>>>> Virtualization
>>>>>>>    in the GUI
>>>>>>>
>>>>>>> Add an "Enable Launch Security" checkbox on the Details memory tab.
>>>>>>> Do the minimal configuration required for libvirt to enable this feature
>>>>>>> on compatible hardware.
>>>>>>>
>>>>>> Don't we need to turn on the 'iommu' option for all virtio devices
>>>>>> too, and disable PXE on any NICs ?
>>>>>>
>>>>>> https://libvirt.org/kbase/launch_security_sev.html#virtio
>>>>>>
>>>>> I used to enumerate through the virtio devices in an old version of this
>>>>> patch
>>>>> for virt-manager and enable iommu but it really wasn't reasonable for
>>>>> virt-manager to track which virtio devices needed iommu enabled.
>>>>> Additionally,
>>>>> libvirt will sometimes add a device when a VM is created. This patch
>>>>> leans on libvirt to do the right thing when sev is enabled similar to what
>>>>> happens when launch security is specified on the virt-install command line.
>>>>>
>>>> Yeah, I would still like to see libvirt do this unless there's a good
>>>> reason why it can't. From my July 2020 mail
>>>> https://listman.redhat.com/archives/virt-tools-list/2020-July/017087.html
>>>>
>>>>> if sev
>>>>> launchSecurity _requires_ every virtio device to have iommu='on' then
>>>>> libvirt should be setting that itself. It doesn't need to hardcode it
>>>>> into the XML, it can set it at VM startup time. If the user set an
>>>>> explicit value in the XML then honor that but otherwise fill it in at
>>>>> runtime when it is required. Trying to deal with this in an app where we
>>>>> want to advertise turning the config off is basically an impossible
>>>>> problem to know if we are going to undo any explicit user config or not.
>>>> danpb does this sound reasonable? If so I can work on this.
>>> Something automagic sounds ok
>>>
>>>> Also, anyone know if TDX and SNP will require virtio iommu setting as well?
>>> I expect SNP will, but no idea about TDX.
>>>
>> So apparently qemu 6.0.0+ already does this for us:
>> https://gitlab.com/qemu-project/qemu/-/commit/9f88a7a3df
>>
>> Which is strange because some of my sev testing definitely failed with
>> an iommu sounding error in the guest kernel until I enabled iommu on
>> virtio-blk, but I can't reproduce now. Maybe I was using an older qemu,
>> I think the host was fedora 34 at the time
> Or you had new QEMU, but the guest was fixed on the older machine
> type perhaps

FWIW, the versions I'm testing with are,
libvirt 8.0.0
qemu 6.2.0
virt-manager 4.0.0

- Charles