Hi, > Also seeing that regenerating tables every time helps, > it hints that PCI subsystem is not configured when tables read 1st time.
This is the case. > Main conditions to get acpi blob representing is that they should be read > after guest firmware enumerated/configured PCI subsystem and > firmware should use BIOSlinker workflow to load/postprocess > tables otherwise all bets are off (even if this series works for now, > it's subject to break without notice since user doesn't follow proper > procedures for reading/processing ACPI blob). > Hence I dislike this approach. Well, the use case which needs this is a confidential VM with SVSM. So the SVSM firmware is the first thing which boots, sets up SVSM and the services it provides (vTPM, in the future UEFI variable store), then goes boot OVMF firmware which handles PCI initialization etc. SVSM needs to know the SMP configuration, but it does not even look at the PCI bus. The MADT is static: Nothing in there changes if the guest changes hardware registers (such as pci bridge windows), nothing requires the bios linker for cross-table references. Given that I fail to see how this can possibly break in the future. > Alternatively, instead of ACPI tables one can use FW_CFG_MAX_CPUS > like old SeaBIOS used to do if all you need is APIC IDs. > Limitation of this approach is that one can't use sparse APIC ID > configs. Thats why the idea is to just use the MADT table for SMP discovery. The APIC IDs are in there, and it also removes qemu-specific code from SVSM. take care, Gerd
