Messages in this thread | | | Date | Thu, 24 Feb 2022 19:04:32 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests |
| |
On Thu, Feb 24, 2022, Dave Hansen wrote: > On 2/24/22 07:56, Kirill A. Shutemov wrote: > > diff --git a/arch/x86/coco/tdx.c b/arch/x86/coco/tdx.c > > index 0a2e6be0cdae..89992593a209 100644 > > --- a/arch/x86/coco/tdx.c > > +++ b/arch/x86/coco/tdx.c > > @@ -116,6 +116,44 @@ void __cpuidle tdx_safe_halt(void) > > WARN_ONCE(1, "HLT instruction emulation failed\n"); > > } > > > > +static bool read_msr(struct pt_regs *regs) > > +{ > > + struct tdx_hypercall_args args = { > > + .r10 = TDX_HYPERCALL_STANDARD, > > + .r11 = EXIT_REASON_MSR_READ, > > Just a minor note: these "EXIT_REASON_FOO"'s in r11 are effectively > *the* hypercall being made, right? > > The hypercall is being made in response to what would have otherwise > been a MSR read VMEXIT. But, it's a *bit* goofy to see them here when > the TDX guest isn't doing any kind of VMEXIT.
But the TDX guest is doing a VM-Exit, that's all TDCALL is, an exit to the host. r10 states that this is a GHCI-standard hypercall, r11 holds the reason why the guest is exiting to the host. The guest could pretty it up by redefining all the VM-Exit reasons as TDX_REQUEST_MSR_READ or whatever, but IMO diverging from directly using EXIT_REASON_* will be annoying in the long run, e.g. will make it more difficult to grep KVM + kernel to understand the end-to-end flow.
| |