qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [virtio-comment] [PATCH] *** Vhost-pci RFC v2 ***


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [virtio-comment] [PATCH] *** Vhost-pci RFC v2 ***
Date: Wed, 31 Aug 2016 12:07:58 -0400
User-agent: Mutt/1.6.2 (2016-07-01)

On Tue, Aug 30, 2016 at 10:08:01AM +0000, Wang, Wei W wrote:
> On Monday, August 29, 2016 11:25 PM, Stefan Hajnoczi wrote:
> > To: Wang, Wei W <address@hidden>
> > Cc: address@hidden; address@hidden; virtio- 
> > address@hidden; address@hidden; address@hidden
> > Subject: Re: [virtio-comment] [PATCH] *** Vhost-pci RFC v2 ***
> > 
> > On Mon, Jun 27, 2016 at 02:01:24AM +0000, Wang, Wei W wrote:
> > > On Sun 6/19/2016 10:14 PM, Wei Wang wrote:
> > > > This RFC proposes a design of vhost-pci, which is a new virtio device 
> > > > type.
> > > > The vhost-pci device is used for inter-VM communication.
> > > >
> > > > Changes in v2:
> > > > 1. changed the vhost-pci driver to use a controlq to send 
> > > > acknowledgement
> > > >    messages to the vhost-pci server rather than writing to the device
> > > >    configuration space;
> > > >
> > > > 2. re-organized all the data structures and the description 
> > > > layout;
> > > >
> > > > 3. removed the VHOST_PCI_CONTROLQ_UPDATE_DONE socket message,
> > which
> > > > is redundant;
> > > >
> > > > 4. added a message sequence number to the msg info structure to 
> > > > identify socket
> > > >    messages, and the socket message exchange does not need to be 
> > > > blocking;
> > > >
> > > > 5. changed to used uuid to identify each VM rather than using the 
> > > > QEMU
> > process
> > > >    id
> > > >
> > >
> > > One more point should be added is that the server needs to send 
> > > periodic socket messages to check if the driver VM is still alive. I 
> > > will add this message support in next version.  (*v2-AR1*)
> > 
> > Either the driver VM could go down or the device VM (server) could go 
> > down.  In both cases there must be a way to handle the situation.
> > 
> > If the server VM goes down it should be possible for the driver VM to 
> > resume either via hotplug of a new device or through messages 
> > reinitializing the dead device when the server VM restarts.
> 
> I got feedbacks from people that the name of device VM and driver VM are 
> difficult to remember. Can we use client (or frontend) VM and server (or 
> backend) VM in the discussion? I think that would sound more straightforward 
> :)

We discussed this in a previous email thread.

Device and driver are the terms used by the virtio spec.  Anyone dealing
with vhost-pci design must be familiar with the virtio spec.

I don't see how using the terminology consistently can be confusing,
unless these people haven't looked at the virtio spec.  In that case
they have no business with working on vhost-pci because virtio is a
prerequisite :).

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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