On Thu, Aug 14, 2025 at 12:42 PM Michael S. Tsirkin <m...@redhat.com> wrote:
>
> On Thu, Aug 14, 2025 at 11:36:22AM +0800, Jason Wang wrote:
> > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> > > > index addbc209275a..37029df94aaf 100644
> > > > --- a/include/linux/virtio.h
> > > > +++ b/include/linux/virtio.h
> > > > @@ -40,6 +40,13 @@ struct virtqueue {
> > > > void *priv;
> > > > };
> > > >
> > > > +union vring_mapping_token {
> > > > + /* Device that performs DMA */
> > > > + struct device *dma_dev;
> > > > + /* Transport specific token used for doing map */
> > > > + void *opaque;
> > >
> > > Please just declare whatever structure you want it to be.
> >
> > It's an opaque one and so
> >
> > 1) the virtio core knows nothing about that because it could be
> > transport or device specific
> > 2) no assumption of the type and usage, it just receive it from the
> > transport and pass it back when doing the mapping
> >
> > It should work like page->private etc.
> >
> > Does this make sense?
> >
> > Thanks
>
> I fully expect most devices simply to use DMA here and no weird
> tricks. vduse is the weird one, but I don't see us making it
> grow much beyond that.
>
> So I think for now we can just make it vduse_iova_domain *. If we see
> it's getting out of hand with too many types, we can think of solutions.
>
I've sent my series of adding ASID to VDUSE, which uses this series'
token on each vq group, on top of this version of the DMA rework.
This patch [1] and the next one are the one that reworks the token to
an empty struct, so virtio can handle it in an opaque way and VDUSE
can convert it back and forth in a type safe way, skipping the void *.
Please let me know if you prefer to import a VDUSE header into the
virtio config header or to make a VDUSE forward declaration instead of
going through the empty struct to preserve layer boundaries.
There is one usage I've not been able to convert though. Jason, could
you take a look? It is marked as TODO in my series. I'm not sure if
that's also an abuse of the void * in the DMA rework to be honest, but
it should be easy to correct.
[1]
https://lore.kernel.org/all/20250818085711.3461758-4-epere...@redhat.com/T/#u
