On 11/19/2024 9:53 PM, Michael Roth wrote: [...]
A few weeks back we discussed during the PUCK call on whether it makes sense for use a common exit type for REQ_CERTS and TDX_GET_QUOTE, and due to the asynchronous/polling nature of TDX_GET_QUOTE, and the somewhat-particular file-locking requirements that need to be built into the REQ_CERTS handling, we'd decided that it's probably more trouble than it's worth to try to merge the 2. However, I'm still hoping that KVM_EXIT_COCO might still provide some useful infrastructure for introducing something like KVM_EXIT_COCO_GET_QUOTE that implements the TDX-specific requirements more directly.
I am not sure it benefits much. Since the handling codes of REQ_CERTS and TDX_GET_QUOTE in userspace are quite different, i.e., there will be little common code to reuse, but it requires KVM to convert the error code from the KVM_EXIT_COCO version to vendor specific versions.
I've just submitted v2 of KVM_EXIT_COCO where the userspace-provided error codes are reworked to be less dependent on specific spec-defined values but instead relies on standard error codes that KVM can provide special handling for internally when needed: https://lore.kernel.org/kvm/20241119133513.3612633-1-michael.roth@xxxxxxx/ But I suppose in your case userspace would just return "SUCCESS"/0 and
According to GHCI spec, besides "TDG.VP.VMCALL_SUCCESS", there are two more error codes "TDG.VP.VMCALL_RETRY" and "TDG.VP.VMCALL_INVALID_OPERAND". "TDG.VP.VMCALL_RETRY" could cover EAGAIN. "TDG.VP.VMCALL_INVALID_OPERAND" could be used to cover the other errors returned, i.e., EIO and ENOSPC according to your proposal in v2.
then all the vendor-specific values are mainly in relation to the "Status Code" field so it likely doesn't make a huge difference as far as what userspace passes back to KVM. Thanks, Mike
[...]
