RE: [PATCH v5 34/34] KVM: x86/vmx: execute "int $2" to handle NMI in NMI caused VM exits when FRED is enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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?

Right, It's the "CS" on the stack. The bit 28 is set by the FRED NMI handler:
https://lore.kernel.org/lkml/20230307023946.14516-20-xin3.li@xxxxxxxxx/

Upon a NMI delivery, the NMI bit is always set by H/W. However, "int $2" does
NOT set it, thus we need to explicitly set it.
 
> > 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.

I ever got such a comment:
https://lore.kernel.org/lkml/8735bpbhat.ffs@tglx/

However, if ASM is also okay, I can work on it.  And I don't think the ASM code
will be big.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux