From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>, <qemu-devel@nongnu.org>,
<ankita@nvidia.com>, <philmd@linaro.org>,
Richard Henderson <richard.henderson@linaro.org>,
Dave Jiang <dave.jiang@intel.com>,
"Huang Ying" <ying.huang@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>, <eduardo@habkost.net>,
<imammedo@redhat.com>, <linux-cxl@vger.kernel.org>,
<linuxarm@huawei.com>, Michael Roth <michael.roth@amd.com>,
Ani Sinha <anisinha@redhat.com>
Subject: Re: [PATCH qemu ] hw/acpi: Fix big endian host creation of Generic Port Affinity Structures
Date: Thu, 6 Jun 2024 10:27:01 +0100 [thread overview]
Message-ID: <20240606102701.000008de@Huawei.com> (raw)
In-Reply-To: <20240605193521-mutt-send-email-mst@kernel.org>
On Wed, 5 Jun 2024 19:38:18 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Jun 05, 2024 at 07:04:55PM +0100, Jonathan Cameron wrote:
> > Treating the HID as an integer caused it to get bit reversed
> > on big endian hosts running little endian guests. Treat it
> > as a character array instead.
> >
> > Fixes hw/acpi: Generic Port Affinity Structure Support
> > Tested-by: Richard Henderson <richard.henderson@linaro.org>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > ---
> > Richard ran the version posted in the thread on an s390 instance.
> > Thanks for the help!
> >
> > Difference from version in thread:
> > - Instantiate i in the for loop.
> >
> > Sending out now so Michael can decide whether to fold this in, or
> > drop the GP series for now from his pull request (in which case
> > I'll do an updated version with this and Markus' docs feedback
> > folded in.)
>
>
> Dropped for now.
>
>
> > ---
> > include/hw/acpi/acpi_generic_initiator.h | 2 +-
> > hw/acpi/acpi_generic_initiator.c | 4 +++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/hw/acpi/acpi_generic_initiator.h b/include/hw/acpi/acpi_generic_initiator.h
> > index 1a899af30f..5baefda33a 100644
> > --- a/include/hw/acpi/acpi_generic_initiator.h
> > +++ b/include/hw/acpi/acpi_generic_initiator.h
> > @@ -61,7 +61,7 @@ typedef struct PCIDeviceHandle {
> > uint16_t bdf;
> > };
> > struct {
> > - uint64_t hid;
> > + char hid[8];
> > uint32_t uid;
> > };
> > };
>
> I think there is another issue:
>
> + memcpy(&dev_handle.hid, hid, sizeof(dev_handle.hid));
>
> not nice since there is no check that 8 will hold all of
> + const char *hid = "ACPI0016";
> and won't access buffer out of range.
>
I think, in theory, that won't ever happen unless someone is using
an invalid ACPI ID as they 'must' be 8 chars (or a uint64_t which
would also be fine). A bit of defensive programming seems
sensible though as there are known buggy real firmware's
that have invalid IDs so maybe one day someone will add one
of those to QEMU when we aren't paying attention.
I'll add a sanity check and treat such a value as an error.
It'll also act as documentation of the requirement.
if (strlen(hid) != sizeof(dev_handle.hid)) {
error_printf("ACPI ID for generic port is not the expected 8 characters");
exit(-1);
}
>
>
>
> > diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
> > index 78b80dcf08..f064753b67 100644
> > --- a/hw/acpi/acpi_generic_initiator.c
> > +++ b/hw/acpi/acpi_generic_initiator.c
> > @@ -151,7 +151,9 @@ build_srat_generic_node_affinity(GArray *table_data, int node,
> > build_append_int_noprefix(table_data, 0, 12);
> > } else {
> > /* Device Handle - ACPI */
> > - build_append_int_noprefix(table_data, handle->hid, 8);
> > + for (int i = 0; i < sizeof(handle->hid); i++) {
> > + build_append_int_noprefix(table_data, handle->hid[i], 1);
> > + }
> > build_append_int_noprefix(table_data, handle->uid, 4);
> > build_append_int_noprefix(table_data, 0, 4);
> > }
> > --
> > 2.39.2
>
>
next prev parent reply other threads:[~2024-06-06 9:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 18:04 [PATCH qemu ] hw/acpi: Fix big endian host creation of Generic Port Affinity Structures Jonathan Cameron via
2024-06-05 23:38 ` Michael S. Tsirkin
2024-06-06 9:27 ` Jonathan Cameron via [this message]
2024-06-06 14:06 ` Igor Mammedov
2024-06-06 17:47 ` Jonathan Cameron via
2024-06-10 17:47 ` Jonathan Cameron via
2024-06-14 10:57 ` Igor Mammedov
2024-06-14 14:08 ` Jonathan Cameron via
2024-06-17 10:49 ` Igor Mammedov
2024-06-17 12:05 ` Jonathan Cameron via
2024-06-18 12:23 ` Igor Mammedov
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=20240606102701.000008de@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=anisinha@redhat.com \
--cc=ankita@nvidia.com \
--cc=armbru@redhat.com \
--cc=dave.jiang@intel.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=richard.henderson@linaro.org \
--cc=ying.huang@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 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).