search for: max_physical_apicid

Hi, on a Nehalem system with VT-d enabled we are seeing strange ACPI-Table contents, especially a corrupted DMAR entry. The hypervisor shows following data on boot: (XEN) ACPI: RSDP 000F80E0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT BF7C469E, 00D4 (r1 PTLTD XSDT 60000 LTP 0) (XEN) ACPI: FACP BF7C9CC9, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240) (XEN) ACPI: DSDT BF7C4772, 54D3 (r1

...(void); struct x86_legacy_features legacy; void (*set_legacy_features)(void); + struct x86_hyper_runtime hyper; }; struct pci_dev; --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1645,7 +1645,7 @@ static __init void try_to_enable_x2apic( * under KVM */ if (max_physical_apicid > 255 || - !hypervisor_x2apic_available()) { + !x86_init.hyper.x2apic_available()) { pr_info("x2apic: IRQ remapping doesn't support X2APIC mode\n"); x2apic_disable(); return; --- a/arch/x86/kernel/cpu/hypervisor.c +++ b/arch/x86/kernel/cpu/hypervisor.c @@ -44,...

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing