linux-kernel - Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV

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: <20241007171840.GZ1365916@nvidia.com>
Date: Mon, 7 Oct 2024 14:18:40 -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 01:33:33PM -0700, Nicolin Chen wrote:
> On Fri, Oct 04, 2024 at 05:17:46PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
> > 
> > > With that, I wonder what is better for the initial version of
> > > this structure, a generic virtual ID or a driver-named ID like
> > > "Stream ID"? The latter might be more understandable/flexible, 
> > > so we won't need to justify a generic virtual ID along the way
> > > if something changes in the nature?
> > 
> > I think the name could be a bit more specific "viommu_device_id"
> > maybe? And elaborate in the kdoc that this is about the identifier
> > that the iommu HW itself uses.
> 
> A "vIOMMU Device ID" might sound a bit confusing with an ID of a
> vIOMMU itself :-/
> 
> At this moment, I named it "virt_id" in uAPI with a description:
> " * @virt_id: Virtual device ID per vIOMMU"
> 
> I could add to that (or just in the documentation):
> "e.g. ARM's Stream ID, AMD's DeviceID, Intel's Context Table ID"
> to clarify it further.

Yeah probably best

> > Alexey is working on vIOMMU support in CC which has the trusted world
> > do some of the trusted vIOMMU components. I'm hoping the other people
> > in this area will look at his design and make it fit nicely to
> > everyone.
> 
> Oh, I didn't connect the dots that lowervisor must rely on the
> vIOMMU too -- I'd need to check the CC stuff in detail. In that
> case, having it in vIOMMU uAPI totally makes sense.

I think we are still getting through this, and I do wonder how to
manage it with so much stuff still in flux and sometimes private.

At least for AMD's CC case where there is an entanglement with the
physical IOMMU it seems like it makes sense.

Even in the pKVM type case I think you end up ripping the translation
away from the "physical" iommu and there should be some coordination
to ensure this handover is clean and undone when iommufd is
closed. But I wonder how the S2 works there..

Jason