Petr reports:
(XEN) MMIO emulation failed (1): d12v1 64bit @ 0010:
fffff8057ba7dfbf -> 45 0f 20 c2 ...
during introspection.
This is MOV %cr8, which is wired up for hvm_mov_{to,from}_cr(); the VMExit
fastpaths, but not for the full emulation slowpaths.
Xen's handling of %cr8 turns out to be quite wrong. At a minimum, we need
storage for %cr8 separate to APIC_TPR, and to alter intercepts based on
whether the vLAPIC is enabled or not. But that's more work than there is time
for in the short term, so make a stopgap fix.
Extend hvmemul_{read,write}_cr() with %cr8 cases. Unlike hvm_mov_to_cr(),
hardware hasn't filtered out invalid values (#GP checks are ahead of
intercepts), so introduce X86_CR8_VALID_MASK.
Reported-by: Petr Beneš <w1benny@gmail.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit:
14fd9b5642cd4805b49fbe716bf2cd577e724169
master date: 2025-03-26 11:54:59 +0000
val = curr->arch.hvm.guest_cr[reg];
break;
+ case 8:
+ val = (vlapic_get_reg(vcpu_vlapic(curr), APIC_TASKPRI) & 0xf0) >> 4;
+ break;
+
default:
return X86EMUL_UNHANDLEABLE;
}
rc = hvm_set_cr4(val, true);
break;
+ case 8:
+ if ( val & ~X86_CR8_VALID_MASK )
+ {
+ rc = X86EMUL_EXCEPTION;
+ break;
+ }
+
+ vlapic_set_reg(vcpu_vlapic(curr), APIC_TASKPRI, val << 4);
+ rc = X86EMUL_OKAY;
+ break;
+
default:
rc = X86EMUL_UNHANDLEABLE;
break;
#define X86_CR4_CET 0x00800000 /* Control-flow Enforcement Technology */
#define X86_CR4_PKS 0x01000000 /* Protection Key Supervisor */
+#define X86_CR8_VALID_MASK 0xf
+
/*
* XSTATE component flags in XCR0 | MSR_XSS
*/