Hi Xiaoyao,

Thanks for reviewing my patches.

On 4/16/2025 11:44 AM, Xiaoyao Li wrote:
> On 3/24/2025 9:02 PM, Manali Shukla wrote:
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 5fe84f2427b5..f7c925aa0c4f 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -7909,6 +7909,25 @@ apply some other policy-based mitigation. When 
>> exiting to userspace, KVM sets
>>   KVM_RUN_X86_BUS_LOCK in vcpu-run->flags, and conditionally sets the 
>> exit_reason
>>   to KVM_EXIT_X86_BUS_LOCK.
>>   +Note! KVM_CAP_X86_BUS_LOCK_EXIT on AMD CPUs with the Bus Lock Threshold 
>> is close
>> +enough  to INTEL's Bus Lock Detection VM-Exit to allow using
>> +KVM_CAP_X86_BUS_LOCK_EXIT for AMD CPUs.
>> +
>> +The biggest difference between the two features is that Threshold (AMD 
>> CPUs) is
>> +fault-like i.e. the bus lock exit to user space occurs with RIP pointing at 
>> the
>> +offending instruction, whereas Detection (Intel CPUs) is trap-like i.e. the 
>> bus
>> +lock exit to user space occurs with RIP pointing at the instruction right 
>> after
>> +the guilty one.
>>
> 
> 
>> +The bus lock threshold on AMD CPUs provides a per-VMCB counter which is
>> +decremented every time a bus lock occurs, and a VM-Exit is triggered if and 
>> only
>> +if the bus lock counter is '0'.
>> +
>> +To provide Detection-like semantics for AMD CPUs, the bus lock counter has 
>> been
>> +initialized to '0', i.e. exit on every bus lock, and when re-executing the
>> +guilty instruction, the bus lock counter has been set to '1' to effectively 
>> step
>> +past the instruction.
> 
> From the perspective of API, I don't think the last two paragraphs matter 
> much to userspace.
> 
> It should describe what userspace can/should do. E.g., when exit to userspace 
> due to bus lock on AMD platform, the RIP points at the instruction which 
> causes the bus lock. Userspace can advance the RIP itself before re-enter the 
> guest to make progress. If userspace doesn't change the RIP, KVM internal can 
> handle it by making the re-execution of the instruction doesn't trigger bus 
> lock VM exit to allow progress.

Sure.

-Manali


Reply via email to