> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Saturday, April 13, 2024 11:47 AM
> 
> This is an experimental RFC series for VIOMMU infrastructure, using NVIDIA
> Tegra241 (Grace) CMDQV as a test instance.
> 
> VIOMMU obj is used to represent a virtual interface (iommu) backed by an
> underlying IOMMU's HW-accelerated feature for virtualizaion: for example,
> NVIDIA's VINTF (v-interface for CMDQV) and AMD"s vIOMMU.
> 
> VQUEUE obj is used to represent a virtual command queue (buffer) backed
> by
> an underlying IOMMU command queue to passthrough for VMs to use
> directly:
> for example, NVIDIA's Virtual Command Queue and AMD's Command Buffer.
> 

is VCMDQ more accurate? AMD also supports fault queue passthrough
then VQUEUE sounds broader than a cmd queue...

On Wed, May 22, 2024 at 08:40:00AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: Saturday, April 13, 2024 11:47 AM
> > 
> > This is an experimental RFC series for VIOMMU infrastructure, using NVIDIA
> > Tegra241 (Grace) CMDQV as a test instance.
> > 
> > VIOMMU obj is used to represent a virtual interface (iommu) backed by an
> > underlying IOMMU's HW-accelerated feature for virtualizaion: for example,
> > NVIDIA's VINTF (v-interface for CMDQV) and AMD"s vIOMMU.
> > 
> > VQUEUE obj is used to represent a virtual command queue (buffer) backed
> > by
> > an underlying IOMMU command queue to passthrough for VMs to use
> > directly:
> > for example, NVIDIA's Virtual Command Queue and AMD's Command Buffer.
> > 
> 
> is VCMDQ more accurate? AMD also supports fault queue passthrough
> then VQUEUE sounds broader than a cmd queue...

Is there a reason VQUEUE couldn't handle the fault/etc queues too? The
only difference is direction, there is still a doorbell/etc.

Jason

On Wed, May 22, 2024 at 01:48:18PM -0300, Jason Gunthorpe wrote:
> On Wed, May 22, 2024 at 08:40:00AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > Sent: Saturday, April 13, 2024 11:47 AM
> > > 
> > > This is an experimental RFC series for VIOMMU infrastructure, using NVIDIA
> > > Tegra241 (Grace) CMDQV as a test instance.
> > > 
> > > VIOMMU obj is used to represent a virtual interface (iommu) backed by an
> > > underlying IOMMU's HW-accelerated feature for virtualizaion: for example,
> > > NVIDIA's VINTF (v-interface for CMDQV) and AMD"s vIOMMU.
> > > 
> > > VQUEUE obj is used to represent a virtual command queue (buffer) backed
> > > by
> > > an underlying IOMMU command queue to passthrough for VMs to use
> > > directly:
> > > for example, NVIDIA's Virtual Command Queue and AMD's Command Buffer.
> > > 
> > 
> > is VCMDQ more accurate? AMD also supports fault queue passthrough
> > then VQUEUE sounds broader than a cmd queue...
> 
> Is there a reason VQUEUE couldn't handle the fault/etc queues too? The
> only difference is direction, there is still a doorbell/etc.

Yea, SMMU also has Event Queue and PRI queue. Though I haven't
got time to sit down to look at Baolu's work closely, the uAPI
seems to be a unified one for all IOMMUs. And though I have no
intention to be against that design, yet maybe there could be
an alternative in a somewhat HW specific language as we do for
invalidation? Or not worth it?

Thanks
Nicolin

On Wed, May 22, 2024 at 12:47:19PM -0700, Nicolin Chen wrote:
> On Wed, May 22, 2024 at 01:48:18PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2024 at 08:40:00AM +0000, Tian, Kevin wrote:
> > > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > > Sent: Saturday, April 13, 2024 11:47 AM
> > > > 
> > > > This is an experimental RFC series for VIOMMU infrastructure, using NVIDIA
> > > > Tegra241 (Grace) CMDQV as a test instance.
> > > > 
> > > > VIOMMU obj is used to represent a virtual interface (iommu) backed by an
> > > > underlying IOMMU's HW-accelerated feature for virtualizaion: for example,
> > > > NVIDIA's VINTF (v-interface for CMDQV) and AMD"s vIOMMU.
> > > > 
> > > > VQUEUE obj is used to represent a virtual command queue (buffer) backed
> > > > by
> > > > an underlying IOMMU command queue to passthrough for VMs to use
> > > > directly:
> > > > for example, NVIDIA's Virtual Command Queue and AMD's Command Buffer.
> > > > 
> > > 
> > > is VCMDQ more accurate? AMD also supports fault queue passthrough
> > > then VQUEUE sounds broader than a cmd queue...
> > 
> > Is there a reason VQUEUE couldn't handle the fault/etc queues too? The
> > only difference is direction, there is still a doorbell/etc.
> 
> Yea, SMMU also has Event Queue and PRI queue. Though I haven't
> got time to sit down to look at Baolu's work closely, the uAPI
> seems to be a unified one for all IOMMUs. And though I have no
> intention to be against that design, yet maybe there could be
> an alternative in a somewhat HW specific language as we do for
> invalidation? Or not worth it?

I was thinking not worth it, I expect a gain here is to do as AMD has
done and make the HW dma the queues directly to guest memory.

