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é <[email protected]>
Just to record that I'm also fine with it this way: Reviewed-by: Jan Beulich <[email protected]> Jan
