From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5475-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 0D5C4985D77 for ; Wed, 20 Feb 2019 15:35:19 +0000 (UTC) MIME-Version: 1.0 References: <20190211092943-mutt-send-email-mst@kernel.org> <20190212112547.GC2715@work-vm> <20190212144741.60083682.cohuck@redhat.com> <20190212090121-mutt-send-email-mst@kernel.org> <20190212164626.GG2715@work-vm> <20190219075415.v4xlw5ywrtmndew5@sirius.home.kraxel.org> <20190220062539.toctrkhk67iyzwnk@sirius.home.kraxel.org> In-Reply-To: From: Frank Yang Date: Wed, 20 Feb 2019 07:35:04 -0800 Message-ID: Content-Type: multipart/alternative; boundary="000000000000cd4a0e0582551af5" Subject: Re: [virtio-dev] Memory sharing device To: Gerd Hoffmann Cc: "Dr. David Alan Gilbert" , "Michael S. Tsirkin" , Cornelia Huck , Roman Kiryanov , Stefan Hajnoczi , virtio-dev@lists.oasis-open.org, Greg Hartman List-ID: --000000000000cd4a0e0582551af5 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 20, 2019 at 7:30 AM Frank Yang wrote: > > > On Tue, Feb 19, 2019 at 10:25 PM Gerd Hoffmann wrote: > >> Hi, >> >> > > That might simlify pass-through of v4l2 host devices, but isn't >> > > necessarily the best choice long-term. >> >> > Right, but if we're not emulating at the v4l2 api level, then it starts >> > looking a lot >> > like the proposed virtio-hostmem; there's a common pattern of >> > direct access to host memory >> >> Typically camera hardware can DMA the image data to any place in memory, >> including guest ram. There is no need to expose host memory to the >> guest for that. The normal virtio workflow with guest-allocated buffers >> will work just fine. >> >> > True, thanks for pointing it out. > Although, I'd still think it is still a bit nicer to do it via a host > memory buffer, > because it'd be outside of guest ram; > we wouldn't have to interface as tightly with the kernel in terms of not > interfering with > other guest RAM usages, > such as equivalents of dma_alloc_coherent with the limitation on CMA and > all. > > > In addition, we'd like to do things in a way >> > that allows virtual drivers/devices to be defined in a manner that >> doesn't >> > require the guest kernel to be updated. >> >> Hmm. I'm wondering whenever you just need a different virtio transport. >> Very simliar to virtio-pci, but instead of using all guest ram (modulo >> iommu quirks) as address space use a pci memory bar as address space. >> virtio rings would live there, all buffers would live there, addresses >> passed around would be offsets into that pci bar. Then your userspace >> driver can just mmap() that pci bar and handle (almost?) everything on >> its own. Maybe a little stub driver in the kernel is needed for ring >> notifications. >> >> > Yeah, that's (almost?) exactly what we want to do / we're doing already > pretty much > with the memory sharing scheme we're using currently. > > Defining it as a transport would also require definition of another virtio > device type > that the userspace drivers talk to, right? > As a transport/device pair, would it break down as, the transport ends up > restricting what kinds of addresses can be referred to in the ring messages > (in the pci memory bar), > then the device provides the userspace drivers with > implementation of mmap() + memory allocation/sharing ops and notification? > > >> > For us, maintaining and upgrading guest kernels in response to tweaks to >> > virtual devices >> > is much more work than modifying a userspace shared library driver that >> > communicates to some virtio driver. >> >> Well, one of the design goals of virtio is that such an upgrade is not >> required. Capabilities of device and driver are negotiated using >> feature flags, which removes the need for lockstep updates of guest and >> host. >> >> > We also have a similar feature flag system, > but yeah it would be great to use the capabilities/flags > to their fullest extent here. > > >> > Thus far, it's suggested that socket or >> > network devices >> > be used for this, because they are general guest/host communication, >> > but they don't have the portability or performance characteristics we >> want. >> >> For high-bandwidth fully agree. >> >> For low-bandwidth (like the sensors discussed elsewhere in the thread) I >> think running some protocol (mqtt, something json-based, ...) over >> virtio-serial or virtio-vsock isn't too bad. >> >> But creating virtio-sensors makes sense too. >> >> > Yeah for performance considerations, sockets seem to be fine. > (for low bandwidth devices that is, just to be clear) > It's just that I've also got concerns on how well sockets work on > non-Linux. > > > > Alternatively emulate something existing, USB Video Class device for >> > > example. >> > >> > Using usb or faking some other transport generally also involves being >> > coupled to that set of kernel code in the guest, which introduces >> > complexity and overhead. Exposing RAM can be a more flexible >> > abstraction. >> >> Well, you get guest drivers for free and all existing software will run >> just fine out-of-the-box. >> >> Which is the reason why there is no virtio-usb for example. xhci has a >> hardware design which can be emulated without much overhead, so the >> performance benefit of virtio-usb over xhci would be pretty close to >> zero. >> >> > That's pretty interesting; from a brief glance at xhci, it looks like what > you're proposing > is that since there usb passthrough already with xhci, > and xhci has something that looks like a virtqueue, > perhaps we can create our own USB driver on the host, > then pass it through. > > It does make things more inconvenient for users though since they would > have to install > usb drivers out of nowhere. Wonder if a usb forwarder virtual device > exists that can talk to some shared library on the host for the xhci queue, > though that might be considered an unsafe plugin. > > >> cheers, >> Gerd >> >> --000000000000cd4a0e0582551af5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 20, 2019 at 7:30 AM Frank= Yang <lfy@google.com> wrote:
=


