On 11/16/22 09:44, Santosh Shukla wrote:
Hello Maxim,.
On 11/16/2022 2:51 PM, Maxim Levitsky wrote:
On Wed, 2022-11-16 at 11:10 +0530, Santosh Shukla wrote:
Hi Maxim,
On 11/14/2022 8:01 PM, Maxim Levitsky wrote:
On Mon, 2022-11-14 at 13:32 +0530, Santosh Shukla wrote:
On 10/27/2022 2:08 PM, Santosh Shukla wrote:
VNMI Spec is at [1].
Change History:
v5 (6.1-rc2)
01,02,06 - Renamed s/X86_FEATURE_V_NMI/X86_FEATURE_AMD_VNMI (Jim Mattson)
Gentle reminder.
Thanks,
Santosh
I started reviewing it today and I think there are still few issues,
and the biggest one is that if a NMI arrives while vNMI injection
is pending, current code just drops such NMI.
We had a discussion about this, like forcing immeditate vm exit
I believe, We discussed above case in [1] i.e.. HW can handle
the second (/pending)virtual NMI while the guest processing first virtual NMI w/o vmexit.
is it same scenario or different one that you are mentioning?
[1] https://lore.kernel.org/lkml/1782cdbb-8274-8c3d-fa98-29147f1e5d1e@xxxxxxx/>>
You misunderstood the issue.
Hardware can handle the case when a NMI is in service (that is V_NMI_MASK is set) and another one is injected
(V_NMI_PENDING can be set),
but it is not possible to handle the case when a NMI is already injected (V_NMI_PENDING set) but
and KVM wants to inject another one before the first one went into the service (that is V_NMI_MASK is not set
yet).
In this case, HW will collapse the NMI.
Note that the HW will take the pending NMI at the boundary of IRET instruction such that
it will check for the V_NMI_PENDING and if its set then HW will *take* the NMI,
HW will clear the V_NMI_PENDING bit and set the V_NMI_MASK w/o the VMEXIT!,.
Also same can happen when NMIs are blocked in SMM, since V_NMI_MASK is set despite no NMI in service,
we will be able to inject only one NMI by setting the V_NMI_PENDING.
Ditto,. HW will collapse the NMI.
Note, this is how bare-metal NMIs are also handled. Multiple NMIs are
collapsed into a single NMI if they are received while an NMI is currently
being processed.
Thanks,
Tom
Thanks,
Santosh
I think I was able to solve all these issues and I will today post a modified patch series of yours,
which should cover all these cases and have some nice refactoring as well.
Best regards,
Maxim Levitsky
Thanks,
Santosh
in this case and such but I have a simplier idea:
In this case we can just open the NMI window in the good old way
by intercepting IRET, STGI, and or RSM (which is intercepted anyway),
and only if we already *just* intercepted IRET, only then just drop
the new NMI instead of single stepping over it based on reasoning that
its 3rd NMI (one is almost done the servicing (its IRET is executing),
one is pending injection, and we want to inject another one.
Does this sound good to you? It won't work for SEV-ES as it looks
like it doesn't intercept IRET, but it might be a reasonable tradeof
for SEV-ES guests to accept that we can't inject a NMI if one is
already pending injection.
Best regards,
Maxim Levitsky
