public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: ted.h.kim@oracle.com
Cc: stefanha@redhat.com, netdev@vger.kernel.org
Subject: Re: vsock CID questions
Date: Wed, 19 Feb 2020 11:44:34 +0100	[thread overview]
Message-ID: <20200219104434.xmpgd3os3qlgjnb5@steredhat> (raw)
In-Reply-To: <7f9dd3c9-9531-902c-3c8a-97119f559f65@oracle.com>

On Tue, Feb 18, 2020 at 02:45:38PM -0800, ted.h.kim@oracle.com wrote:
> Hi Stefano (and Stefan),

Hi Ted,

> 
> I have some questions about vsock CIDs, particularly when migration happens.
> 
> 1. Is there an API to lookup CIDs of guests from the host side (in libvirt)?

I don't know if there is a specific API, but looking at the xml, you can see
the assigned CID:

$ virsh dumpxml fedora31 | grep cid
      <cid auto='yes' address='3'/>

I'm not sure that's what you were asking, if you meant a list of all the
guest CIDs, I don't think there's an API for that.

> 
> 2. In the vsock(7) man page, it says the CID might change upon migration, if
> it is not available.
> Is there some notification when CID reassignment happens?

Connected stream sockets will receive an error after the migration and then
they'll be closed.

Usually it is not recommended to bind the guest's cid, it is preferable
to use VMADDR_CID_ANY.

> 
> 3. if CID reassignment happens, is this persistent? (i.e. will I see updated
> vsock definition in XML for the guest)

I guess so, but I didn't try.

> 
> 4. I would like to minimize the chance of CID collision. If I understand
> correctly, the CID is a 32-bit unsigned.

Right. 'struct sockaddr_vm' supports 32-bit unsigned CID.

>                                          So for my application, it might
> work to put an IPv4 address. But if I adopt this convention, then I need to
> look forward to possibly using IPv6. Anyway, would it be hard to potentially
> expand the size of the CID to 64 bits or even 128?

virtio-vsock specification [1] supports up to 64-bit CID.
The 'svm_cid' field in the 'struct sockaddr_vm' is the last one, before
the zero section, and we have 16-bit reserved on top that we can use for
some flags.
Maybe extending it to 64 bit might be feasible, but we need to check
other transports (vmci, hyperv).

Cheers,
Stefano

[1] https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-3960006


  reply	other threads:[~2020-02-19 10:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 22:45 vsock CID questions ted.h.kim
2020-02-19 10:44 ` Stefano Garzarella [this message]
2020-02-19 15:43 ` Stefan Hajnoczi
2020-02-20 16:09   ` Ján Tomko
2020-02-21 19:49     ` ted.h.kim
2020-02-25 11:30       ` Ján Tomko

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=20200219104434.xmpgd3os3qlgjnb5@steredhat \
    --to=sgarzare@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=stefanha@redhat.com \
    --cc=ted.h.kim@oracle.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