From: Junjie Cao <junjie.cao@intel.com>
To: zhenzhong.duan@intel.com
Cc: qemu-devel@nongnu.org, mst@redhat.com, jasowang@redhat.com,
yi.l.liu@intel.com, clement.mathieu--drif@bull.com,
philmd@linaro.org, Junjie Cao <junjie.cao@intel.com>
Subject: Re: [PATCH v2 1/2] intel_iommu: widen impl.min_access_size to 8 to fix MMIO abort
Date: Thu, 30 Apr 2026 08:16:07 +0800 [thread overview]
Message-ID: <20260430001607.3505699-1-junjie.cao@intel.com> (raw)
In-Reply-To: <IA3PR11MB9136A84869D0FA17B213347392362@IA3PR11MB9136.namprd11.prod.outlook.com>
Hi Zhenzhong,
Thanks for the careful review.
You are right that the code path has changed. With min_access_size=8
the handler always receives size=8, so a guest 4-byte write to a base
offset calls vtd_set_quad() with a zero-extended value instead of
vtd_set_long(). Two effects:
1. Triggers called unconditionally
CCMD_REG, IOTLB_REG, and FRCD_REG_0_2 originally guarded the
trigger on size==8. In v2 all three are still no-ops:
vtd_handle_ccmd_write() and vtd_handle_iotlb_write() gate on
ICC/IVT (bit 63), which the zero-extended write just cleared
through the wmask. For FRCD_REG_0_2, wmask is zero and the w1c
bit 63 does not fire (val bit 63 = 0), so the register is
unchanged.
2. Upper writable bits cleared by zero-extended vtd_set_quad()
Where the upper 32-bit wmask is non-zero, zero-extended val clears
those bits:
Register Offset Upper wmask Bits cleared
CCMD_REG 0x28 0xe0000003 ICC, CIRG, 33:32
IOTLB_REG 0xf8 0xb003ffff IVT, IIRG, DID
RTADDR_REG 0x20 0xffffffff address 63:32
IQA_REG 0x90 0xffffffff address 63:32
IVA_REG 0xf0 0xffffffff address 63:32
IRTA_REG 0xb8 0xffffffff address 63:32
(IQT_REG, FRCD_0_0, and FRCD_0_2 have upper wmask = 0 -- safe.)
This is safe because a guest must program the full register before
the value is consumed: CCMD/IOTLB fields are set before the action
bit (ICC/IVT) in the high-half write; RTADDR, IQA, and IRTA are
latched only when a GCMD enable bit (SRTP/QIE/SIRTP) fires; IVA is
read when IOTLB invalidation triggers via IVT.
However, a read-back between the low-half and high-half writes
would observe zeroed upper bits -- a real behavioral difference.
Two possible paths
(a) Keep v2 as-is, add comments documenting the safety argument
above.
(b) Stay with min_access_size=4. Simply remove all 25 asserts.
21 sit at non-8-aligned offsets -- unreachable by any 8-byte
guest access (alignment check rejects them). The remaining 4
at 8-aligned offsets (FECTL 0x38, IECTL 0xa0, IEADDR 0xa8,
PECTL 0xe0) fall through to vtd_set_long() which implicitly
truncates the value -- safe and no semantic change. All
existing size branches in 64-bit register pairs are preserved.
As I see it, both approaches are correct; (a) is simpler but
changes observable semantics in an edge case, (b) is conservative
with zero semantic change. That said, I am happy to hear any other
suggestions.
Thanks,
Junjie
next prev parent reply other threads:[~2026-04-29 16:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 20:18 [PATCH v2 0/2] intel_iommu: fix guest-triggerable assert in MMIO handlers Junjie Cao
2026-04-24 20:18 ` [PATCH v2 1/2] intel_iommu: widen impl.min_access_size to 8 to fix MMIO abort Junjie Cao
2026-04-24 13:58 ` Philippe Mathieu-Daudé
2026-04-27 1:24 ` Junjie Cao
2026-04-27 5:23 ` Duan, Zhenzhong
2026-04-30 0:16 ` Junjie Cao [this message]
2026-04-30 8:31 ` Duan, Zhenzhong
2026-05-06 3:19 ` [PATCH v3 0/2] intel_iommu: fix guest-triggerable assert in MMIO handlers Junjie Cao
2026-05-06 3:19 ` [PATCH v3 1/2] intel_iommu: fix guest-triggerable abort on oversized MMIO access Junjie Cao
2026-05-08 9:36 ` Yi Liu
2026-05-11 5:41 ` Duan, Zhenzhong
2026-05-14 13:42 ` Junjie Cao
2026-05-14 6:59 ` Yi Liu
2026-05-06 3:19 ` [PATCH v3 2/2] tests/qtest: add 8-byte MMIO access sweep for intel-iommu Junjie Cao
2026-04-24 20:18 ` [PATCH v2 " Junjie Cao
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=20260430001607.3505699-1-junjie.cao@intel.com \
--to=junjie.cao@intel.com \
--cc=clement.mathieu--drif@bull.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=yi.l.liu@intel.com \
--cc=zhenzhong.duan@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 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.