[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBs/sSJwr7zdOUsE@google.com>
Date: Wed, 22 Mar 2023 10:49:37 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Xin Li <xin3.li@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, peterz@...radead.org,
andrew.cooper3@...rix.com, pbonzini@...hat.com,
ravi.v.shankar@...el.com
Subject: Re: [PATCH v5 34/34] KVM: x86/vmx: execute "int $2" to handle NMI in
NMI caused VM exits when FRED is enabled
On Mon, Mar 06, 2023, Xin Li wrote:
> Execute "int $2" to handle NMI in NMI caused VM exits when FRED is enabled.
>
> Like IRET for IDT, ERETS/ERETU are required to end the NMI handler for FRED
> to unblock NMI ASAP (w/ bit 28 of CS set).
That's "CS" on the stack correct? Is bit 28 set manually by software, or is it
set automatically by hardware? If it's set by hardware, does "int $2" actually
set the bit since it's not a real NMI?
> And there are 2 approaches to
> invoke the FRED NMI handler:
> 1) execute "int $2", let the h/w do the job.
> 2) create a FRED NMI stack frame on the current kernel stack with ASM,
> and then jump to fred_entrypoint_kernel in arch/x86/entry/entry_64_fred.S.
>
> 1) is preferred as we want less ASM.
Who is "we", and how much assembly are we talking about? E.g. I personally don't
mind a trampoline in KVM if it's small and/or can share code with existing
assembly subroutines.
Powered by blists - more mailing lists