Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 May 2023 15:09:43 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Tianyu Lan <ltykernel@gmail.com>
Cc:     luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
        hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com,
        jgross@suse.com, tiala@microsoft.com, kirill@shutemov.name,
        jiangshan.ljs@antgroup.com, ashish.kalra@amd.com,
        srutherford@google.com, akpm@linux-foundation.org,
        anshuman.khandual@arm.com, pawan.kumar.gupta@linux.intel.com,
        adrian.hunter@intel.com, daniel.sneddon@linux.intel.com,
        alexander.shishkin@linux.intel.com, sandipan.das@amd.com,
        ray.huang@amd.com, brijesh.singh@amd.com, michael.roth@amd.com,
        thomas.lendacky@amd.com, venu.busireddy@oracle.com,
        sterritt@google.com, tony.luck@intel.com, samitolvanen@google.com,
        fenghua.yu@intel.com, pangupta@amd.com,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        linux-hyperv@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH V6 02/14] x86/sev: Add Check of #HV event in path
Message-ID: <20230517130943.GE2665450@hirez.programming.kicks-ass.net>
References: <20230515165917.1306922-1-ltykernel@gmail.com>
 <20230515165917.1306922-3-ltykernel@gmail.com>
 <20230516093225.GD2587705@hirez.programming.kicks-ass.net>
 <851f6305-2145-d756-91e3-55ab89bfcd42@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <851f6305-2145-d756-91e3-55ab89bfcd42@gmail.com>
Precedence: bulk

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.