IMHO the primary issue with the queues is DOS, as having any shared
queue across VMs is dangerous in that way. Allowing each VIOMMU to
have its own private queue and own flow control helps with that.

Jason

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, May 23, 2024 7:29 AM
> 
> On Wed, May 22, 2024 at 12:47:19PM -0700, Nicolin Chen wrote:
> > On Wed, May 22, 2024 at 01:48:18PM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 22, 2024 at 08:40:00AM +0000, Tian, Kevin wrote:
> > > > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > > > Sent: Saturday, April 13, 2024 11:47 AM
> > > > >
> > > > > This is an experimental RFC series for VIOMMU infrastructure, using
> NVIDIA
> > > > > Tegra241 (Grace) CMDQV as a test instance.
> > > > >
> > > > > VIOMMU obj is used to represent a virtual interface (iommu) backed
> by an
> > > > > underlying IOMMU's HW-accelerated feature for virtualizaion: for
> example,
> > > > > NVIDIA's VINTF (v-interface for CMDQV) and AMD"s vIOMMU.
> > > > >
> > > > > VQUEUE obj is used to represent a virtual command queue (buffer)
> backed
> > > > > by
> > > > > an underlying IOMMU command queue to passthrough for VMs to
> use
> > > > > directly:
> > > > > for example, NVIDIA's Virtual Command Queue and AMD's Command
> Buffer.
> > > > >
> > > >
> > > > is VCMDQ more accurate? AMD also supports fault queue passthrough
> > > > then VQUEUE sounds broader than a cmd queue...
> > >
> > > Is there a reason VQUEUE couldn't handle the fault/etc queues too? The
> > > only difference is direction, there is still a doorbell/etc.

No reason. the description made it specific to a cmd queue which
led me the impression that we may want to create a separate
fault queue.

> >
> > Yea, SMMU also has Event Queue and PRI queue. Though I haven't
> > got time to sit down to look at Baolu's work closely, the uAPI
> > seems to be a unified one for all IOMMUs. And though I have no
> > intention to be against that design, yet maybe there could be
> > an alternative in a somewhat HW specific language as we do for
> > invalidation? Or not worth it?
> 
> I was thinking not worth it, I expect a gain here is to do as AMD has
> done and make the HW dma the queues directly to guest memory.
> 
> IMHO the primary issue with the queues is DOS, as having any shared
> queue across VMs is dangerous in that way. Allowing each VIOMMU to
> have its own private queue and own flow control helps with that.
> 

and also shorter delivering path with less data copy?

On Wed, May 22, 2024 at 11:43:51PM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Thursday, May 23, 2024 7:29 AM
> > On Wed, May 22, 2024 at 12:47:19PM -0700, Nicolin Chen wrote:
> > > Yea, SMMU also has Event Queue and PRI queue. Though I haven't
> > > got time to sit down to look at Baolu's work closely, the uAPI
> > > seems to be a unified one for all IOMMUs. And though I have no
> > > intention to be against that design, yet maybe there could be
> > > an alternative in a somewhat HW specific language as we do for
> > > invalidation? Or not worth it?
> >
> > I was thinking not worth it, I expect a gain here is to do as AMD has
> > done and make the HW dma the queues directly to guest memory.
> >
> > IMHO the primary issue with the queues is DOS, as having any shared
> > queue across VMs is dangerous in that way. Allowing each VIOMMU to
> > have its own private queue and own flow control helps with that.
> >
> 
> and also shorter delivering path with less data copy?

Should I interpret that as a yes for fault report via VQUEUE?

We only have AMD that can HW dma the events to the guest queue
memory. Others all need a backward translation of (at least) a
physical dev ID to a virtual dev ID. This is now doable in the
kernel by the ongoing vdev_id design by the way. So kernel then
can write the guest memory directly to report events?

Thanks
Nicolin

On Wed, May 22, 2024 at 08:09:12PM -0700, Nicolin Chen wrote:
> On Wed, May 22, 2024 at 11:43:51PM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > Sent: Thursday, May 23, 2024 7:29 AM
> > > On Wed, May 22, 2024 at 12:47:19PM -0700, Nicolin Chen wrote:
> > > > Yea, SMMU also has Event Queue and PRI queue. Though I haven't
> > > > got time to sit down to look at Baolu's work closely, the uAPI
> > > > seems to be a unified one for all IOMMUs. And though I have no
> > > > intention to be against that design, yet maybe there could be
> > > > an alternative in a somewhat HW specific language as we do for
> > > > invalidation? Or not worth it?
> > >
> > > I was thinking not worth it, I expect a gain here is to do as AMD has
> > > done and make the HW dma the queues directly to guest memory.
> > >
> > > IMHO the primary issue with the queues is DOS, as having any shared
> > > queue across VMs is dangerous in that way. Allowing each VIOMMU to
> > > have its own private queue and own flow control helps with that.
> > >
> > 
> > and also shorter delivering path with less data copy?
> 
> Should I interpret that as a yes for fault report via VQUEUE?
> 
> We only have AMD that can HW dma the events to the guest queue
> memory. Others all need a backward translation of (at least) a
> physical dev ID to a virtual dev ID. This is now doable in the
> kernel by the ongoing vdev_id design by the way. So kernel then
> can write the guest memory directly to report events?

I don't think we should get into kernel doing direct access at this
point, lets focus on basic functionality before we get to
microoptimizations like that.

So long as the API could support doing something like that it could be
done after benchmarking/etc.

Jason