|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 4/5] hvmload: Add x2apic entry support in the MADT build
On Thu, Aug 24, 2017 at 10:52:19PM -0400, Lan Tianyu wrote:
> This patch is to add x2apic entry support for ACPI MADT table.
>
> Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx>
> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
> ---
> tools/libacpi/acpi2_0.h | 10 ++++++++
> tools/libacpi/build.c | 61
> ++++++++++++++++++++++++++++++++++---------------
> 2 files changed, 53 insertions(+), 18 deletions(-)
>
> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
> index 758a823..ff18b3e 100644
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -322,6 +322,7 @@ struct acpi_20_waet {
> #define ACPI_IO_SAPIC 0x06
> #define ACPI_PROCESSOR_LOCAL_SAPIC 0x07
> #define ACPI_PLATFORM_INTERRUPT_SOURCES 0x08
> +#define ACPI_PROCESSOR_LOCAL_X2APIC 0x09
>
> /*
> * APIC Structure Definitions.
> @@ -338,6 +339,15 @@ struct acpi_20_madt_lapic {
> uint32_t flags;
> };
>
> +struct acpi_20_madt_x2apic {
> + uint8_t type;
> + uint8_t length;
> + uint16_t reserved; /* reserved - must be zero */
> + uint32_t apic_id; /* Processor x2APIC ID */
> + uint32_t flags;
> + uint32_t acpi_processor_id; /* ACPI processor UID */
There's a mix of tabs and spaces above.
> +};
> +
> /*
> * Local APIC Flags. All other bits are reserved and must be 0.
> */
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index c7cc784..36e582a 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -82,9 +82,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt
> *ctxt,
> struct acpi_20_madt *madt;
> struct acpi_20_madt_intsrcovr *intsrcovr;
> struct acpi_20_madt_ioapic *io_apic;
> - struct acpi_20_madt_lapic *lapic;
> const struct hvm_info_table *hvminfo = config->hvminfo;
> int i, sz;
> + void *end;
>
> if ( config->lapic_id == NULL )
> return NULL;
> @@ -92,7 +92,11 @@ static struct acpi_20_madt *construct_madt(struct
> acpi_ctxt *ctxt,
> sz = sizeof(struct acpi_20_madt);
> sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
> sz += sizeof(struct acpi_20_madt_ioapic);
> - sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
> +
> + if (hvminfo->nr_vcpus < 256)
> + sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
> + else
> + sz += sizeof(struct acpi_20_madt_x2apic) * hvminfo->nr_vcpus;
This is wrong, APIC ID is cpu id * 2, so the limit here needs to be
128, not 256. Also this should be set as a constant somewhere.
Apart from that, although this is technically correct, I would rather
prefer the first 128 vCPUs to have xAPIC entries, and APIC IDs > 254
to use x2APIC entries. This will allow a guest without x2APIC support
to still boot on VMs > 128 vCPUs, although they won't be able to use
the extra CPUs. IIRC this is in line with what bare metal does.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |