All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.