Re: [PATCH v6 09/60] i386/tdx: Initialize TDX before creating TD vcpus

[Tony Lindgren]

On Thu, Dec 12, 2024 at 11:24:03AM -0600, Ira Weiny wrote:
> On Wed, Nov 06, 2024 at 07:13:56AM +0200, Tony Lindgren wrote:
> > On Wed, Nov 06, 2024 at 10:01:04AM +0800, Xiaoyao Li wrote:
> > > On 11/6/2024 4:51 AM, Edgecombe, Rick P wrote:
> > > > +Tony
> > > > 
> > > > On Tue, 2024-11-05 at 01:23 -0500, Xiaoyao Li wrote:
> > > > > +int tdx_pre_create_vcpu(CPUState *cpu, Error **errp)
> > > > > +{
> > > > > +    X86CPU *x86cpu = X86_CPU(cpu);
> > > > > +    CPUX86State *env = &x86cpu->env;
> > > > > +    g_autofree struct kvm_tdx_init_vm *init_vm = NULL;
> > > > > +    int r = 0;
> > > > > +
> > > > > +    QEMU_LOCK_GUARD(&tdx_guest->lock);
> > > > > +    if (tdx_guest->initialized) {
> > > > > +        return r;
> > > > > +    }
> > > > > +
> > > > > +    init_vm = g_malloc0(sizeof(struct kvm_tdx_init_vm) +
> > > > > +                        sizeof(struct kvm_cpuid_entry2) * 
> > > > > KVM_MAX_CPUID_ENTRIES);
> > > > > +
> > > > > +    r = setup_td_xfam(x86cpu, errp);
> > > > > +    if (r) {
> > > > > +        return r;
> > > > > +    }
> > > > > +
> > > > > +    init_vm->cpuid.nent = kvm_x86_build_cpuid(env, 
> > > > > init_vm->cpuid.entries, 0);
> > > > > +    tdx_filter_cpuid(&init_vm->cpuid);
> > > > > +
> > > > > +    init_vm->attributes = tdx_guest->attributes;
> > > > > +    init_vm->xfam = tdx_guest->xfam;
> > > > > +
> > > > > +    do {
> > > > > +        r = tdx_vm_ioctl(KVM_TDX_INIT_VM, 0, init_vm);
> > > > > +    } while (r == -EAGAIN);
> > > > 
> > > > KVM_TDX_INIT_VM can also return EBUSY. This should check for it, or KVM 
> > > > should
> > > > standardize on one for both conditions. In KVM, both cases handle
> > > > TDX_RND_NO_ENTROPY, but one tries to save some of the initialization 
> > > > for the
> > > > next attempt. I don't know why userspace would need to differentiate 
> > > > between the
> > > > two cases though, which makes me think we should just change the KVM 
> > > > side.
> > > 
> > > I remember I tested retrying on the two cases and no surprise showed.
> > > 
> > > I agree to change KVM side to return -EAGAIN for the two cases.
> > 
> > OK yeah let's patch KVM for it.
> 
> Will the patch to KVM converge such that it is ok for qemu to loop forever?

Hmm I don't think we should loop forever anywhere, the retries needed should
be only a few. Or what do you have in mind?

Regards,

Tony