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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

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