[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240809230120.GN8378@nvidia.com>
Date: Fri, 9 Aug 2024 20:01:20 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Nicolin Chen <nicolinc@...dia.com>, Robin Murphy <robin.murphy@....com>,
"joro@...tes.org" <joro@...tes.org>,
"will@...nel.org" <will@...nel.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] iommu/dma: Support MSIs through nested domains
On Fri, Aug 09, 2024 at 08:00:34AM +0000, Tian, Kevin wrote:
> > - IOMMUFD should provide VMM a way to tell the gPA (or directly +
> > GITS_TRANSLATER?). Then kernel should do the stage-2 mapping. I
> > have talked to Jason about this a while ago, and we have a few
> > thoughts how to implement it. But eventually, I think we still
> > can't avoid a middle man like msi_cookie to associate the gPA in
> > IOMMUFD to PA in irqchip?
>
> Probably a new IOMMU_DMA_MSI_COOKIE_USER type which uses
> GPA (passed in in ALLOC_HWPT for a nested_parent type) as IOVA
> in iommu_dma_get_msi_page()?
To get the ITS page into the iommufd I suspect we'd add a new iommufd ioctl:
struct iommu_ioas_map_msi_window {
__u32 size;
__u32 flags;
__u32 ioas_id;
__u32 __reserved;
__s32 kvm_device_fd;
__u32 kvm_device_type; // == KVM_DEV_TYPE_ARM_VGIC_ITS for safety
__aligned_u64 device_args; // ??
__aligned_u64 length;
__aligned_u64 iova;
};
Where kvm_device_fd would be the KVM_DEV_TYPE_ARM_VGIC_ITS (?) device
(or the RISCV version).
This would let us get the ITS physical address from the GIC driver and
put it into the S2 at IOVA while relying on KVM to authorize and
locate the correct PA for whatever is going on here.
Jason
Powered by blists - more mailing lists