On Tue, Nov 04, 2025 at 03:35:21PM -0400, Jason Gunthorpe wrote: > On Tue, Nov 04, 2025 at 11:31:50AM -0800, Nicolin Chen wrote: > > On Tue, Nov 04, 2025 at 02:56:51PM -0400, Jason Gunthorpe wrote: > > > On Tue, Nov 04, 2025 at 10:44:27AM -0800, Nicolin Chen wrote: > > > > KVM would always get the IRQ from HW, since the HW is programmed > > > > correctly. But if gIOVA->vITS is not mapped, i.e. gIOVA is given > > > > incorrectly, it can't inject the IRQ. > > > > > > But this is a software interrupt, and I think it should still just > > > ignore vMSI's address and assume it is mapped to a legal ITS > > > page. There is just no way to validate it. > > > > > > Even SW MSI shouldn't fail because the vMSI has some weird IOVA in it > > > that isn't mapped in the S2. That's wrong and is something the guest > > > is permitted to do. > > > > Hmm, that feels like a self-correction? But in a baremetal case, > > if HW is programmed with a weird IOVA, interrupt would not work, > > right? > > Right, but qemu has no way to duplicate that behavior unless it walks > the full s1 and s2 page tables, which we have said it isn't going to > do.
I think it could. The stage-1 page table is in the guest RAM. And vSMMU has already implemented the logic to walk through a guest page table. What KVM has already been doing today is to ask vSMMU to translate that. What we haven't implemented today is, if gIOVA is a weird one that isn't translatable, vSMMU should trigger an F_TRANSLATION event as the real HW does. > So it should probably just ignore this check and assume the IOVA is > set properly, exactly the same as if it was HW injected using the RMR. Hmm, I am not sure about that, especially considering our plan to support the true 2-stage mapping: gIOVA->vITS->pITS :-/ Thanks Nicolin
