OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Memory sharing device


* Roman Kiryanov (rkir@google.com) wrote:
> Hi Dave,
> 
> > In virtio-fs we have two separate stages:
> >   a) A shared arena is setup (and that's what the spec Stefan pointed to is about) -
> >      it's statically allocated at device creation and corresponds to a chunk
> >      of guest physical address space
> 
> We do exactly the same:
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/hw/pci/goldfish_address_space.c#659
> 
> >   b) During operation the guest kernel asks for files to be mapped into
> >      part of that arena dynamically, using commands sent over the queue
> >      - our queue carries FUSE commands, and we've added two new FUSE
> >      commands to perform the map/unmap.  They talk in terms of offsets
> >      within the shared arena, rather than GPAs.
> 
> In our case we have no files to map, only pointers returned from
> OpenGL or Vulkan.
> Do you have the approach to share for this use case?

I should say that the spec I'm talking aobut is my 1st virito spec
change; so take my ideas with a large pinch of salt!

> > How do you transmit the glMapBufferRange command from QEMU driver to
> > host?
> 
> In December we did this by passing these bits over our guest-host channel
> (another driver, goldfish_pipe). Frank is currently working on moving
> this into our memory
> mapping device as "something changed in the memory you shared".
> 
> Do you this it is possible to have virtio-pipe where we could send
> arbitrary blobs between
> guest and host? We want to move all our drivers into userspace so we
> could share memory
> using the device you are currently working on and this virtio-pipe to
> pass MMIOs and IRQs
> to control our devices to avoid dealing with kernel drivers at all.

It sounds to me like you want something like a virtio-pipe, with
a shared arena (like specified using the spec change I suggested)
but with either a separate queue, or commands in the queue to do the
mapping/unmapping of your GL pointers from your arena.

Dave

> Thank you.
> 
> Regards,
> Roman.
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]