[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddabdb1f-9b33-4576-a47f-f19fe5ca6b7e@redhat.com>
Date: Thu, 15 Feb 2024 14:44:47 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Michael Roth <michael.roth@....com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, seanjc@...gle.com,
aik@....com, isaku.yamahata@...el.com
Subject: Re: [PATCH 09/10] KVM: SEV: introduce KVM_SEV_INIT2 operation
On 2/15/24 02:34, Michael Roth wrote:
>> + struct struct kvm_sev_init {
> Missing the vm_type param here.
It can go away in the struct actually. Also, "struct struct".
>> +If the ``KVM_X86_SEV_VMSA_FEATURES`` attribute does not exist, the hypervisor only
>> +supports KVM_SEV_INIT and KVM_SEV_ES_INIT. In that case the set of VMSA features is
>> +undefined.
>
> It's hard to imagine userspace implementation support for querying
> KVM_X86_SEV_VMSA_FEATURES but still insisting on KVM_SEV_INIT.
.. except for backwards compatibility with old kernels. For example,
the VMM could first invoke HAS_DEVICE_ATTR, and then fall back to
KVM_SEV_INIT after checking that the user did not explicitly request or
forbid one or more VMSA features.
> Maybe it
> would be better to just lock in that VMSA_FEATURES at what is currently
> supported: DEBUG_SWAP=on/off depending on the kvm_amd module param, and
> then for all other features require opt-in via KVM_SEV_INIT2, and then
> bake that into the documentation. That way way they could still reference
> this documentation to properly calculate measurements for older/existing
> VMM implementations.
Thinking more about it, I think all features including debug_swap should
be disabled with the old SEV_INIT/SEV_ES_INIT. Because the features
need to match between the VMM and the measurement calculation, they need
to be added explicitly on e.g. the QEMU command line.
Paolo
Powered by blists - more mailing lists