From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Ankit Agrawal <ankita@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"clg@redhat.com" <clg@redhat.com>,
"shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"ani@anisinha.ca" <ani@anisinha.ca>,
Aniket Agashe <aniketa@nvidia.com>, Neo Jia <cjia@nvidia.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
"Tarun Gupta (SW-GPU)" <targupta@nvidia.com>,
Vikram Sethi <vsethi@nvidia.com>,
"Andy Currid" <ACurrid@nvidia.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v1 3/4] hw/arm/virt-acpi-build: patch guest SRAT for NUMA nodes
Date: Wed, 27 Sep 2023 12:01:48 +0100 [thread overview]
Message-ID: <20230927120148.000037a0@Huawei.com> (raw)
In-Reply-To: <BY5PR12MB37637E2A77DC8A9AB064ABCEB0C3A@BY5PR12MB3763.namprd12.prod.outlook.com>
On Tue, 26 Sep 2023 14:54:36 +0000
Ankit Agrawal <ankita@nvidia.com> wrote:
> > With an ACPI spec clarification agreed then I'm fine with
> > using this for all the cases that have come up in this thread.
> > Or a good argument that this is valid in under existing ACPI spec.
>
> Hi Jonathan
>
> I looked at the Section 5.2.16 in ACPI spec doc, but could not see
> any mention of whether size == 0 is invalid or be avoided.
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
>
> If that is not convincing, do you have suggestions as to how I may
> confirm this?
>
It's not so much whether 0 size is valid that concerns me (as you
say it isn't ruled out, though given the explanatory text is
is non sensical) but rather whether you are allowed to use
such an entry to add memory that is not within the range later.
To my reading the statement under "Memory Affinity Structure" suggests
not.
"The Memory Affinity structure provides the following topology information
statically to the operating system:
* The association between a _memory range_ and the proximity to which it belongs.
* Information about whether the memory range can be hot-plugged.
"
That doesn't leave space for using it to define a proximity node without
providing the range. With my 'occasional' contributor to ACPI spec hat on,
(obviously there are people way more versed in this than me!)
I'd suggest that ASWG will ask the obvious question of why does the ACPI
table needs to describe a software entity that is entirely discoverable by
other means? After all your driver is clearly going to pick up these
nodes and assign them later - so it can just create them. ACPI spec
doesn't care if Linux can do this or not :(
There are some hacks in place in the kernel (or at least under review)
to deal with a CXL case where there are BIOSes that assign part of the
CXL Fixed Memory Window (a bit of host PA space) to an SRAT entry, but
not the whole of it. However, I think those are a workaround for a bug
(maybe not everyone agrees with that though).
Perhaps I'm being overly hopeful for clarity and it is fine to
do what you have here.
Jonathan
next prev parent reply other threads:[~2023-09-27 11:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 2:45 [PATCH v1 0/4] vfio: report NUMA nodes for device memory ankita
2023-09-15 2:45 ` [PATCH v1 1/4] vfio: new command line params for device memory NUMA nodes ankita
2023-09-15 14:25 ` Jonathan Cameron via
2023-09-15 14:48 ` Igor Mammedov
2023-09-22 5:44 ` Ankit Agrawal
2023-09-25 14:08 ` Jonathan Cameron via
2023-09-15 2:45 ` [PATCH v1 2/4] vfio: assign default values to node params ankita
2023-09-15 2:45 ` [PATCH v1 3/4] hw/arm/virt-acpi-build: patch guest SRAT for NUMA nodes ankita
2023-09-15 14:37 ` Jonathan Cameron via
2023-09-22 5:49 ` Ankit Agrawal
2023-09-25 13:54 ` Jonathan Cameron via
2023-09-25 14:03 ` Jason Gunthorpe
2023-09-25 14:53 ` Jonathan Cameron via
2023-09-25 16:00 ` Jason Gunthorpe
2023-09-25 17:00 ` Jonathan Cameron via
2023-09-26 14:54 ` Ankit Agrawal
2023-09-27 7:06 ` Ankit Agrawal
2023-09-27 11:01 ` Jonathan Cameron via [this message]
2023-09-15 14:52 ` Igor Mammedov
2023-09-15 15:49 ` David Hildenbrand
2023-09-15 2:45 ` [PATCH v1 4/4] acpi/gpex: patch guest DSDT for dev mem information ankita
2023-09-15 15:13 ` Igor Mammedov
2023-09-27 11:42 ` Jonathan Cameron via
2023-09-15 14:19 ` [PATCH v1 0/4] vfio: report NUMA nodes for device memory Cédric Le Goater
2023-09-15 14:47 ` Alex Williamson
2023-09-15 18:34 ` David Hildenbrand
2023-09-22 8:11 ` Ankit Agrawal
2023-09-22 8:15 ` David Hildenbrand
2023-09-26 14:52 ` Ankit Agrawal
2023-09-26 16:54 ` David Hildenbrand
2023-09-26 19:14 ` Alex Williamson
2023-09-27 7:14 ` Ankit Agrawal
2023-09-27 11:33 ` Jonathan Cameron via
2023-09-27 13:53 ` Jason Gunthorpe
2023-09-27 14:24 ` Alex Williamson
2023-09-27 15:03 ` Vikram Sethi
2023-09-27 15:42 ` Jason Gunthorpe
2023-09-28 16:15 ` Jonathan Cameron via
2023-09-27 16:37 ` Alex Williamson
2023-09-28 16:29 ` Jonathan Cameron via
2023-09-28 16:04 ` Jonathan Cameron via
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=20230927120148.000037a0@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=ACurrid@nvidia.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=alex.williamson@redhat.com \
--cc=ani@anisinha.ca \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=cjia@nvidia.com \
--cc=clg@redhat.com \
--cc=jgg@nvidia.com \
--cc=kwankhede@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).