On 5/26/22 8:27 PM, Igor Mammedov wrote:
On Thu, 26 May 2022 19:37:47 +0800
Gavin Shan <gs...@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


Reply via email to