From: Peter Zijlstra <peterz@xxxxxxxxxxxxx> Sent: Wednesday, May 17, 2023 6:10 AM
>
> On Wed, May 17, 2023 at 05:55:45PM +0800, Tianyu Lan wrote:
> > On 5/16/2023 5:32 PM, Peter Zijlstra wrote:
> > > > --- a/arch/x86/entry/entry_64.S
> > > > +++ b/arch/x86/entry/entry_64.S
> > > > @@ -1019,6 +1019,15 @@ SYM_CODE_END(paranoid_entry)
> > > > * R15 - old SPEC_CTRL
> > > > */
> > > > SYM_CODE_START_LOCAL(paranoid_exit)
> > > > +#ifdef CONFIG_AMD_MEM_ENCRYPT
> > > > + /*
> > > > + * If a #HV was delivered during execution and interrupts were
> > > > + * disabled, then check if it can be handled before the iret
> > > > + * (which may re-enable interrupts).
> > > > + */
> > > > + mov %rsp, %rdi
> > > > + call check_hv_pending
> > > > +#endif
> > > > UNWIND_HINT_REGS
> > > > /*
> > > > @@ -1143,6 +1152,15 @@ SYM_CODE_START(error_entry)
> > > > SYM_CODE_END(error_entry)
> > > > SYM_CODE_START_LOCAL(error_return)
> > > > +#ifdef CONFIG_AMD_MEM_ENCRYPT
> > > > + /*
> > > > + * If a #HV was delivered during execution and interrupts were
> > > > + * disabled, then check if it can be handled before the iret
> > > > + * (which may re-enable interrupts).
> > > > + */
> > > > + mov %rsp, %rdi
> > > > + call check_hv_pending
> > > > +#endif
> > > > UNWIND_HINT_REGS
> > > > DEBUG_ENTRY_ASSERT_IRQS_OFF
> > > > testb $3, CS(%rsp)
> > > Oh hell no... do now you're adding unconditional calls to every single
> > > interrupt and nmi exit path, with the grand total of 0 justification.
> > >
> >
> > Sorry to Add check inside of check_hv_pending(). Will move the check before
> > calling check_hv_pending() in the next version. Thanks.
>
> You will also explain, in the Changelog, in excruciating detail, *WHY*
> any of this is required.
>
> Any additional code in these paths that are only required for some
> random hypervisor had better proof that they are absolutely required and
> no alternative solution exists and have no performance impact on normal
> users.
>
> If this is due to Hyper-V design idiocies over something fundamentally
> required by the hardware design you'll get a NAK.
I'm jumping in to answer some of the basic questions here. Yesterday,
there was a discussion about nested #HV exceptions, so maybe some of
this is already understood, but let me recap at a higher level, provide some
references, and suggest the path forward.
This code and some of the other patches in this series are for handling the
#HV exception that is introduced by the Restricted Interrupt Injection
feature of the SEV-SNP architecture. See Section 15.36.16 of [1], and
Section 5 of [2]. There's also an AMD presentation from LPC last fall [3].
Hyper-V requires that the guest implement Restricted Interrupt Injection
to handle the case of a compromised hypervisor injecting an exception
(and forcing the running of that exception handler), even when it should
be disallowed by guest state. For example, the hypervisor could inject an
interrupt while the guest has interrupts disabled. In time, presumably other
hypervisors like KVM will at least have an option where they expect SEV-SNP
guests to implement Restricted Interrupt Injection functionality, so it's
not Hyper-V specific.
Naming the new exception as #HV and use of "hv" as the Linux prefix
for related functions and variable names is a bit unfortunate. It
conflicts with the existing use of the "hv" prefix to denote Hyper-V
specific code in the Linux kernel, and at first glance makes this code
look like it is Hyper-V specific code. Maybe we can choose a different
prefix ("hvex"?) for this #HV exception related code to avoid that
"first glance" confusion.
I've talked with Tianyu offline, and he will do the following:
1) Split this patch set into two patch sets. The first patch set is Hyper-V
specific code for managing communication pages that must be shared
between the guest and Hyper-V, for starting APs, etc. The second patch
set will be only the Restricted Interrupt Injection and #HV code.
2) For the Restricted Interrupt Injection code, Tianyu will look at
how to absolutely minimize the impact in the hot code paths,
particularly when SEV-SNP is not active. Hopefully the impact can
be a couple of instructions at most, or even less with the use of
other existing kernel techniques. He'll look at the other things you've
commented on and get the code into a better state. I'll work with
him on writing commit messages and comments that explain what's
going on.
Michael
[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://www.amd.com/system/files/TechDocs/56421-guest-hypervisor-communication-block-standardization.pdf
[3] https://lpc.events/event/16/contributions/1321/attachments/965/1886/SNP_Interrupt_Security.pptx
