Re: [RFC PATCH 0/4] Confidential Guest Support: Introduce kvm_init() and kvm_reset() virtual functions

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 2/6/2024 10:19 PM, Daniel P. Berrangé wrote:
> On Tue, Feb 06, 2024 at 03:28:48AM -0500, Xiaoyao Li wrote:
>> This series is inspired and suggested by Daniel:
>> https://lore.kernel.org/qemu-devel/ZbfoQsEuv6_zwl3b@redhat.com/
>>
>> Currently, different confidential VMs in different architectures have
>> their own specific *_kvm_init() (and some have *_kvm_reset()) exposed
>> for KVM stuff when it's a confidential VM. e.g., sev_kmv_init() for x86
>> SEV, pef_kvm_init() and pef_kvm_reset() for PPC PEF, and s390_pv_init()
>> for s390 PV VMs.
>>
>> Introduce a generic .kvm_init() and .kvm_reset() functions in
>> ConfidentialGuestSupportClass, so that different cgs technologies in
>> different architectures can implement their own, while common interface
>> of cgs can be used.
>>
>> This RFC implements two helper functions confidential_guest_kvm_init()
>> and confidential_guest_kvm_reset() in Patch 1. In the following patches,
>> they are called in arch specific implementation. X86 will benefit more
>> for the generic implementation when TDX support is added.
>>
>> There is one step forward possible, that calling
>> confidential_guest_kvm_init() before kvm_arch_init() in kvm_int() in
>> accel/kvm/kvm-all.c. This way, each arch doesn't need to call in their
>> arch specific code.
>>
>> X86 fits it, however I'm not sure if ppc and s390 fit it as well.
>> Because currently, ppc calls it in machine->init()
>> and s390 calls in MachineClass->init(). I'm not sure if there is any
>> order dependency.
> 
> IIUC that s390 call is still a machine->init method, rather than
> class init.

I double check the code again. Only struct MachineClass has .init() 
function defined. And I find both ppc and s390 calls the 
confidential_guest_kvm_init() (or their specific cgs kvm_init()) inside 
their machine_class->init().

> I think this series is nice, but its up to the KVM maintainers
> to decide...
> 
> 
> With regards,
> Daniel