Re: [RFC PATCH v1 3/4] KVM: x86: nSVM: Implement support for nested Bus Lock Threshold

[Manali Shukla <manali.shukla@amd.com>]

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