All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Srivatsa Vaddagiri <vatsa.ml@gmail.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>, virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] Backend libraries for VirtIO device emulation
Date: Mon, 09 Mar 2020 17:42:39 +0000	[thread overview]
Message-ID: <87v9ndifw0.fsf@linaro.org> (raw)
In-Reply-To: <CAMHO8so2zuDS5BjATchFpYk_4Qy4aG76L51qmCg7qkPPfNwmFA@mail.gmail.com>


Srivatsa Vaddagiri <vatsa.ml@gmail.com> writes:

> On Mon, Mar 9, 2020 at 9:16 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
>>
>> That already exists today.  Pick a vhost-user device implementation from
>> QEMU, DPDK/SPDK, or rust-vmm and run it with your VMM of choice.
>>
>> > backend be emulated purely with some shared memory and some sockets for
>> > passing messages/kicks from/to the VMM which then deals with the hypervisor
>> > specifics of the virtio-transport?
>>
>> Yes, that is what vhost-user does.
>
> Are there vhost-user based backends that emulates block and console devices?
>
> From my quick read, vhost-user seems to depend on having backend complete access
> to front-end's memory. Is that true? We are looking for a backend solution that
> does not assume access to whole of front-end memory. Only the memory regions
> hosting IO buffers need to be ideally shared between the two VMs.

I think it currently is true because generally the pointers passed in
the virtqueues are directly into the various internal structures of the
kernel (e.g. pagecache, skb etc.).

Now for linux the are ways of declaring particular buffers to be in
specific locations - ostensibly for things like DMA-ability. But AFAICT
there is no mechanism to communicate the particular locations to be used
to the VMM and backend daemon.

> Also the
> mechanism of memory sharing and signalling between VMs could be very
> hypervisor specific.
> Does vhost-user allow for such hyp-specific memory sharing and
> signalling interfaces?

The daemons I've looked at so far are passed a shm fd and a control fd
from the VMM. From their point of view it's just posix shared memory and
a event queue via a socket. Setting that up is the VMMs problem.

>
> - vatsa


-- 
Alex Bennée

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-03-09 17:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 18:33 [virtio-dev] Backend libraries for VirtIO device emulation Alex Bennée
2020-03-06 19:14 ` Matias Ezequiel Vara Larsen
2020-03-06 20:34   ` Alex Bennée
2020-03-06 19:40 ` Dr. David Alan Gilbert
2020-03-06 20:24   ` Alex Bennée
2020-03-09  8:11     ` Jan Kiszka
2020-03-09 10:44     ` Dr. David Alan Gilbert
2020-03-09 12:12       ` Alex Bennée
2020-03-09 15:08         ` Dr. David Alan Gilbert
2020-03-09 15:46 ` Stefan Hajnoczi
2020-03-09 16:43   ` Alex Bennée
2020-03-11 17:24     ` Stefan Hajnoczi
2020-03-11 18:18       ` Halil Pasic
2020-03-09 17:27   ` Srivatsa Vaddagiri
2020-03-09 17:42     ` Alex Bennée [this message]
2020-03-11 17:28       ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9ndifw0.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=vatsa.ml@gmail.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.