| Message ID | 20250311122235.61656-1-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] x86/msr: expose MSR_FAM10H_MMIO_CONF_BASE on AMD | expand |
On 11.03.2025 13:22, Roger Pau Monne wrote: > The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems. > Linux pre-6.14 is unconditionally attempting to read the MSR without a > safe MSR accessor, and since Xen doesn't allow access to it Linux reports > the following error: > > unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) > Call Trace: > xen_read_msr+0x1e/0x30 > amd_get_mmconfig_range+0x2b/0x80 > quirk_amd_mmconfig_area+0x28/0x100 > pnp_fixup_device+0x39/0x50 > __pnp_add_device+0xf/0x150 > pnp_add_device+0x3d/0x100 > pnpacpi_add_device_handler+0x1f9/0x280 > acpi_ns_get_device_callback+0x104/0x1c0 > acpi_ns_walk_namespace+0x1d0/0x260 > acpi_get_devices+0x8a/0xb0 > pnpacpi_init+0x50/0x80 > do_one_initcall+0x46/0x2e0 > kernel_init_freeable+0x1da/0x2f0 > kernel_init+0x16/0x1b0 > ret_from_fork+0x30/0x50 > ret_from_fork_asm+0x1b/0x30 > > Such access is conditional to the presence of a device with PnP ID > "PNP0c01", which triggers the execution of the quirk_amd_mmconfig_area() > function. Note that prior to commit 3fac3734c43a MSR accesses when running > as a PV guest would always use the safe variant, and thus silently handle > the #GP. > > Fix by allowing access to the MSR on AMD systems for the hardware domain. > > Write attempts to the MSR will still result in #GP for all domain types. > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Just to record that I'm also fine with it this way: Reviewed-by: Jan Beulich <jbeulich@suse.com> Jan
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 1550fd9ec9f3..2cd46b6c8afa 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -318,6 +318,14 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) *val = 0; break; + case MSR_FAM10H_MMIO_CONF_BASE: + if ( !is_hardware_domain(d) || + !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || + rdmsr_safe(msr, *val) ) + goto gp_fault; + + break; + case MSR_VIRT_SPEC_CTRL: if ( !cp->extd.virt_ssbd ) goto gp_fault;
The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems. Linux pre-6.14 is unconditionally attempting to read the MSR without a safe MSR accessor, and since Xen doesn't allow access to it Linux reports the following error: unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Call Trace: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Such access is conditional to the presence of a device with PnP ID "PNP0c01", which triggers the execution of the quirk_amd_mmconfig_area() function. Note that prior to commit 3fac3734c43a MSR accesses when running as a PV guest would always use the safe variant, and thus silently handle the #GP. Fix by allowing access to the MSR on AMD systems for the hardware domain. Write attempts to the MSR will still result in #GP for all domain types. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Changes since v2: - #GP on domU accesses. Changes since v1: - Expand commit message to note which device triggers the MSR read. --- xen/arch/x86/msr.c | 8 ++++++++ 1 file changed, 8 insertions(+)