Message ID | 20220518092141.1050852-1-gshan@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | hw/acpi/aml-build: Fix {socket, cluster, core} IDs in PPTT | expand |
On Wed, May 18, 2022 at 05:21:38PM +0800, Gavin Shan wrote: > The {socket, cluster, core} IDs detected from Linux guest aren't > matching with what have been provided in PPTT. The flag used for > 'ACPI Processor ID valid' is missed for {socket, cluster, core} > nodes. In this case, Linux guest takes the offset between the > node and PPTT header as the corresponding IDs, as the following > logs show. > > > /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ > -accel kvm -machine virt,gic-version=host -cpu host \ > -smp 8,sockets=2,clusters=2,cores=2,threads=1 > : > > # cd /sys/devices/system/cpu > # for i in `seq 0 15`; do cat cpu$i/topology/physical_package_id; done > 36 36 36 36 36 36 36 36 > 336 336 336 336 336 336 336 336 > # for i in `seq 0 15`; do cat cpu$i/topology/cluster_id; done > 56 56 56 56 196 196 196 196 > 356 356 356 356 496 496 496 496 > # for i in `seq 0 15`; do cat cpu$i/topology/core_id; done > 76 76 136 136 216 216 276 276 > 376 376 436 436 516 516 576 576 > > This fixes the issue by setting 'ACPI Processor ID valid' flag for > {socket, cluster, core} nodes. With this applied, the IDs are exactly > what have been provided in PPTT. I also checked the PPTT table on my > host, where the 'ACPI Processor ID valid' is set for cluster/core nodes, > but missed from socket nodes. > > host# pwd > /sys/devices/system/cpu > host# cat cpu0/topology/physical_package_id; \ > cat cpu0/topology/cluster_id; \ > cat cpu0/topology/core_id > 36 0 0 > > Gavin Shan (3): > tests/acpi/virt: Allow PPTT ACPI table changes > hw/acpi/aml-build: Fix {socket, cluster, core} IDs in PPTT > tests/acpi/virt: Update PPTT ACPI table > > hw/acpi/aml-build.c | 9 ++++++--- > tests/data/acpi/virt/PPTT | Bin 96 -> 96 bytes > 2 files changed, 6 insertions(+), 3 deletions(-) > > -- > 2.23.0 > For the series Reviewed-by: Andrew Jones <drjones@redhat.com>
Hi Igor, Yanan and maintainers, On 5/18/22 5:21 PM, Gavin Shan wrote: > The {socket, cluster, core} IDs detected from Linux guest aren't > matching with what have been provided in PPTT. The flag used for > 'ACPI Processor ID valid' is missed for {socket, cluster, core} > nodes. In this case, Linux guest takes the offset between the > node and PPTT header as the corresponding IDs, as the following > logs show. > > > /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ > -accel kvm -machine virt,gic-version=host -cpu host \ > -smp 8,sockets=2,clusters=2,cores=2,threads=1 > : > > # cd /sys/devices/system/cpu > # for i in `seq 0 15`; do cat cpu$i/topology/physical_package_id; done > 36 36 36 36 36 36 36 36 > 336 336 336 336 336 336 336 336 > # for i in `seq 0 15`; do cat cpu$i/topology/cluster_id; done > 56 56 56 56 196 196 196 196 > 356 356 356 356 496 496 496 496 > # for i in `seq 0 15`; do cat cpu$i/topology/core_id; done > 76 76 136 136 216 216 276 276 > 376 376 436 436 516 516 576 576 > > This fixes the issue by setting 'ACPI Processor ID valid' flag for > {socket, cluster, core} nodes. With this applied, the IDs are exactly > what have been provided in PPTT. I also checked the PPTT table on my > host, where the 'ACPI Processor ID valid' is set for cluster/core nodes, > but missed from socket nodes. > > host# pwd > /sys/devices/system/cpu > host# cat cpu0/topology/physical_package_id; \ > cat cpu0/topology/cluster_id; \ > cat cpu0/topology/core_id > 36 0 0 > > Gavin Shan (3): > tests/acpi/virt: Allow PPTT ACPI table changes > hw/acpi/aml-build: Fix {socket, cluster, core} IDs in PPTT > tests/acpi/virt: Update PPTT ACPI table > > hw/acpi/aml-build.c | 9 ++++++--- > tests/data/acpi/virt/PPTT | Bin 96 -> 96 bytes > 2 files changed, 6 insertions(+), 3 deletions(-) > Could you help to review this tiny series? Thanks in advance. Thanks, Gavin
On Thu, 26 May 2022 19:37:47 +0800 Gavin Shan <gshan@redhat.com> wrote: > Hi Igor, Yanan and maintainers, > > On 5/18/22 5:21 PM, Gavin Shan wrote: > > The {socket, cluster, core} IDs detected from Linux guest aren't > > matching with what have been provided in PPTT. The flag used for > > 'ACPI Processor ID valid' is missed for {socket, cluster, core} > > nodes. In this case, Linux guest takes the offset between the > > node and PPTT header as the corresponding IDs, as the following > > logs show. > > > > > > /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ > > -accel kvm -machine virt,gic-version=host -cpu host \ > > -smp 8,sockets=2,clusters=2,cores=2,threads=1 > > : > > > > # cd /sys/devices/system/cpu > > # for i in `seq 0 15`; do cat cpu$i/topology/physical_package_id; done > > 36 36 36 36 36 36 36 36 > > 336 336 336 336 336 336 336 336 > > # for i in `seq 0 15`; do cat cpu$i/topology/cluster_id; done > > 56 56 56 56 196 196 196 196 > > 356 356 356 356 496 496 496 496 > > # for i in `seq 0 15`; do cat cpu$i/topology/core_id; done > > 76 76 136 136 216 216 276 276 > > 376 376 436 436 516 516 576 576 > > > > This fixes the issue by setting 'ACPI Processor ID valid' flag for > > {socket, cluster, core} nodes. With this applied, the IDs are exactly > > what have been provided in PPTT. I also checked the PPTT table on my > > host, where the 'ACPI Processor ID valid' is set for cluster/core nodes, > > but missed from socket nodes. > > > > host# pwd > > /sys/devices/system/cpu > > host# cat cpu0/topology/physical_package_id; \ > > cat cpu0/topology/cluster_id; \ > > cat cpu0/topology/core_id > > 36 0 0 > > > > Gavin Shan (3): > > tests/acpi/virt: Allow PPTT ACPI table changes > > hw/acpi/aml-build: Fix {socket, cluster, core} IDs in PPTT > > tests/acpi/virt: Update PPTT ACPI table > > > > hw/acpi/aml-build.c | 9 ++++++--- > > tests/data/acpi/virt/PPTT | Bin 96 -> 96 bytes > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > Could you help to review this tiny series? Thanks in advance. done, so far I'm not convinced that it's QEMU's fault. see comment on 2/3 > > Thanks, > Gavin >
On 5/26/22 8:27 PM, Igor Mammedov wrote: > On Thu, 26 May 2022 19:37:47 +0800 > Gavin Shan <gshan@redhat.com> wrote: >> >> On 5/18/22 5:21 PM, Gavin Shan wrote: >>> The {socket, cluster, core} IDs detected from Linux guest aren't >>> matching with what have been provided in PPTT. The flag used for >>> 'ACPI Processor ID valid' is missed for {socket, cluster, core} >>> nodes. In this case, Linux guest takes the offset between the >>> node and PPTT header as the corresponding IDs, as the following >>> logs show. >>> >>> >>> /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ >>> -accel kvm -machine virt,gic-version=host -cpu host \ >>> -smp 8,sockets=2,clusters=2,cores=2,threads=1 >>> : >>> >>> # cd /sys/devices/system/cpu >>> # for i in `seq 0 15`; do cat cpu$i/topology/physical_package_id; done >>> 36 36 36 36 36 36 36 36 >>> 336 336 336 336 336 336 336 336 >>> # for i in `seq 0 15`; do cat cpu$i/topology/cluster_id; done >>> 56 56 56 56 196 196 196 196 >>> 356 356 356 356 496 496 496 496 >>> # for i in `seq 0 15`; do cat cpu$i/topology/core_id; done >>> 76 76 136 136 216 216 276 276 >>> 376 376 436 436 516 516 576 576 >>> >>> This fixes the issue by setting 'ACPI Processor ID valid' flag for >>> {socket, cluster, core} nodes. With this applied, the IDs are exactly >>> what have been provided in PPTT. I also checked the PPTT table on my >>> host, where the 'ACPI Processor ID valid' is set for cluster/core nodes, >>> but missed from socket nodes. >>> >>> host# pwd >>> /sys/devices/system/cpu >>> host# cat cpu0/topology/physical_package_id; \ >>> cat cpu0/topology/cluster_id; \ >>> cat cpu0/topology/core_id >>> 36 0 0 >>> >>> Gavin Shan (3): >>> tests/acpi/virt: Allow PPTT ACPI table changes >>> hw/acpi/aml-build: Fix {socket, cluster, core} IDs in PPTT >>> tests/acpi/virt: Update PPTT ACPI table >>> >>> hw/acpi/aml-build.c | 9 ++++++--- >>> tests/data/acpi/virt/PPTT | Bin 96 -> 96 bytes >>> 2 files changed, 6 insertions(+), 3 deletions(-) >>> >> >> Could you help to review this tiny series? Thanks in advance. > done, so far I'm not convinced that it's QEMU's fault. see comment on 2/3 > Thanks, Igor. I just replied. Lets discuss this through in the loop of PATCH[2/3]. Thanks, Gavin