From: "Jorgen S. Hansen" <jhansen@vmware.com>
To: Dexuan Cui <decui@microsoft.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
George Zhang <georgezhang@vmware.com>,
Michal Kubecek <mkubecek@suse.cz>, Asias He <asias@redhat.com>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
Cathy Avery <cavery@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
Rolf Neugebauer <rolf.neugebauer@docker.com>,
Dave Scott <dave.scott@docker.com>,
"Marcelo Cerri" <marcelo.cerri@canonical.com>,
"apw@canonical.com" <apw@canonical.com
Subject: Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
Date: Tue, 29 Aug 2017 15:37:07 +0000 [thread overview]
Message-ID: <61AE41B3-D143-46D2-8C68-009B78AF12C8@vmware.com> (raw)
In-Reply-To: <KL1P15301MB0008087A3EF0A8D037CC4D52BF9F0@KL1P15301MB0008.APCP153.PROD.OUTLOOK.COM>
> On Aug 29, 2017, at 4:36 AM, Dexuan Cui <decui@microsoft.com> 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
next prev parent reply other threads:[~2017-08-29 15:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 8:00 [PATCH] vsock: only load vmci transport on VMware hypervisor by default Dexuan Cui
2017-08-17 13:55 ` Stefan Hajnoczi
2017-08-17 15:16 ` Jorgen S. Hansen
2017-08-18 3:07 ` Dexuan Cui
2017-08-18 15:37 ` Stefan Hajnoczi
2017-08-18 23:07 ` Dexuan Cui
2017-08-22 9:54 ` Stefan Hajnoczi
2017-08-22 13:07 ` Jorgen S. Hansen
2017-08-23 4:21 ` Dexuan Cui
2017-08-29 2:36 ` Dexuan Cui
2017-08-29 15:37 ` Jorgen S. Hansen [this message]
2017-08-31 11:54 ` Stefan Hajnoczi
2017-09-02 6:25 ` Dexuan Cui
2017-09-06 14:11 ` Jorgen S. Hansen
2017-09-06 19:39 ` Dexuan Cui
2017-08-17 17:04 ` David Miller
2017-08-17 18:27 ` Dexuan Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61AE41B3-D143-46D2-8C68-009B78AF12C8@vmware.com \
--to=jhansen@vmware.com \
--cc=apw@canonical.com \
--cc=asias@redhat.com \
--cc=cavery@redhat.com \
--cc=dave.scott@docker.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=georgezhang@vmware.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=jasowang@redhat.com \
--cc=kys@microsoft.com \
--cc=marcelo.cerri@canonical.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=rolf.neugebauer@docker.com \
--cc=stefanha@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox