On 20.03.2024 09:52, Roger Pau Monné wrote: > On Tue, Jan 09, 2024 at 03:38:32PM +0000, Alejandro Vallejo wrote: >> As part of topology correction efforts, APIC IDs can no longer be derived >> strictly through the vCPU ID alone. Bring in the machinery for policy >> retrieval and parsing in order to generate the proper MADT table and wake >> the appropriate CPUs. > > I'm kind of unsure about this last part of the sentence, as I see no > waking of CPUs in hvmloader. Is this referring to something else? > > I'm kind of unsure about bringing the cpu_policy machinery to > hvmloader.
I share this concern and ... > Won't it be simpler to just pass the array of APIC IDs in > hvm_info_table? The current size of this struct is 48bytes, and an > array of 128 32bit integers would be an additional 512bytes. > > AFAICT there's plenty of room in hvm_info_table, it's > positioned at 0x9f800, and there's unused space up to 0x9fc00, so 1024 > bytes of memory we could use. > > I know this doesn't give us much room for expansion if we want to bump > past 128 vCPUs, but a more appropriate solution IMO would be to move > ACPI table creation to the toolstack. > > It's possible I'm missing some aspects, so if this has been considered > and rejected would be good to note in the commit message. ... it being at least clarified whether alternatives were considered and why they cannot / should not be used. Jan
