Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1715282 > unrolled thread
| Started by | Stefan Hajnoczi <stefanha@redhat.com> |
|---|---|
| First post | 2017-08-18 18:00 +0200 |
| Last post | 2017-08-24 18:00 +0200 |
| Articles | 3 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK) Stefan Hajnoczi <stefanha@redhat.com> - 2017-08-18 18:00 +0200
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK) Stefan Hajnoczi <stefanha@redhat.com> - 2017-08-22 12:20 +0200
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK) Stefan Hajnoczi <stefanha@redhat.com> - 2017-08-24 18:00 +0200
| From | Stefan Hajnoczi <stefanha@redhat.com> |
|---|---|
| Date | 2017-08-18 18:00 +0200 |
| Subject | Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK) |
| Message-ID | <ufRQK-5Ky-7@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Aug 15, 2017 at 10:18:41PM +0000, Dexuan Cui wrote:
> +static u32 hvs_get_local_cid(void)
> +{
> + return VMADDR_CID_ANY;
> +}
Interesting concept: the guest never knows its CID. This is nice from a
live migration perspective. Currently VMCI and virtio adjust listen
socket local CIDs after migration.
> +static bool hvs_stream_allow(u32 cid, u32 port)
> +{
> + static const u32 valid_cids[] = {
> + VMADDR_CID_ANY,
Is this for loopback?
> + VMADDR_CID_HOST,
> + };
> + int i;
> +
> + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> + * reserved as ephemeral ports, which are used as the host's ports
> + * when the host initiates connections.
> + */
> + if (port > MAX_HOST_LISTEN_PORT)
> + return false;
Without this if statement the guest will attempt to connect. I guess
there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
connection attempt will fail.
...but hardcode this knowledge into the guest driver?
[toc] | [next] | [standalone]
| From | Stefan Hajnoczi <stefanha@redhat.com> |
|---|---|
| Date | 2017-08-22 12:20 +0200 |
| Message-ID | <uherT-X8-1@gated-at.bofh.it> |
| In reply to | #1715282 |
On Fri, Aug 18, 2017 at 10:23:54PM +0000, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > Sent: Thursday, August 17, 2017 07:56
> > To: Dexuan Cui <decui@microsoft.com>
> > On Tue, Aug 15, 2017 at 10:18:41PM +0000, Dexuan Cui wrote:
> > > +static u32 hvs_get_local_cid(void)
> > > +{
> > > + return VMADDR_CID_ANY;
> > > +}
> >
> > Interesting concept: the guest never knows its CID. This is nice from a
> > live migration perspective. Currently VMCI and virtio adjust listen
> > socket local CIDs after migration.
> >
> > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > +{
> > > + static const u32 valid_cids[] = {
> > > + VMADDR_CID_ANY,
> >
> > Is this for loopback?
>
> No, we don't support lookback in Linux VM, at least for now.
> In our Linux implementation, Linux VM can only connect to the host, and
> here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> the same as VMADDR_CID_HOST.
VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
> > > + VMADDR_CID_HOST,
> > > + };
> > > + int i;
> > > +
> > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF)
> > is
> > > + * reserved as ephemeral ports, which are used as the host's ports
> > > + * when the host initiates connections.
> > > + */
> > > + if (port > MAX_HOST_LISTEN_PORT)
> > > + return false;
> >
> > Without this if statement the guest will attempt to connect. I guess
> > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > connection attempt will fail.
>
> You're correct.
> To use the vsock common infrastructure, we have to map Hyper-V's
> GUID <VM_ID, Service_ID> to int <cid, port>, and hence we must limit
> the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> we can only use half of the whole 32-bit port space for listen().
> This is detailed in the long comments starting at about Line 100.
>
> > ...but hardcode this knowledge into the guest driver?
> I'd like the guest's connect() to fail immediately here.
> IMO this is better than a connect timeout. :-)
Thanks for explaining. Perhaps the comment could be updated:
/* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
* reserved as ephemeral ports, which are used as the host's ports when
* the host initiates connections.
*
* Perform this check in the guest so an immediate error is produced
* instead of a timeout.
*/
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Hajnoczi <stefanha@redhat.com> |
|---|---|
| Date | 2017-08-24 18:00 +0200 |
| Message-ID | <ui2I1-8tG-3@gated-at.bofh.it> |
| In reply to | #1717263 |
On Tue, Aug 22, 2017 at 09:40:01PM +0000, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > On Fri, Aug 18, 2017 at 10:23:54PM +0000, Dexuan Cui wrote:
> > > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > > +{
> > > > > + static const u32 valid_cids[] = {
> > > > > + VMADDR_CID_ANY,
> > > >
> > > > Is this for loopback?
> > >
> > > No, we don't support lookback in Linux VM, at least for now.
> > > In our Linux implementation, Linux VM can only connect to the host, and
> > > here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> > > the same as VMADDR_CID_HOST.
> >
> > VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> > connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
>
> Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since
> we don't support loopback mode.
>
> > > > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF)
> > > > is
> > > > > + * reserved as ephemeral ports, which are used as the host's ports
> > > > > + * when the host initiates connections.
> > > > > + */
> > > > > + if (port > MAX_HOST_LISTEN_PORT)
> > > > > + return false;
> > > >
> > > > Without this if statement the guest will attempt to connect. I guess
> > > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > > connection attempt will fail.
> > >
> > > You're correct.
> > > To use the vsock common infrastructure, we have to map Hyper-V's
> > > GUID <VM_ID, Service_ID> to int <cid, port>, and hence we must limit
> > > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > > we can only use half of the whole 32-bit port space for listen().
> > > This is detailed in the long comments starting at about Line 100.
> > >
> > > > ...but hardcode this knowledge into the guest driver?
> > > I'd like the guest's connect() to fail immediately here.
> > > IMO this is better than a connect timeout. :-)
> >
> > Thanks for explaining. Perhaps the comment could be updated:
> >
> > /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> > * reserved as ephemeral ports, which are used as the host's ports when
> > * the host initiates connections.
> > *
> > * Perform this check in the guest so an immediate error is produced
> > * instead of a timeout.
> > */
> >
> > Stefan
>
> Thank you, Stefan!
> Please see the below for the updated version of the function:
>
> static bool hvs_stream_allow(u32 cid, u32 port)
> {
> /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> * reserved as ephemeral ports, which are used as the host's ports
> * when the host initiates connections.
> *
> * Perform this check in the guest so an immediate error is produced
> * instead of a timeout.
> */
> if (port > MAX_HOST_LISTEN_PORT)
> return false;
>
> if (cid == VMADDR_CID_HOST)
> return true;
>
> return false;
> }
>
> I'll send a v2 of the patch later today.
Great, thanks!
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web