On 8/17/2024 1:35 AM, Sean Christopherson wrote: > On Tue, Jul 09, 2024, Manali Shukla wrote: >> Expose the Bus Lock Threshold in the guest CPUID and support its >> functionality in nested guest. > > Why? This is a rather messy feature to support in a nested setup, and I'd much > prefer to not open that can of worms unless there's a very good reason to do so. Agreed. > >> Ensure proper restoration and saving of the bus_lock_counter at VM >> Entry and VM Exit respectively in nested guest scenarios. >> >> Case 1: >> L0 supports buslock exit and L1 does not: use buslock counter from L0 >> and exits happen to L0 VMM. >> >> Case 2: >> Both L0 and L1 supports buslock exit: use L1 buslock counter value and >> exits happen to L1 VMM. > > Yeah, no. L1 wants to attack the host, so it runs L2 with buslock detection > enabled, but the highest possible threshold. Game over. > > If we take the min between the two, then we have to track the delta and shove > _that_ into the VMCB. E.g. L1 wants every 4, L0 wants every 5. After 4 locks, > KVM synthesizes a nested VM-Exit. Then on nested VMRUN, KVM needs to remember > it should run L2 with a threshold of 1. > > If we really want to support virtualizing bus lock detection for L1, the easiest > approach would be to do so if and only if it's NOT in use by L0. But IMO that's > not worth doing. I will drop the nested implementation in V2. -Manali
