On Sat, Aug 24, 2024, Manali Shukla wrote: > > Actually, we already have a capability, which means there's zero reason for this > > module param to exist. Userspace already has to opt-in to turning on bus lock > > detection, i.e. userspace already has the opportunity to provide a different > > threshold. > > > > That said, unless someone specifically needs a threshold other than '0', I vote > > to keep the uAPI as-is and simply exit on every bus lock. > > > > According to APM [1], > "The VMCB provides a Bus Lock Threshold enable bit and an unsigned 16-bit Bus > Lock Threshold count. On VMRUN, this value is loaded into an internal count > register. Before the processor executes a bus lock in the guest, it checks > the value of this register. If the value is greater than 0, the processor > executes the bus lock successfully and decrements the count. If the value is > 0, the bus lock is not executed and a #VMEXIT to the VMM is taken." > > So, the bus_lock_counter value "0" always results in VMEXIT_BUSLOCK, so the > default value of the bus_lock_counter should be greater or equal to "1". Ugh, so AMD's bus-lock VM-Exit is fault-like. That's annoying. > I can remove the module parameter and initialize the value of > bus_lock_counter as "1" ? No, because that will have the effect of detecting every other bus lock, whereas the intent is to detect _every_ bus lock. I think the only sane approach is to set it to '0' when enabled, and then set it to '1' on a bus lock exit _before_ exiting to userspace. If userspace or the guest mucks with RIP or the guest code stream and doesn't immediately trigger the bus lock, then so be it. That only defers the allowed bus lock to a later time, so effectively such shenanigans would penalize the guest even more. We'll need to document that KVM on AMD exits to userspace with RIP pointing at the offending instruction, whereas KVM on Intel exits with RIP pointing at the instruction after the guilty instruction.
