Re: [PATCH 2/2] KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated

[Tom Lendacky]

On 3/10/26 17:40, Sean Christopherson wrote:
> On Tue, Mar 10, 2026, Tom Lendacky wrote:
>> On 3/10/26 16:58, Sean Christopherson wrote:
>>> On Tue, Mar 10, 2026, Tom Lendacky wrote:
>>>> On 3/10/26 13:35, Sean Christopherson wrote:
>>>>> On Tue, Mar 10, 2026, Tom Lendacky wrote:
>>>>>> I'm just saying that the unconditional trap for CR8_WRITE isn't flawed
>>>>>> for SEV-ES+ because AVIC can't work with SEV, so there isn't any time
>>>>>> that CR8 writes shouldn't be trapped.
>>>>>
>>>>> Yeah, I forgot that (obviously).
>>>>>
>>>>> But sync_cr8_to_lapic() is very broken, no?  INTERCEPT_CR8_WRITE will never be
>>>>> set, and svm->vmcb->control.int_ctl will become stale as soon as the VMSA is
>>>>> live, and so in all likelihood KVM is crushing CR8 to zero for SEV-ES guests.
>>>>
>>>> I don't think so. V_TPR is written on #VMEXIT even for SEV-ES+ guests,
>>>> and since it is a trap, CR8 is set and so V_TPR should have that value.
>>>> That would imply sync_cr8_to_lapic() should do the right thing.
>>>
>>> But isn't svm->vmcb->control.int_ctl stale?  Oh.  "control", not "save".  /facepalm
>>>
>>> Ah, and I assume Secure AVIC hides vTPR from the host?  Or at least prevents the
>>> host from setting it?
>>
>> Secure AVIC will prevent the host from setting it since the backing page
>> lives in guest memory and is encrypted/private.
> 
> What about vmcb->control.int_ctl though?  IIUC, that's the source of truth for
> the effective vTPR, not the value in the virtual APIC page.

For Secure AVIC, V_TPR from the vmcb->control.int_ctl isn't used,
instead it is saved to and restored from the VMSA. The APM should
probably be updated to be clear about that.

> 
>>>> After attempting to verify this behavior it turns out that writes to CR8
>>>> (and CR2) are, in fact, not trapped, but the APM was not updated with
>>>> this information (I'll send a patch to remove that code). KVM's CR8
>>>> value is, however, synced with the proper value through
>>>> sync_cr8_to_lapic() because V_TPR in the VMCB is updated on #VMEXIT.
>>>
>>> Oh.  Huh.  So doesn't that mean that supporting Windows (or any other guest that
>>> uses TPR to mask interrupts) as an SEV-ES guest is practically impossible?  Because
>>> while KVM can observe and manipulate guest CR8, KVM won't be able to precisely
>>> detect when TPR drops below a pending IRQ.
>>
>> Could we do something with virtual interrupt support? Today KVM uses the
>> virtual interrupt control to detect when an IRQ window opens. We could
>> do something similar by setting up the virtual interrupt priority,
>> V_INTR_PRIO, at the level of the current TPR/CR8 level. When the TPR
>> drops, that would trigger a #VMEXIT and allow the pending IRQ to be
>> injected. Thoughts?
> 
> Uh, yes, that would work?  I was thinking we couldn't model the priority, but
> obviously that's not true.
> 
> FWIW, my preference would be to not add support unless someone asks for it :-)

Agreed.

Thanks,
Tom