lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