> On Aug 29, 2017, at 4:36 AM, Dexuan Cui <decui@xxxxxxxxxxxxx> wrote: > >> From: Dexuan Cui >> Sent: Tuesday, August 22, 2017 21:21 >>> ... >>> ... >>> The only problem here would be the potential for a guest and a host app >> to >>> have a conflict wrt port numbers, even though they would be able to >>> operate fine, if restricted to their appropriate transport. >>> >>> Thanks, >>> Jorgen >> >> Hi Jorgen, Stefan, >> Thank you for the detailed analysis! >> You have a much better understanding than me about the complex >> scenarios. Can you please work out a patch? :-) > > Hi Jorgen, Stefan, > May I know your plan for this? I’d be happy to discuss this now, but I don’t have time to work on the actual implementation in the next couple of weeks. For the guest, we agree that registering a guest transport should be tied to either the hypervisor running the guest, or the existence of the appropriate virtual hardware. My main concern is that our existing software relies on the current behavior of auto-loading the VMCI transport on the host side. So changing that behavior could cause trouble for our existing Linux users. I’m wondering whether it would be possible to support multiple host side transports. Since it is theoretically possible to run multiple hypervisors at the same time, there would even be a use case for this. If the assignment of CIDs is made unique across all transports, a connection initiated by the host side will get directed to the appropriate transport based on the CID. Any traffic coming from a guest will naturally be using the appropriate transport. Host side applications will have to share the port space as well. This would require tracking CIDs as a common resource across all transports, but make CIDs unique VM addresses on a given host. If we allow multiple host side transports, virtio host side support and vmci should be able to coexist regardless of the order of initialization. Thanks, Jorgen _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
