From: Nicolin Chen <nicolinc@nvidia.com>
To: "Michael S. Tsirkin" <mst@redhat.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 v2] hw/arm/virt-acpi-build: Fix IORT id_count
Date: Tue, 18 Jun 2024 12:57:10 -0700 [thread overview]
Message-ID: <ZnHmlvckrUNJDWsC@Asurada-Nvidia> (raw)
In-Reply-To: <20240618153725-mutt-send-email-mst@kernel.org>
On Tue, Jun 18, 2024 at 03:38:31PM -0400, Michael S. Tsirkin wrote:
> > > > - next_range.input_base = idmap->input_base + idmap->id_count;
> > > > + next_range.input_base = idmap->input_base + idmap->id_count + 1;
> > > > }
> > > >
> > >
> > > Given this was different previously, did you actually test with multiple ranges?
> >
> > Tested by creating 5 buses: input_base increases by 0x400 while
> > id_count=0x2ff (0x300 - 1). ITS results look correct to me:
> > --------------build_iort: smmu_idmaps
> > DEBUG: build_iort_id_mapping: input_base=0xec00, id_count=0x2ff, out_ref=0x48, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xf000, id_count=0x2ff, out_ref=0xa0, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xf400, id_count=0x2ff, out_ref=0xf8, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xf800, id_count=0x2ff, out_ref=0x150, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xfc00, id_count=0x2ff, out_ref=0x1a8, flags=0
> > --------------build_iort: its_idmaps
> > DEBUG: build_iort_id_mapping: input_base=0x0, id_count=0xebff, out_ref=0x30, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xef00, id_count=0xff, out_ref=0x30, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xf300, id_count=0xff, out_ref=0x30, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xf700, id_count=0xff, out_ref=0x30, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xfb00, id_count=0xff, out_ref=0x30, flags=0
> > DEBUG: build_iort_id_mapping: input_base=0xff00, id_count=0xff, out_ref=0x30, flags=0
> Okay. Is it the case that none of these effect the IORT in
> ./tests/data/acpi/virt/IORT then?
I wasn't aware of that. I checked the dsl content of that IORT
(attaching at the EOM). Only one section of ID mapping, and it
covers the entire 0xFFFF. So, I would say it's not affected?
Or is there anything else that we should try with that IORT?
Thanks
Nicolin
-----
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20200925 (64-bit version)
* Copyright (c) 2000 - 2020 Intel Corporation
*
* Disassembly of ../tests/data/acpi/virt/IORT, Tue Jun 18 19:49:04 2024
*
* ACPI Data Table [IORT]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/
[000h 0000 4] Signature : "IORT" [IO Remapping Table]
[004h 0004 4] Table Length : 00000080
[008h 0008 1] Revision : 03
[009h 0009 1] Checksum : B3
[00Ah 0010 6] Oem ID : "BOCHS "
[010h 0016 8] Oem Table ID : "BXPC "
[018h 0024 4] Oem Revision : 00000001
[01Ch 0028 4] Asl Compiler ID : "BXPC"
[020h 0032 4] Asl Compiler Revision : 00000001
[024h 0036 4] Node Count : 00000002
[028h 0040 4] Node Offset : 00000030
[02Ch 0044 4] Reserved : 00000000
[030h 0048 1] Type : 00
[031h 0049 2] Length : 0018
[033h 0051 1] Revision : 01
[034h 0052 4] Reserved : 00000000
[038h 0056 4] Mapping Count : 00000000
[03Ch 0060 4] Mapping Offset : 00000000
[040h 0064 4] ItsCount : 00000001
[044h 0068 4] Identifiers : 00000000
[048h 0072 1] Type : 02
[049h 0073 2] Length : 0038
[04Bh 0075 1] Revision : 03
[04Ch 0076 4] Reserved : 00000001
[050h 0080 4] Mapping Count : 00000001
[054h 0084 4] Mapping Offset : 00000024
[058h 0088 8] Memory Properties : [IORT Memory Access Properties]
[058h 0088 4] Cache Coherency : 00000001
[05Ch 0092 1] Hints (decoded below) : 00
Transient : 0
Write Allocate : 0
Read Allocate : 0
Override : 0
[05Dh 0093 2] Reserved : 0000
[05Fh 0095 1] Memory Flags (decoded below) : 03
Coherency : 1
Device Attribute : 1
[060h 0096 4] ATS Attribute : 00000000
[064h 0100 4] PCI Segment Number : 00000000
[068h 0104 1] Memory Size Limit : 40
[069h 0105 3] Reserved : 000000
[06Ch 0108 4] Input base : 00000000
[070h 0112 4] ID Count : 0000FFFF
[074h 0116 4] Output Base : 00000000
[078h 0120 4] Output Reference : 00000030
[07Ch 0124 4] Flags (decoded below) : 00000000
Single Mapping : 0
Raw Table Data: Length 128 (0x80)
0000: 49 4F 52 54 80 00 00 00 03 B3 42 4F 43 48 53 20 // IORT......BOCHS
0010: 42 58 50 43 20 20 20 20 01 00 00 00 42 58 50 43 // BXPC ....BXPC
0020: 01 00 00 00 02 00 00 00 30 00 00 00 00 00 00 00 // ........0.......
0030: 00 18 00 01 00 00 00 00 00 00 00 00 00 00 00 00 // ................
0040: 01 00 00 00 00 00 00 00 02 38 00 03 01 00 00 00 // .........8......
0050: 01 00 00 00 24 00 00 00 01 00 00 00 00 00 00 03 // ....$...........
0060: 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 // ........@.......
0070: FF FF 00 00 00 00 00 00 30 00 00 00 00 00 00 00 // ........0.......
next prev parent reply other threads:[~2024-06-18 19:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 22:39 [PATCH v2] hw/arm/virt-acpi-build: Fix IORT id_count Nicolin Chen
2024-06-18 9:49 ` Michael S. Tsirkin
2024-06-18 19:04 ` Nicolin Chen
2024-06-18 19:38 ` Michael S. Tsirkin
2024-06-18 19:57 ` Nicolin Chen [this message]
2024-06-18 20:03 ` Michael S. Tsirkin
2024-06-18 20:12 ` 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=ZnHmlvckrUNJDWsC@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.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 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).