On Wed, Jun 5, 2024 at 1:16 PM Stefan Hajnoczi <stefa...@redhat.com> wrote:
> On Wed, Jun 05, 2024 at 09:24:36AM +0200, Albert Esteve wrote: > > On Tue, Jun 4, 2024 at 8:16 PM Stefan Hajnoczi <stefa...@redhat.com> > wrote: > > > > > On Thu, May 30, 2024 at 05:22:22PM +0200, Albert Esteve wrote: > > > > Hi all, > > > > > > > > This is an early attempt to have backends > > > > support dynamic fd mapping into shared > > > > memory regions. As such, there are a few > > > > things that need settling, so I wanted to > > > > post this first to have some early feedback. > > > > > > > > The usecase for this is, e.g., to support > > > > vhost-user-gpu RESOURCE_BLOB operations, > > > > or DAX Window request for virtio-fs. In > > > > general, any operation where a backend > > > > would need to mmap an fd to a shared > > > > memory so that the guest can access it. > > > > > > I wanted to mention that this sentence confuses me because: > > > > > > - The frontend will mmap an fd into the guest's memory space so that a > > > VIRTIO Shared Memory Region is exposed to the guest. The backend > > > requests the frontend to perform this operation. The backend does not > > > invoke mmap itself. > > > > > > > Sorry for the confused wording. It is true that the backend does not > > do the mmap, but requests it to be done. One point of confusion for > > me from your sentence is that I refer to the driver as the frontend, > > They are different concepts. Frontend is defined in the vhost-user spec > and driver is defined in the VIRTIO spec. > Ah! I see. Then you may probably want to ignore some of my responses to other mail of this series :P Thanks for the clarification. > > The frontend is the application that uses vhost-user protocol messages > to communicate with the backend. > > The driver uses VIRTIO device model interfaces like virtqueues to > communicate with the device. > > > and the mapping is done by the VMM (i.e., QEMU). > > > > But yeah, I agree and the scenario you describe is what > > I had in mind. Thanks for pointing it out. I will rephrase it > > in follow-up patches. > > Thanks! > > > > > > > > > > > - "Shared memory" is ambiguous. Please call it VIRTIO Shared Memory > > > Region to differentiate from vhost-user shared memory tables/regions. > > > > > > > Ok! > > > > > > > > > > > The request will be processed by the VMM, > > > > that will, in turn, trigger a mmap with > > > > the instructed parameters (i.e., shmid, > > > > shm_offset, fd_offset, fd, lenght). > > > > > > > > As there are already a couple devices > > > > that could benefit of such a feature, > > > > and more could require it in the future, > > > > my intention was to make it generic. > > > > > > > > To that end, I declared the shared > > > > memory region list in `VirtIODevice`. > > > > I could add a couple commodity > > > > functions to add new regions to the list, > > > > so that the devices can use them. But > > > > I wanted to gather some feedback before > > > > refining it further, as I am probably > > > > missing some required steps/or security > > > > concerns that I am not taking into account. > > > > > > > > Albert Esteve (1): > > > > vhost-user: add shmem mmap request > > > > > > > > docs/interop/vhost-user.rst | 23 ++++++++ > > > > hw/virtio/vhost-user.c | 106 > ++++++++++++++++++++++++++++++++++++ > > > > hw/virtio/virtio.c | 2 + > > > > include/hw/virtio/virtio.h | 3 + > > > > 4 files changed, 134 insertions(+) > > > > > > > > -- > > > > 2.44.0 > > > > > > > >
