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

[Jan Beulich <jbeulich@suse.com>]

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.

The zen2-* failure in [1] is, I think, unrelated.

Jan

[1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2828369624