qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Chenbo Xia" <chenbo.xia@intel.com>, "Cindy Lu" <lulu@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	jasowang@redhat.com, qemu-devel@nongnu.org,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
	kraxel@redhat.com,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Changpeng Liu" <changpeng.liu@intel.com>
Subject: Re: VHOST_USER_PROTOCOL_F_VDPA
Date: Thu, 10 Sep 2020 10:55:00 +0200	[thread overview]
Message-ID: <ea150955-fc89-147f-0fdc-1ff60b35a6e6@redhat.com> (raw)
In-Reply-To: <20200821110822.GA205318@stefanha-x1.localdomain>


[-- Attachment #1.1: Type: text/plain, Size: 2784 bytes --]

Hi Stefan,

On 8/21/20 1:08 PM, Stefan Hajnoczi wrote:
> The first vDPA ioctls have been added to the vhost-user protocol and I
> wonder if it's time to fully change the vhost-user protocol's focus to
> providing a full VIRTIO device model like vDPA does.
> 
> Initially vhost-user was just used for vhost-net. As a result it didn't
> need the full VIRTIO device model including the configuration space and
> device status register.
> 
> Over the years device-specific messages were added to extend vhost-user
> to cover more of the VIRTIO device model. vhost-user-blk needed
> configuration space support, for example.
> 
> The problem for VMMs and device backend implementors is that the
> protocol is currently positioned halfway between the original vhost-net
> approach and the full VIRTIO device model. Even if a VMM implements
> VHOST_USER_GET_CONFIG, it can only expect it to work with
> vhost-user-blk, not vhost-user-net. Similarly, a vhost-user-net device
> backend cannot implement VHOST_USER_GET_CONFIG and expect all VMMs to
> allow it to participate in configuration space emulation because
> existing VMMs won't send that message.
> 
> The current approach where each device type uses a undocumented subset
> of vhost-user messages is really messy. VMM and device backend
> implementors have to look at existing implementations to know what is
> expected for a given device type. It would be nice to switch to the
> VIRTIO device model so that the VIRTIO specification can be used as the
> reference for how device types work.
> 
> Now that vDPA is here and extends the kernel vhost ioctls with a full
> VIRTIO device model, it might be a good time to revise the vhost-user
> protocol.
> 
> A vdpa-user protocol (or vhost-user 2.0) would replace the current mess
> with a full VIRTIO device model. Both VMMs and device backends would
> require changes to support this, but it would be a cleaner path forward
> for the vhost-user protocol.
> 
> One way of doing this would be a new VHOST_USER_PROTOCOL_F_VDPA feature
> bit that indicates all the currently existing Linux vDPA ioctl messages
> are available. Legacy vhost-user messages with overlapping functionality
> must not be used when this bit is set. Most importantly, device backends
> need to implement the full VIRTIO device model, regardless of device
> type (net, blk, scsi, etc).
> 
> The device type most affected by this change would be virtio-net. The
> other device types are already closer to the full VIRTIO device model.
> 
> I wanted to share this idea in case someone is currently trying to
> figure out how to add more VIRTIO device model functionality to
> vhost-user.
> 
> Stefan
> 

I understand the need and like the idea.

Maxime


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-09-10  8:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21 11:08 VHOST_USER_PROTOCOL_F_VDPA Stefan Hajnoczi
2020-09-02  7:42 ` VHOST_USER_PROTOCOL_F_VDPA Jason Wang
2020-09-10  8:55 ` Maxime Coquelin [this message]
2020-09-11 12:54   ` VHOST_USER_PROTOCOL_F_VDPA 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=ea150955-fc89-147f-0fdc-1ff60b35a6e6@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=changpeng.liu@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lulu@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=stefanha@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).