Hi Michael,

quoted

           __u32 guest_cid;

Given that cid is like an IP address, 32 bit seems too
limiting. I would go for a 64 bit one or maybe even 128 bit,
so that e.g. GUIDs can be used there.

That's likely based on what vSockets uses, which is in turn based on
what the VMCI device exposes (which is what vSockets was originally
built on), so unfortunately it's too late to extend that type.
However, that still allows just under 2^32 VMs per host (there are
three reserved values).

quoted

           __u32   dst_port;

Ports are 32 bit? I guess most applications can't work with >16 bit.

As with the cid, the width of the port type comes from vSockets,
which is what this plugs into.

Also, why put cid's in all packets? They are only needed
when you create a connection, no? Afterwards port numbers
can be used.

The cid is present in DGRAM packets and STREAM _control_ packets
(connection handshake, signal read/write and so forth).  I don't
think the intent here is for it to be in STREAM _data_ packets,
but Asias can clarify.

quoted

Virtio VM socket connection creation:
1) Client sends VIRTIO_VSOCK_OP_REQUEST to server
2) Server reponses with VIRTIO_VSOCK_OP_NEGOTIATE to client
3) Client sends VIRTIO_VSOCK_OP_OFFER to server
4) Server responses with VIRTIO_VSOCK_OP_ATTACH to client

What's the reason for a 4 stage setup? Most transports
make do with 3.

I'm guessing that's also based on the original vSockets/VMCI
implementation, where the NEGOTIATE/OFFER stages are used to
negotiate the underlying transport buffer size (in VMCI, the
queuepair that underlies a STREAM socket).  The virtio
transport can probably use 3.

Thanks!
- Andy