Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively

[Ross Lagerwall <ross.lagerwall@citrix.com>]

On 9/3/26 2:02 PM, Jan Beulich wrote:
> On 28.08.2026 16:19, Ross Lagerwall wrote:
>> Xen does not need to track when the TS or MP bits change so opt to
>> intercept CR0 writes selectively.
> 
> Not anymore, which may want expressing here (or else it looks as if this
> would have been possible from the start).
> 
>> Aside from potentially reducing a few
>> VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE
>> and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so
>> L1 never sees any CR0 writes.
> 
> Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if
> I'm not mistaken), ...
> 
>> @@ -2882,7 +2884,8 @@ void asmlinkage svm_vmexit_handler(void)
>>           break;
>>   
>>       case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
>> -    case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
>> +    case VMEXIT_CR1_WRITE ... VMEXIT_CR15_WRITE:
>> +    case VMEXIT_CR0_SEL_WRITE:
>>           if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn )
>>               svm_vmexit_do_cr_access(vmcb, regs);
>>           else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") )
> 
> ... we may still see VMEXIT_CR0_WRITE here (i.e. its handling cannot be
> removed).
> 

No, it shouldn't get here in that case. If L1 sets CR0_WRITE, it will enter
nestedsvm_check_intercepts() and then hit the NESTEDHVM_VMEXIT_INJECT case.

Ross