linux-kernel - Re: [PATCH V5 4/9] virtio: introduce vring_mapping

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: <CAJaqyWcxV+f6dhKLscGGy0bw2YWJ8NaJ4QN+Qe3Ax7C+Lf4X-g@mail.gmail.com>
Date: Mon, 18 Aug 2025 11:09:44 +0200
From: Eugenio Perez Martin <eperezma@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Jason Wang <jasowang@...hat.com>, xuanzhuo@...ux.alibaba.com, 
	virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	hch@...radead.org
Subject: Re: [PATCH V5 4/9] virtio: introduce vring_mapping_token

On Thu, Aug 14, 2025 at 12:42 PM Michael S. Tsirkin <mst@...hat.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-eperezma@redhat.com/T/#u