All of lore.kernel.org
 help / color / mirror / Atom feed
From: Salil Mehta <salil.mehta@huawei.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"sameo@linux.intel.com" <sameo@linux.intel.com>,
	"mst@redhat.com" <mst@redhat.com>, Linuxarm <linuxarm@huawei.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	pbonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: [Question] Regarding presence of duplicate ACPI CPU entries at two nodes \\_SB.CXXX and \\_SB.CPUS.CXXX  of namespace
Date: Wed, 29 Jan 2020 11:51:14 +0000	[thread overview]
Message-ID: <590fb35353de473d9c689caead95c659@huawei.com> (raw)

Hello,

Observation:
If we launch Linux Guest VM using QEMU(running on any type host. I am using x86) with
CPU based on any ARM64 architecture then I could see QEMU populating ACPI nodes
related to same CPU at 2 places of the ACPI namespace:
1. \\_SB.CXXX
2. \\_SB.CPUS.CXXX 

Above results in Guest VM showing duplicate CPU entries in the sysfs for the same CPUS.
I could make out the entries under \\_SB.CPUS.XXX are part of the container.

estuary:/$ ls -al /sys/bus/acpi/devices/

Observation 1: (belongs to \\_SB.C00X)
ACPI0007:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:00 
ACPI0007:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:01
ACPI0007:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:02
ACPI0007:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:03
ACPI0007:04 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:04
ACPI0007:05 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:05

Observation 2: (belongs to \\_SB.CPUS.C00X and under container ACPI0010:00 part of \\_SB.CPUS)
ACPI0007:06 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:06  
ACPI0007:07 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:07 
ACPI0007:08 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:08
ACPI0007:09 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:09
ACPI0007:0a -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:0a
ACPI0007:0b -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:0b
ACPI0010:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00


estuary:/$ cat /sys/bus/acpi/devices/ACPI0010\:00/path 
\_SB_.CPUS

estuary:/$ cat /sys/bus/acpi/devices/ACPI0007\:00/uid 
0
estuary:/$ cat /sys/bus/acpi/devices/ACPI0007\:00/path
\_SB_.C000

estuary:/$ cat /sys/bus/acpi/devices/ACPI0007\:06/uid 
0
estuary:/$ cat /sys/bus/acpi/devices/ACPI0007\:06/path
\_SB_.CPUS.C000



QEMU Code Excerpt:
I could trace with in QEMU AML code, the CPUS are being appended at 2 places:


Code 1. File: hw/arm/virt-acpi-build.c (Cause of Observation 1 i.e. \\_SB.CXXX )

static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
{
    uint16_t i;

    for (i = 0; i < smp_cpus; i++) { --->{should be possible cpus anyways}
        Aml *dev = aml_device("C%.03X", i);
        aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0007")));
        aml_append(dev, aml_name_decl("_UID", aml_int(i)));
        aml_append(scope, dev);
    }
}


Code 2. File: hw/acpi/cpu.c (Cause of Observation 2 i.e. \\_SB.CPUS.CXXX)

void build_cpus_aml(..)
{
[...]
  cpus_dev = aml_device("\\_SB.CPUS");
  {
    [...]
            /* build Processor object for each processor */
        for (i = 0; i < arch_ids->len; i++) {
            Aml *dev;
            Aml *uid = aml_int(i);
            GArray *madt_buf = g_array_new(0, 1, 1);
            int arch_id = arch_ids->cpus[i].arch_id;

            if (opts.acpi_1_compatible && arch_id < 255) {
                dev = aml_processor(i, 0, 0, CPU_NAME_FMT, i);
            } else {
                dev = aml_device(CPU_NAME_FMT, i);
                aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0007")));
                aml_append(dev, aml_name_decl("_UID", uid));
            }
    [...]
  }    
[...]
}



Questions:
Q1. I could not understand the purpose of keeping acpi_dsdt_add_cpus() after the code 2.
     was introduced as part of the below change and which is already adding CPUS related
     AML to \\_SB.CPUS namespace?

acpi: cpuhp: add CPU devices AML with _STA method
commit 5e1b5d93887b52eede156f846b6c4c5c8bbcfcdb

Q2. Do we really require CPUs being added by acpi_dsdt_add_cpus() in \\_SB.CXXX
     Namespace OR is it a stray code left?



Please help to correct if there is a gap in my understanding here and please
forgive me if I have terribly missed out something very basic here.

Many thanks!

Best Regards
Salil









             reply	other threads:[~2020-01-29 11:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 11:51 Salil Mehta [this message]
2020-01-29 12:23 ` [Question] Regarding presence of duplicate ACPI CPU entries at two nodes \\_SB.CXXX and \\_SB.CPUS.CXXX of namespace Salil Mehta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=590fb35353de473d9c689caead95c659@huawei.com \
    --to=salil.mehta@huawei.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=linuxarm@huawei.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sameo@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.