On Tue Jan 20, 2026 at 3:32 PM CET, Jan Beulich wrote:
> On 20.01.2026 15:26, Andrew Cooper wrote:
>> On 20/01/2026 2:16 pm, Jan Beulich wrote:
>>> On 20.01.2026 15:11, Andrew Cooper wrote:
>>>> On 20/01/2026 1:34 pm, Jan Beulich wrote:
>>>>> On 20.01.2026 14:29, Andrew Cooper wrote:
>>>>>> On 20/01/2026 1:27 pm, Jan Beulich wrote:
>>>>>>> On 20.01.2026 14:18, Andrew Cooper wrote:
>>>>>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote:
>>>>>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>>>>>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>>>>>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v)
>>>>>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP
>>>>>>>>> |
>>>>>>>>> GENERAL2_INTERCEPT_RDPRU;
>>>>>>>>>
>>>>>>>>> + if ( cpu_has_bus_lock_thresh )
>>>>>>>>> + {
>>>>>>>>> + vmcb->_general3_intercepts =
>>>>>>>>> GENERAL3_INTERCEPT_BUS_LOCK_THRESH;
>>>>>>>> |=
>>>>>>>>
>>>>>>>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */
>>>>>>>> Really? The APM states:
>>>>>>>>
>>>>>>>> On processors that support Bus Lock Threshold (indicated by CPUID
>>>>>>>> Fn8000_000A_EDX[29] BusLockThreshold=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 according to the APM, setting the count to 1 will permit one bus
>>>>>>>> lock
>>>>>>>> then exit (fault style) immediately before the next. This also says
>>>>>>>> that a count of 0 is a legal state.
>>>>>>> But then you'd livelock the guest as soon as it uses a bus lock. Are you
>>>>>>> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at
>>>>>>> all other times?
>>>>>> I should have been clearer. I'm complaining at the "trigger
>>>>>> immediately" comment, because I don't think that's a correct statement
>>>>>> of how hardware behaves.
>>>>> In turn I should have looked at the patch itself before commenting. The
>>>>> other setting to 1 is what makes sense, and what ought to prevent a
>>>>> livelock. The one here indeed raises questions.
>>>> Setting it to 1 here is fine. This is the constructor for VMCBs, and
>>>> *something* needs to make the state consistent with the setting we chose
>>>> at runtime.
>>> But the setting at runtime is generally going to be 0
>>
>> First, we need clarity on what "Initialising as zero is invalid and
>> causes an immediate exit." means.
>
> +1
The exit is not an VMEXIT_INVALID, if that's your fear. Let me clarify:
The TL;DR is that the commit message is the unfortunate side effect of trying
to remember why I did something a while ago and not remembering very well.
Initialy I had zero at both the initialiser and the reset. That doesn't get
very far until you notice the behaviour is a fault and not a trap, which the APM
states as:
```
If the value is 0, the bus lock is not executed and a #VMEXIT to the VMM is
taken
```
Then in order to go past that boundary the reset must be set at 1, or the guest
loops. The initialisation may start at either (though zero would be more
consistent).
I guess over time I just internalised a bit too much "I can't exec vmrun with
a counter of 0".
I'll send a v2 with the initialiser set to zero and an amended commit message.
Cheers,
Alejandro
