[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YhfWwHE4nZfQWPCl@google.com>
Date: Thu, 24 Feb 2022 19:04:32 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
luto@...nel.org, peterz@...radead.org,
sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
pbonzini@...hat.com, sdeep@...are.com, tony.luck@...el.com,
vkuznets@...hat.com, wanpengli@...cent.com,
thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
linux-kernel@...r.kernel.org
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.
Powered by blists - more mailing lists