qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v2 06/44] hw/i386: Introduce kvm-type for TDX guest


From: Xiaoyao Li
Subject: Re: [RFC PATCH v2 06/44] hw/i386: Introduce kvm-type for TDX guest
Date: Mon, 10 Jan 2022 20:01:33 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1

On 1/10/2022 7:18 PM, Daniel P. Berrangé wrote:
On Wed, Nov 24, 2021 at 03:31:13PM +0800, Xiaoyao Li wrote:
On 8/26/2021 6:22 PM, Gerd Hoffmann wrote:
On Wed, Jul 07, 2021 at 05:54:36PM -0700, isaku.yamahata@gmail.com wrote:
From: Xiaoyao Li <xiaoyao.li@intel.com>

Introduce a machine property, kvm-type, to allow the user to create a
Trusted Domain eXtensions (TDX) VM, a.k.a. a Trusted Domain (TD), e.g.:

   # $QEMU \
        -machine ...,kvm-type=tdx \
        ...

Sorry for the very late reply.

Can we align sev and tdx better than that?

SEV is enabled this way:

qemu -machine ...,confidential-guest-support=sev0 \
       -object sev-guest,id=sev0,...

(see docs/amd-memory-encryption.txt for details).

tdx could likewise use a tdx-guest object (and both sev-guest and
tdx-guest should probably have a common parent object type) to enable
and configure tdx support.

yes, sev only introduced a new object and passed it to
confidential-guest-support. This is because SEV doesn't require the new type
of VM.
However, TDX does require a new type of VM.

If we read KVM code, there is a parameter of CREATE_VM to pass the vm_type,
though x86 doesn't use this field so far. On QEMU side, it also has the
codes to pass/configure vm-type in command line. Of cousre, x86 arch doesn't
implement it. With upcoming TDX, it will implement and use vm type for TDX.
That's the reason we wrote this patch to implement kvm-type for x86, similar
to other arches.

yes, of course we can infer the vm_type from "-object tdx-guest". But I
prefer to just use vm_type. Let's see others opinion.

It isn't just SEV that is using the confidential-guest-support approach.
This was done for PPC64 and S390x too.  This gives QEMU a standard
internal interface to declare that a confidential guest is being used /
configured. IMHO, TDX needs to use this too, unless there's a compelling
technical reason why it is a bad approach & needs to diverge from every
other confidential guest impl in QEMU.


Forgot to tell the update that we went the direction to identify the TDX vm_type based on confidential-guest_support like below:


if (ms->cgs && object_dynamic_cast(OBJECT(ms->cgs), TYPE_TDX_GUEST)) {
        kvm_type = KVM_X86_TDX_VM;
} else {
        kvm_type = KVM_X86_DEFAULT_VM;
}


I think it's what you want, right?

BTW, the whole next version of TDX QEMU series should be released with next version of TDX KVM series. But I cannot tell the exact date yet.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]