On 16.05.2023 02:11, Stefano Stabellini wrote: > On Mon, 15 May 2023, Roger Pau Monné wrote: >> On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote: >>> From: Stefano Stabellini <stefano.stabell...@amd.com> >>> >>> Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of >>> the tables in the guest. Instead, copy the tables to Dom0. >>> >>> This is a workaround. >>> >>> Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com> >>> --- >>> As mentioned in the cover letter, this is a RFC workaround as I don't >>> know the cause of the underlying problem. I do know that this patch >>> solves what would be otherwise a hang at boot when Dom0 PVH attempts to >>> parse ACPI tables. >> >> I'm unsure how safe this is for native systems, as it's possible for >> firmware to modify the data in the tables, so copying them would >> break that functionality. >> >> I think we need to get to the root cause that triggers this behavior >> on QEMU. Is it the table checksum that fail, or something else? Is >> there an error from Linux you could reference? > > I agree with you but so far I haven't managed to find a way to the root > of the issue. Here is what I know. These are the logs of a successful > boot using this patch: > > [ 10.437488] ACPI: Early table checksum verification disabled > [ 10.439345] ACPI: RSDP 0x000000004005F955 000024 (v02 BOCHS ) > [ 10.441033] ACPI: RSDT 0x000000004005F979 000034 (v01 BOCHS BXPCRSDT > 00000001 BXPC 00000001) > [ 10.444045] ACPI: APIC 0x0000000040060F76 00008A (v01 BOCHS BXPCAPIC > 00000001 BXPC 00000001) > [ 10.445984] ACPI: FACP 0x000000004005FA65 000074 (v01 BOCHS BXPCFACP > 00000001 BXPC 00000001) > [ 10.447170] ACPI BIOS Warning (bug): Incorrect checksum in table [FACP] - > 0x67, should be 0x30 (20220331/tbprint-174)
With this line I wouldn't really call it a "successful boot". > [ 10.449522] ACPI: DSDT 0x000000004005FB19 00145D (v01 BOCHS BXPCDSDT > 00000001 BXPC 00000001) > [ 10.451258] ACPI: FACS 0x000000004005FAD9 000040 > [ 10.452245] ACPI: Reserving APIC table memory at [mem > 0x40060f76-0x40060fff] > [ 10.452389] ACPI: Reserving FACP table memory at [mem > 0x4005fa65-0x4005fad8] > [ 10.452497] ACPI: Reserving DSDT table memory at [mem > 0x4005fb19-0x40060f75] > [ 10.452602] ACPI: Reserving FACS table memory at [mem > 0x4005fad9-0x4005fb18] > > > And these are the logs of the same boot (unsuccessful) without this > patch: > > [ 10.516015] ACPI: Early table checksum verification disabled > [ 10.517732] ACPI: RSDP 0x0000000040060F1E 000024 (v02 BOCHS ) > [ 10.519535] ACPI: RSDT 0x0000000040060F42 000034 (v01 BOCHS BXPCRSDT > 00000001 BXPC 00000001) > [ 10.522523] ACPI: APIC 0x0000000040060F76 00008A (v01 BOCHS BXPCAPIC > 00000001 BXPC 00000001) > [ 10.527453] ACPI: ���� 0x000000007FFE149D FFFFFFFF (v255 ������ �������� > FFFFFFFF ���� FFFFFFFF) By instrumenting the kernel a little, it shouldn't be difficult to spot where this bogus address is coming from. Inspecting the relevant tables right before Dom0 actually starts and then again slightly later (perhaps triggered by Dom0 itself, again via slight instrumentation) from Xen should also be possible. I kind of expect they're going to be okay right after construction, and become corrupted subsequently. Did you check that the E820 table properly covers the ACPI table range(s)? Jan
