Re: [RFC PATCH v2 3/4] iommu/riscv: Add guest IMSIC GPA mapping helpers

[Gong Shuai]

Hi Fangyu,

> >Andrew has moved well past a v3
> >
> >I shouldn't be seeing code in iommu or irq drivers directly mapping into
> >domains. That doesn't work, Andrew's latest series don't do this.
> >
> >It still needs to use the SW_MSI mechanism and related.
> >
>
> Andrew has posted two patch series in the community: one is the
> MSI remap v6 series[1], and another is the IRQ bypass v3 series[2].
> I think you are referring to the MSI remap v6 series. My patch was
> based on the IRQ bypass v3 series, and I added this patch on top
> of it.
>
> [1] https://lore.kernel.org/linux-iommu/179209292714.4133959.5997128071302263244.b4-review@b4/T/#t
> [2] https://lore.kernel.org/linux-riscv/20260928143113.49838-1-andrew.jones@xxxxxxxxxxxxxxxx/
>
> >Nothing in the commit messages clearly explained what this is actually for
> >without having to go dig up the riscv manuals again. Please explain how the
> >interrupt translation works and what actual user visible problem this is
> >trying to solve is.
> >
>
> The interrupt translation is based on Andrew's irq bypass patch
> description.
>
> RISC-V IOMMU defines an optional MSI page table feature, which can
> be used to implement irq bypass by translating the vIMSIC GPA to
> the pIMSIC HPA.
>
> My patch complements that design. If the RISC-V IOMMU hardware does
> not implement the MSI page table, then the second-stage page table
> can be used instead to map vIMSIC GPA to pIMSIC HPA.

Using the regular stage-2 page table to translate MSI target
addresses seems reasonable to me as a fallback for hardware without
MSI_FLAT.

I would like to share my personal understanding of Jason's review.
Please correct me if I missed his point.

His concern seems to be about who owns and maintains these mappings.
When the RISC-V IOMMU driver calls iommu_map directly on a paging
domain managed by iommufd, the mappings are not visible to the domain
owner. This makes it difficult to handle mapping lifetime and
hardware page table replacement correctly.

The current SW_MSI support does not appear to cover this use case
directly. It allocates IOVAs for host MSI pages and records the
resulting mappings. Guest forwarding instead requires mappings at
fixed guest GPAs, with their target HPAs changing when vCPUs migrate.
Supporting this through SW_MSI would therefore seem to require a
nontrivial extension.

Best regards,
Shuai

>
> Thanks,
> Fangyu
>
> >--
> >Jason
>