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. 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. > > Wei Wang (1): > > Vhost-pci RFC v2: a new virtio device for inter-VM communication > > > > vhost-pci.patch | 341 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 341 insertions(+) > > create mode 100755 vhost-pci.patch > > > > Hi Michael, > > Would you be able to look into the design? Thanks. > > Best, > Wei -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
