On 8/26/2024 9:45 PM, Sean Christopherson wrote: > 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. Yeah. > >> 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. > When the bus_lock_counter is set to '1' and a bus lock is generated in the guest, the counter is decremented to '0', triggering a bus lock exit immediately. So, bus lock exit is triggered for every generated bus locks in the guest when bus_lock_counter value is set to '1'. > 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. Sure I will document it. - Manali
