On 28.01.2025 17:33, Alejandro Vallejo wrote:
> MP Tables have no means of representing APIC IDs wider than 255. At the
> moment the effect is wrapping around which would give a corrupted table
> with duplicate APIC IDs (some of them possibly the broadcast 255).
>
> Skip writing it altogether. While it would be possible to restrict the
> APs shown it's just not worth the work. Any OS that needs such
> adjustments should not have been booted with that many vCPUs to begin
> with.
>
> Signed-off-by: Alejandro Vallejo <[email protected]>
Oh, here we go. Yet then indeed ...
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -49,6 +49,7 @@ extern uint8_t ioapic_version;
> #define IOAPIC_ID 0x01
>
> extern uint32_t *cpu_to_apicid;
> +extern uint32_t max_apicid;
.. I don't think we need this, as ...
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -389,7 +389,11 @@ int main(void)
>
> if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
> {
> - if ( bios->create_mp_tables )
> + /*
> + * Legacy MP tables hold strictly xAPIC IDs. Skip writing
> + * the tables altogether if we have IDs wider than 8bits.
> + */
> + if ( max_apicid < 0xFF && bios->create_mp_tables )
> bios->create_mp_tables();
I think we ought to continue to write MP tables in this case, merely
omitting processor entries with APIC IDs that don't fit.
Jan
