[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhR5DHN+MTXX8v6LMWsQzKfpRefFwNO62hH+4iKiMpaSKiYvQ@mail.gmail.com>
Date: Wed, 14 Jan 2026 19:22:19 -0600
From: Sagi Shahar <sagis@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, Paolo Bonzini <pbonzini@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, Kiryl Shutsemau <kas@...nel.org>,
Rick Edgecombe <rick.p.edgecombe@...el.com>, Thomas Gleixner <tglx@...nel.org>,
Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev,
Vishal Annapurve <vannapurve@...gle.com>, Michael Roth <michael.roth@....com>
Subject: Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA
On Wed, Jan 14, 2026 at 3:48 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> +Mike
>
> On Wed, Jan 14, 2026, Sean Christopherson wrote:
> > On Wed, Jan 14, 2026, Xiaoyao Li wrote:
> > > On 1/14/2026 8:30 AM, Sagi Shahar wrote:
> > > So it needs to be
> > >
> > > if (vcpu->run->hypercall.ret == -EBUSY)
> > > tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
> > > else
> > > tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
> >
> > No, because assuming everything except -EBUSY translates to
> > TDVMCALL_STATUS_INVALID_OPERAND paints KVM back into the same corner its already
> > in. What I care most about is eliminating KVM's assumption that a non-zero
> > hypercall.ret means TDVMCALL_STATUS_INVALID_OPERAND.
> >
> > For the new ABI, I see two options:
> >
> > 1. Translate -errno as done in this patch.
> > 2. Propagate hypercall.ret directly to the TDVMCALL return code, i.e. let
> > userspace set any return code it wants.
> >
> > #1 has the downside of needing KVM changes and new uAPI every time a new return
> > code is supported.
> >
> > #2 has the downside of preventing KVM from establishing its own ABI around the
> > return code, and making the return code vendor specific. E.g. if KVM ever wanted
> > to do something in response to -EBUSY beyond propagating the error to the guest,
> > then we can't reasonably do that with #2.
> >
> > Whatever we do, I want to change snp_complete_psc_msr() and snp_complete_one_psc()
> > in the same patch, so that whatever ABI we establish is common to TDX and SNP.
> >
> > See also https://lore.kernel.org/all/Zn8YM-s0TRUk-6T-@google.com.
>
> Aha! Finally. I *knew* we had discussed this more recently. The SNP series to
> add KVM_EXIT_SNP_REQ_CERTS uses a similar pattern. Note its intentional use of
> positive values, because that's what userspace sees in errno. This code should
> do the same. Oh, and we need to choose between EAGAIN and EBUSY...
>
> switch (READ_ONCE(vcpu->run->snp_req_certs.ret)) {
> case 0:
> return snp_handle_guest_req(svm, control->exit_info_1,
> control->exit_info_2);
> case ENOSPC:
> vcpu->arch.regs[VCPU_REGS_RBX] = vcpu->run->snp_req_certs.npages;
> return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_INVALID_LEN);
> case EAGAIN:
> return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_BUSY);
> case EIO:
> return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_GENERIC);
> default:
> break;
> }
>
I think EAGAIN makes more sense semantically in this case. So
something like this?
- tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
+ if (vcpu->run->hypercall.ret == EAGAIN)
+ tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
+ else if (vcpu->run->hypercall.ret == EINVAL)
+ tdvmcall_set_return_code(vcpu,
TDVMCALL_STATUS_INVALID_OPERAND);
+ else
+ return -EINVAL;
+
>
> https://lore.kernel.org/all/20260109231732.1160759-2-michael.roth@amd.com
Powered by blists - more mailing lists