From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [virtio-comment] [PATCH] *** Vhost-pci RFC v2 *** Date: Mon, 29 Aug 2016 18:41:59 +0300 Message-ID: <20160829183717-mutt-send-email-mst@kernel.org> References: <1466345649-64841-1-git-send-email-wei.w.wang@intel.com> <286AC319A985734F985F78AFA26841F7CB5968@shsmsx102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "virtio-comment@lists.oasis-open.org" , "stefanha@redhat.com" , "pbonzini@redhat.com" To: "Wang, Wei W" Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: <286AC319A985734F985F78AFA26841F7CB5968@shsmsx102.ccr.corp.intel.com> List-Id: kvm.vger.kernel.org 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 This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beOhL-00075r-N8 for qemu-devel@nongnu.org; Mon, 29 Aug 2016 11:42:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beOhG-0004P5-Fw for qemu-devel@nongnu.org; Mon, 29 Aug 2016 11:42:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beOhG-0004Of-Aq for qemu-devel@nongnu.org; Mon, 29 Aug 2016 11:42:02 -0400 Date: Mon, 29 Aug 2016 18:41:59 +0300 From: "Michael S. Tsirkin" Message-ID: <20160829183717-mutt-send-email-mst@kernel.org> References: <1466345649-64841-1-git-send-email-wei.w.wang@intel.com> <286AC319A985734F985F78AFA26841F7CB5968@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <286AC319A985734F985F78AFA26841F7CB5968@shsmsx102.ccr.corp.intel.com> Subject: Re: [Qemu-devel] [virtio-comment] [PATCH] *** Vhost-pci RFC v2 *** List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Wang, Wei W" Cc: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "virtio-comment@lists.oasis-open.org" , "stefanha@redhat.com" , "pbonzini@redhat.com" 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