On Tue, Feb 19, 2019 at 10:25 PM Gerd Hoffmann <kraxel@redhat.com&g= t; wrote:
=C2=A0= Hi,

> > That might simlify pass-through of v4l2 host devices, but isn'= ;t
> > necessarily the best choice long-term.

> Right, but if we're not emulating at the v4l2 api level, then it s= tarts
> looking a lot
> like the proposed virtio-hostmem; there's a common pattern of
> direct access to host memory

Typically camera hardware can DMA the image data to any place in memory, including guest ram.=C2=A0 There is no need to expose host memory to the guest for that.=C2=A0 The normal virtio workflow with guest-allocated buffe= rs
will work just fine.

=C2=A0
True, thanks for pointing it out.
Although, I'd still think it is still a bit nicer to do it via = a host memory buffer,
because it'd be outside of guest ram;
we wouldn't have to interface as tightly with the kernel in te= rms of not interfering with
other guest RAM usages,
suc= h as equivalents of dma_alloc_coherent with the limitation on CMA and all.<= /div>

> In addition, we'd like to do things in a way
> that allows virtual drivers/devices to be defined in a manner that doe= sn't
> require the guest kernel to be updated.

Hmm.=C2=A0 I'm wondering whenever you just need a different virtio tran= sport.
Very simliar to virtio-pci, but instead of using all guest ram (modulo
iommu quirks) as address space use a pci memory bar as address space.
virtio rings would live there, all buffers would live there, addresses
passed around would be offsets into that pci bar.=C2=A0 Then your userspace=
driver can just mmap() that pci bar and handle (almost?) everything on
its own.=C2=A0 Maybe a little stub driver in the kernel is needed for ring<= br> notifications.

=C2=A0
Yeah, that's (almost?) exactly w= hat we want to do / we're doing already pretty much
with the = memory sharing scheme we're using currently.

D= efining it as a transport would also require definition of another virtio d= evice type
that the userspace drivers talk to, right?
As a transport/device pair, would it break down as, the transport ends u= p restricting what kinds of addresses can be referred to in the ring messag= es (in the pci memory bar),
then the device provides the userspac= e drivers with
implementation of mmap() + memory allocation/shari= ng ops and notification?
=C2=A0
> For us, maintaining and upgrading guest kernels in response to tweaks = to
> virtual devices
> is much more work than modifying a userspace shared library driver tha= t
> communicates to some virtio driver.

Well, one of the design goals of virtio is that such an upgrade is not
required.=C2=A0 Capabilities of device and driver are negotiated using
feature flags, which removes the need for lockstep updates of guest and
host.


We also have a similar feature flag sy= stem,
but yeah it would be great to use the capabilities/flags
to their fullest extent here.
=C2=A0
> Thus far, it's suggested that socket or
> network devices
> be used for this, because they are general guest/host communication, > but they don't have the portability or performance characteristics= we want.

For high-bandwidth fully agree.

For low-bandwidth (like the sensors discussed elsewhere in the thread) I think running some protocol (mqtt, something json-based, ...) over
virtio-serial or virtio-vsock isn't too bad.

But creating virtio-sensors makes sense too.

=C2=A0
Yeah for performance considerations,= sockets seem to be fine.
(for low bandw= idth devices that is, just to be clear)=C2=A0
= It's just that I've also got concerns on how well sockets work on n= on-Linux.

> > Alternatively emulate something existing, USB Video Class device = for
> > example.
>
> Using usb or faking some other transport generally also involves being=
> coupled to that set of kernel code in the guest, which introduces
> complexity and overhead.=C2=A0 Exposing RAM can be a more flexible
> abstraction.

Well, you get guest drivers for free and all existing software will run
just fine out-of-the-box.

Which is the reason why there is no virtio-usb for example.=C2=A0 xhci has = a
hardware design which can be emulated without much overhead, so the
performance benefit of virtio-usb over xhci would be pretty close to
zero.

=C2=A0
That's pretty interesting; from = a brief glance at xhci, it looks like what you're proposing
i= s that since there usb passthrough already with xhci,
and xhci ha= s something that looks like a virtqueue,
perhaps we can create ou= r own USB driver on the host,
then pass it through.
It does make things more inconvenient for users though since th= ey would have to install
usb drivers out of nowhere. Wonder if a = usb forwarder virtual device exists that can talk to some shared library on= the host for the xhci queue, though that might be considered an unsafe plu= gin.
=C2=A0