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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 08/09/2026 9:44 am, Jan Beulich wrote:
> On 04.09.2026 14:23, Ross Lagerwall wrote:
>> @@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void)
>>      hvm_sanitize_regs_fields(
>>          regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l));
>>  
>> +    v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb);
>>      v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb);
>>      if ( paging_mode_hap(v->domain) )
>>          v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb);
> gitlab-CI says no to this patch [1], and I think it's the change above which
> gets in the way of running guests in shadow mode (as is the case for the two
> qemu-smoke-x86_64-*-pvh tests). svm_update_guest_cr() has
>
>         value = v->arch.hvm.guest_cr[0];
>         if ( paging_mode_shadow(v->domain) )
>             value |= X86_CR0_PG | X86_CR0_WP;
>         vmcb_set_cr0(vmcb, value);
>
> i.e. upon reading back the guest's CR0 value we would wrongly record it
> having PG (and WP) enabled, at which point shadow code would try to use the
> still-zero CR3 as page table base. I think values need merging here, with
> only TS and MP taken from what vmcb_get_cr0() returns.

Yes this is broken for Shadow.

Shadow shouldn't be trying to use CR0_WRITE_SEL.  What's in the VMCB is
unrelated to the guest's choice of value, and reverse engineering it is
fragile.

Use full CR0_WRITE for Shadow guests, and use CR0_WRITE_SEL for HAP only.

~Andrew