[svsm-devel] Clear the guest busy bit when Alternated Injection is enabled

[Jon Lange]

The SVSM should always be clearing the busy bit when it decides that it is safe to reenter the guest.  There should be no hypervisor control of when and how this happens.  If the hypervisor encounters a busy bit error, it should invoke the SVSM, which should take the correct action to return the guest to a runnable state (or should panic if it detects that a fatal error prevents the guest from being runnable again).

-Jon

From: Wang, Huibo <Huibo.Wang at amd.com>
Sent: Tuesday, April 15, 2025 8:17 AM
To: svsm-devel at coconut-svsm.dev
Cc: Jon Lange <jlange at microsoft.com>; Lendacky, Thomas <Thomas.Lendacky at amd.com>; Kaplan, David <David.Kaplan at amd.com>
Subject: [EXTERNAL] Clear the guest busy bit when Alternated Injection is enabled


[AMD Official Use Only - AMD Internal Distribution Only]

Hi,

I am currently working towards enabling Alternate Injection in Linux and Coconut SVSM.

When I start a guest, I hit a KVM internal error - VMEXIT_BUSY.  In guests that run with Alternate Injection, bit 63 of the encrypted VIntrCtrl field is defined as a BUSY bit. On VMRUN, if VIntrCtrl[BUSY] is set to 1, then the VMRUN fails with a VMEXIT_BUSY error code. The BUSY bit enables a VMSA to be temporarily marked non-runnable while software modifications are in progress.

When KVM is trying to deliver an interrupt or exception into the guest while a VMEXIT happens, then the busy bit gets set in the guest's VMSA. So VMPL0 needs to come in a re-inject the event to the guest.

To solve this problem, the HV should not wait for VMEXIT_BUSY.  If it sees that EXITINTINFO.V=1 on an exit and Alternate Injection is enabled, it should invoke VMPL0 to clear the busy bit and then ask to switch to run the guest which will keep running the interrupted interrupt/exception.

The question is how would we like the communication between HV and SVSM to look like when it comes to the HV letting the SVSM know that the guest's busy bit needs to get cleared before it runs again?

For example, should the HV explicitly set something in the HVDB page indicating that the SVSM should clear its guest's busy bit or should the SVSM itself always check the busy bit before running the guest and clear it if set?

Or any other, better idea?

Thanks,
Melody

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.8bytes.org/pipermail/svsm-devel/attachments/20250415/c5b3cb2a/attachment-0001.htm>