Hi Michael, > > __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). > > __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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
