qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC virtio-dev] vhost-user-slave: add vhost-user slave


From: Wei Wang
Subject: Re: [Qemu-devel] [RFC virtio-dev] vhost-user-slave: add vhost-user slave device type
Date: Tue, 19 Dec 2017 16:00:13 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 12/16/2017 01:05 AM, Stefan Hajnoczi wrote:
The vhost-user slave device facilitates vhost-user device emulation
through vhost-user protocol exchanges and access to shared memory.
Software-defined networking, storage, and other I/O appliances can
provide services through this device.

This device is based on Wei Wang's vhost-pci work.  The vhost-user slave
device differs from vhost-pci because it is a single virtio device type
that exposes the vhost-user protocol instead of a family of new virtio
device types, one for each vhost-user device type.

This device supports vhost-user slave and vhost-user master
reconnection.  It also contains a UUID so that vhost-user slave programs
can identify a specific device among many without using bus addresses.

It is somewhat unconventional for a virtio device because it makes use
of additional resources called doorbells, notifications, and shared
memory.  A mapping of these resources to the virtio PCI transport is
provided.  Other transports, such as CCW may not be able to support
this device.

Hi Stefan,

Sorry for being late. I need to shift my focus to some other things for a week or two.

I still couldn't see how those problems can be solved with this slave device proposal (which vhost-pci doesn't have):

- The complexity of the "relaying" mechanism for two directions (GuestSlave<->QemuSlave<->Master). I couldn't think of a simple way to do this. If you know a *simple* way, could you please describe the detailed steps or show a picture of the details? (I think most of us couldn't see the true advantage over the vhost-pci's method)

- Reusability. We seem to have no chance to reuse one slave implementation for GuestSlave and QemuSlave, which also wasn't your intention as you mentioned. If this couldn't be solved, shall we give up this option?

Best,
Wei




reply via email to

[Prev in Thread] Current Thread [Next in Thread]