On Wed, Dec 13, 2017 at 3:01 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Dec 13, 2017 at 12:35:21PM +0000, Stefan Hajnoczi wrote: >> I'm not saying that DPDK should use libvhost-user. I'm saying that it's >> easy to add vfio vhost-pci support (for the PCI adapter I described) to >> DPDK. This patch series would require writing a completely new slave >> for vhost-pci because the device interface is so different from >> vhost-user. > > The main question is how appropriate is the vhost user protocol > for passing to guests. And I am not sure at this point. > > Someone should go over vhost user messages and see whether they are safe > to pass to guest. If most are then we can try the transparent approach. > If most aren't then we can't and might as well use the proposed protocol > which at least has code behind it.
I have done that: Master message types -------------------- * VHOST_USER_GET_FEATURES Safe to pass through. * VHOST_USER_SET_FEATURES Safe to pass through. * VHOST_USER_GET_PROTOCOL_FEATURES QEMU must mask unsupported VHOST_USER_PROTOCOL_F_* bits that the guest set. * VHOST_USER_SET_PROTOCOL_FEATURES Safe to pass through. * VHOST_USER_SET_OWNER Safe to pass through. * VHOST_USER_RESET_OWNER Unused message, ignore and do not pass through. * VHOST_USER_SET_MEM_TABLE Set up BARs before sending a VHOST_USER_SET_MEM_TABLE to the guest. * VHOST_USER_SET_LOG_BASE Set up log shared memory region before sending VHOST_USER_SET_LOG_BASE to the guest. * VHOST_USER_SET_LOG_FD Set up log doorbell before sending VHOST_USER_SET_LOG_FD to the guest. * VHOST_USER_SET_VRING_NUM Safe to pass through. * VHOST_USER_SET_VRING_ADDR Passthrough if QEMU isn't doing IOMMU. Otherwise remap the addresses before passing them to the guest. * VHOST_USER_SET_VRING_BASE Safe to pass through. * VHOST_USER_GET_VRING_BASE Safe to pass through. * VHOST_USER_SET_VRING_KICK Set up vring kick doorbell (unless bit 8 is set) before sending VHOST_USER_SET_VRING_KICK to the guest. * VHOST_USER_SET_VRING_CALL Set up the vring call doorbell (unless bit 8 is set) before sending VHOST_USER_SET_VRING_CALL to the guest. * VHOST_USER_SET_VRING_ERR Set up the vring err doorbell (unless bit 8 is set) before sending VHOST_USER_SET_VRING_ERR to the guest. * VHOST_USER_GET_QUEUE_NUM Safe to pass through. * VHOST_USER_SET_VRING_ENABLE Safe to pass through. * VHOST_USER_SEND_RARP Safe to pass through. * VHOST_USER_NET_SET_MTU Safe to pass through. * VHOST_USER_SET_SLAVE_REQ_FD Stash slave req fd so that Slave-to-Master queue messages can be relayed before sending VHOST_USER_SET_SLAVE_REQ_FD to guest. * VHOST_USER_IOTLB_MSG Translate addresses if QEMU implements IOMMU before sending VHOST_USER_IOTLB_MSG to the guest. * VHOST_USER_SET_VRING_ENDIAN Safe to pass through. Slave message types ------------------- * VHOST_USER_SLAVE_IOTLB_MSG Handled by QEMU if it implements the IOMMU. > I took a quick look and I doubt we can do something that is both > compatible with the existing vhost-user and will make it possible to > extend the protocol without qemu changes. Let's assume I pass a new > message over the vhost-user channel. How do we know it's safe to pass > it to the guest? > > That's why we gate any protocol change on a feature bit and must parse > all messages. QEMU must parse all messages and cannot pass through unknown messages. Think of QEMU vhost-pci as both a vhost-user slave to the other VM and a vhost-user master to the guest. QEMU changes are necessary when the vhost protocol is extended. Device interface changes are only necessary if doorbells or shared memory regions are added, any other protocol changes do not change the device interface. Stefan
