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. > 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.
