From: Jason Gunthorpe <jgg@ziepe.ca>
To: Tan Chi <tanchi25@mails.ucas.ac.cn>
Cc: gong.shuai@sanechips.com.cn, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
tomasz.jeznach@linux.dev, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, pbonzini@redhat.com, seanjc@google.com,
kevin.tian@intel.com, andrew.jones@oss.qualcomm.com,
fangyu.yu@linux.alibaba.com, wu.fei9@sanechips.com.cn,
zhao.qingye@sanechips.com.cn, gsh517025@gmail.com
Subject: Re: [RFC PATCH v2 9/9] iommu/riscv: Add riscv_iommu_attach_dev_nested
Date: Thu, 5 Nov 2026 14:32:22 -0400 [thread overview]
Message-ID: <20261105183222.GE663069@ziepe.ca> (raw)
In-Reply-To: <20261105144944.10193-1-tanchi25@mails.ucas.ac.cn>
On Thu, Nov 05, 2026 at 10:49:44PM +0800, Tan Chi wrote:
> Hi Shuai and Fei,
>
> I noticed a potential issue with fixing the physical DC's PSCID to 0.
>
> In QEMU, different VFIO devices can have separate stage-1 HWPTs while
> sharing the same vIOMMU and stage-2 parent. This means two devices may
> have different first-stage page table roots but the same host GSCID
> and PSCID=0.
>
> According to the RISC-V IOMMU specification, DC.ta.PSCID identifies
> the first-stage address space when PDTV=0 and the first stage is not
> Bare. Could this cause the physical IOMMU to reuse cached translations
> across different stage-1 address spaces? Even broader invalidations
> would not prevent such cache aliasing.
>
> There also seems to be a related issue in patch 6.
> riscv_viommu_cache_invalidate() unconditionally forces PSCV=1 and
> PSCID=0. However, an IOTINVAL.VMA with PSCV=0 also invalidates global
> mappings, while PSCV=1 excludes them. This appears to narrow the
> guest's requested invalidation scope and could leave stale global
> translations cached.
>
> One possible approach might be to use the PSCID from the guest-provided
> DC.ta when allocating the nested domain, and preserve the guest's PSCID
> and PSCV settings during invalidation while substituting the host GSCID.
> I'm not sure whether additional considerations are needed for PSCID
> reuse or domain lifetime, though.
If the guest is issuing invalidations you must always preserve the
guests "ASID" or whatever your HW calls it. It can be virtualized and
mapped from a guest view to physical, but it must be preserved and
physical must be 1:1 with virtual.
Jason
prev parent reply other threads:[~2026-11-05 18:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 6:11 [RFC PATCH v2 0/9] iommu/riscv: Add nested translation (vIOMMU) support Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 1/9] iommu/riscv: Use DC.tc.V as the device context valid bit Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 2/9] iommufd: Add RISC-V IOMMU hwpt and vIOMMU types Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 3/9] iommufd: Add RISC-V IOMMU cache invalidation data type Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 4/9] iommu/riscv: Add vIOMMU object support Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 5/9] iommu/riscv: Add nested domain allocation Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 6/9] iommu/riscv: Add vIOMMU cache invalidation Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 7/9] iommufd: Add RISC-V IOMMU hardware info type Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 8/9] iommu/riscv: Add riscv_iommu_hw_info Gong Shuai
2026-10-29 6:11 ` [RFC PATCH v2 9/9] iommu/riscv: Add riscv_iommu_attach_dev_nested Gong Shuai
2026-11-05 14:49 ` Tan Chi
2026-11-05 18:32 ` Jason Gunthorpe [this message]
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=20261105183222.GE663069@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex@ghiti.fr \
--cc=andrew.jones@oss.qualcomm.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=fangyu.yu@linux.alibaba.com \
--cc=gong.shuai@sanechips.com.cn \
--cc=gsh517025@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=tanchi25@mails.ucas.ac.cn \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
--cc=wu.fei9@sanechips.com.cn \
--cc=zhao.qingye@sanechips.com.cn \
/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
all inboxes | Powered by JetHome®