| Message ID | 20240206082852.3333299-1-xiaoyao.li@intel.com |
|---|---|
| Headers | show |
| Series | Confidential Guest Support: Introduce kvm_init() and kvm_reset() virtual functions | expand |
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 think this series is nice, but its up to the KVM maintainers to decide... With regards, Daniel
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