> * 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.
But guest can't use it, now can it? What guest needs is a mapping to interrupts. > * 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. Same here. what guest needs is mapping from io to notifications, right? --- > > 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 I guess you have a different definition of a device interface than myself - I consider it an interface change if a feature bit changes :) -- MST