On 6/6/2024 6:44 AM, Paolo Bonzini wrote:
There can be other confidential computing classes that are not derived from sev-common. Avoid aborting when encountering them.
I hit it today when rebasing TDX patches to latest QEMU master, which has the SEV-SNP series merged. (I didn't get time to review it between it gets merged.)
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- target/i386/sev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/i386/sev.c b/target/i386/sev.c index 004c667ac14..97e15f8b7a9 100644 --- a/target/i386/sev.c +++ b/target/i386/sev.c @@ -1710,7 +1710,9 @@ void sev_es_set_reset_vector(CPUState *cpu)
my approach is to guard with sev_enabled() when calling sev_es_set_reset_vector() in kvm_arch_reset_vcpu(), because calling sev* specific function in generic kvm code doesn't look reasonable to me.
{ X86CPU *x86; CPUX86State *env; - SevCommonState *sev_common = SEV_COMMON(MACHINE(qdev_get_machine())->cgs); + ConfidentialGuestSupport *cgs = MACHINE(qdev_get_machine())->cgs; + SevCommonState *sev_common = SEV_COMMON( + object_dynamic_cast(OBJECT(cgs), TYPE_SEV_COMMON));/* Only update if we have valid reset information */if (!sev_common || !sev_common->reset_data_valid) {
