Re: MMIO/PIO dispatch file descriptors (ioregionfd) design discussion

[Peter Xu <peterx@redhat.com>]

On Wed, Nov 25, 2020 at 12:44:07PM -0800, Elena Afanasova wrote:

[...]

> Wire protocol
> -------------
> The protocol spoken over the file descriptor is as follows. The device reads
> commands from the file descriptor with the following layout::
> 
>   struct ioregionfd_cmd {
>       __u32 info;
>       __u32 padding;
>       __u64 user_data;
>       __u64 offset;
>       __u64 data;
>   };

I'm thinking whether it would be nice to have a handshake on the wire protocol
before starting the cmd/resp sequence.

I was thinking about migration - we have had a hard time trying to be
compatible between old/new qemus.  Now we fixed those by applying the same
migration capabilities on both sides always so we do the handshake "manually"
from libvirt, but it really should be done with a real handshake on the
channel, imho..  That's another story, for sure.

My understanding is that the wire protocol is kind of a standalone (but tiny)
protocol between kvm and the emulation process.  So I'm thinking the handshake
could also help when e.g. kvm can fallback to an old version of wire protocol
if it knows the emulation binary is old.  Ideally, I think this could even
happen without VMM's awareness.

[...]

> Ordering
> --------
> Guest accesses are delivered in order, including posted writes.

I'm wondering whether it should prepare for out-of-order commands assuming if
there's no handshake so harder to extend, just in case there could be some slow
commands so we still have chance to reply to a very trivial command during
handling the slow one (then each command may require a command ID, too).  But
it won't be a problem at all if we can easily extend the wire protocol so the
ordering constraint can be extended too when really needed, and we can always
start with in-order-only requests.

Thanks,

-- 
Peter Xu