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: Wang, Wei W
Subject: Re: [Qemu-devel] [virtio-comment] [PATCH] *** Vhost-pci RFC v2 ***
Date: Tue, 30 Aug 2016 10:07:39 +0000

On Monday, August 29, 2016 11:42 PM, Michael S. Tsirkin wrote:
> 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*)
> 
> Question would be, does it mean guest is alive or QEMU/vhost thread running is
> alive? And how do you distinguish a guest that crashed from guest that is
> scheduled out?
> 
> Hypervisors generally have ways to detect and handle crashed and stuck guests.
> It is likely a better idea to have a single device to detect this than have 
> each
> device send keep-alive interrupts, interfering with the guest.

Agree that QEMU can detect the guest crash. 
I think we can just handle the guest powering off case, because the crashed 
guest will be powered off or reboot anyway. Please check another email about 
how to handle the situation when a guest powers off. Thanks.

> Given this is not a networking
> transport, isn't it enough to handle this simply as a guest reset?
> you have to handle it anyway.

I think handling this case is not related to the transport type (btw, the 
vhost-pci device can offer multiple transports (net, scsi, console etc.) at the 
same time). 

Best,
Wei




reply via email to

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