From: "Michael S. Tsirkin" <mst@redhat.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: peter.maydell@linaro.org, wangxingang5@huawei.com,
shannon.zhaosl@gmail.com, imammedo@redhat.com,
anisinha@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v3] hw/arm/virt-acpi-build: Fix id_count in build_iort_id_mapping
Date: Tue, 18 Jun 2024 17:14:32 -0400 [thread overview]
Message-ID: <20240618171311-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240618211110.922809-1-nicolinc@nvidia.com>
On Tue, Jun 18, 2024 at 02:11:10PM -0700, Nicolin Chen wrote:
> It's observed that Linux kernel booting with the VM reports a "conflicting
> mapping for input ID" FW_BUG.
>
> The IORT doc defines "Number of IDs" to be "the number of IDs in the range
> minus one", while virt-acpi-build.c simply stores the number of IDs in the
> id_count without the "minus one". Meanwhile, some of the callers pass in a
> 0xFFFF following the spec. So, this is a mismatch between the function and
> its callers.
>
> Fix build_iort_id_mapping() by internally subtracting one from the pass-in
> @id_count. Accordingly make sure that all existing callers pass in a value
> without the "minus one", i.e. change all 0xFFFFs to 0x10000s.
>
> Also, add a few lines of comments to highlight this change along with the
> referencing document for this build_iort_id_mapping().
>
> Fixes: 42e0f050e3a5 ("hw/arm/virt-acpi-build: Add IORT support to bypass SMMUv3")
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> Changelog
> v3:
> * Added "-1" internally in build_iort_id_mapping() instead
> * Added comments to highlight this and referencing doc
> v2:
> https://lore.kernel.org/all/20240617223945.906996-1-nicolinc@nvidia.com/
> * Moved "-1" to the same line of id_count calculation
> * Added "+1" to the next_range.input_base calculation
> v1:
> https://lore.kernel.org/all/20240613234802.828265-1-nicolinc@nvidia.com/
>
> hw/arm/virt-acpi-build.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index c3ccfef026..ee6f56b410 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -209,12 +209,20 @@ static void acpi_dsdt_add_tpm(Aml *scope, VirtMachineState *vms)
> #define ROOT_COMPLEX_ENTRY_SIZE 36
> #define IORT_NODE_OFFSET 48
>
> +/*
> + * Input Output Remapping Table (IORT) -- Table 4 ID mapping format
> + * Conforms to "IO Remapping Table System Software on ARM Platforms",
> + * Document number: ARM DEN 0049E.b, Feb 2021
> + *
> + * Note that @id_count will be internally subtracted by one, following
> + * the IORT spec.
> + */
> static void build_iort_id_mapping(GArray *table_data, uint32_t input_base,
> uint32_t id_count, uint32_t out_ref)
> {
> - /* Table 4 ID mapping format */
> build_append_int_noprefix(table_data, input_base, 4); /* Input base */
> - build_append_int_noprefix(table_data, id_count, 4); /* Number of IDs */
> + /* Number of IDs - The number of IDs in the range minus one */
> + build_append_int_noprefix(table_data, id_count - 1, 4);
> build_append_int_noprefix(table_data, input_base, 4); /* Output base */
> build_append_int_noprefix(table_data, out_ref, 4); /* Output Reference */
> /* Flags */
> @@ -306,8 +314,8 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> }
>
> /* Append the last RC -> ITS ID mapping */
> - if (next_range.input_base < 0xFFFF) {
> - next_range.id_count = 0xFFFF - next_range.input_base;
> + if (next_range.input_base < 0x10000) {
> + next_range.id_count = 0x10000 - next_range.input_base;
> g_array_append_val(its_idmaps, next_range);
> }
A change of logic here - I think the new one is right and old
one was wrong, actually. Right?
>
> @@ -366,7 +374,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> build_append_int_noprefix(table_data, 0, 4);
>
> /* output IORT node is the ITS group node (the first node) */
> - build_iort_id_mapping(table_data, 0, 0xFFFF, IORT_NODE_OFFSET);
> + build_iort_id_mapping(table_data, 0, 0x10000, IORT_NODE_OFFSET);
> }
>
> /* Table 17 Root Complex Node */
> @@ -419,7 +427,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> }
> } else {
> /* output IORT node is the ITS group node (the first node) */
> - build_iort_id_mapping(table_data, 0, 0xFFFF, IORT_NODE_OFFSET);
> + build_iort_id_mapping(table_data, 0, 0x10000, IORT_NODE_OFFSET);
> }
>
> acpi_table_end(linker, &table);
> --
> 2.43.0
next prev parent reply other threads:[~2024-06-18 21:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 21:11 [PATCH v3] hw/arm/virt-acpi-build: Fix id_count in build_iort_id_mapping Nicolin Chen
2024-06-18 21:14 ` Michael S. Tsirkin [this message]
2024-06-18 21:19 ` Nicolin Chen
2024-06-18 21:34 ` Michael S. Tsirkin
2024-06-18 21:51 ` Nicolin Chen
2024-06-18 22:05 ` Michael S. Tsirkin
2024-06-19 14:15 ` Eric Auger
2024-06-19 19:56 ` Nicolin Chen
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=20240618171311-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=nicolinc@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=wangxingang5@huawei.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.