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: <20241004185019.GJ1365916@nvidia.com>
Date: Fri, 4 Oct 2024 15:50:19 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Alexey Kardashevskiy <aik@....com>, kevin.tian@...el.com,
	will@...nel.org, joro@...tes.org, suravee.suthikulpanit@....com,
	robin.murphy@....com, dwmw2@...radead.org, baolu.lu@...ux.intel.com,
	shuah@...nel.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kselftest@...r.kernel.org, eric.auger@...hat.com,
	jean-philippe@...aro.org, mdf@...nel.org, mshavit@...gle.com,
	shameerali.kolothum.thodi@...wei.com, smostafa@...gle.com,
	yi.l.liu@...el.com
Subject: Re: [PATCH v2 06/19] iommufd/viommu: Add
 IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl

On Fri, Oct 04, 2024 at 11:13:46AM -0700, Nicolin Chen wrote:
> On Fri, Oct 04, 2024 at 08:41:47AM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > > For my SEV-TIO exercise ("trusted IO"), I am looking for a kernel interface
> > > to pass the guest's BDFs for a specific host device (which is passed
> > > through) and nothing in the kernel has any knowledge of it atm, is this the
> > > right place, or another ioctl() is needed here?
> > 
> > We probably need to add the vRID as well to this struct for that
> > reason.
> 
> "vRID"/"vBDF" doesn't sound very generic to me to put in this
> structure, though PCI devices are and very likely will be the
> only users of this Virtual Device for a while. Any good idea?

It isn't necessarily bad to have a pci field as long as we can
somehow understand when it is used.

> Also, I am wondering if the uAPI structure of Virtual Device
> should have a driver-specific data structure. And the vdev_id
> should be in the driver-specific struct. So, it could stay in
> corresponding naming, "Stream ID", "Device ID" or "Context ID"
> v.s. a generic "Virtual ID" in the top-level structure? Then,
> other info like CCA can be put in the driver-level structure
> of SMMU's.

I'd to avoid a iommu-driver specific structure here, but I fear we
will have a "lowervisor" (sigh) specific structure for the widely
varied CC/pkvm/etc world.

> Agreed. That also implies that a vRID is quite independent to
> the IOMMU right? So, I think that the reason of adding a vRID
> to the virtual deivce uAPI/structure should be IOMMU requiring
> it?

I would like to use this API to link in the CC/pkvm/etc world, and use
it to create not just the vIOMMU components but link up to the
"lowervisor" components as well, since it is all the same stuff
basically.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