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:57 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 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.