Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 10 Nov 2021 09:34:32 +0000
From:   Stefan Hajnoczi <stefanha@redhat.com>
To:     "Wang, Wei W" <wei.w.wang@intel.com>
Cc:     "sgarzare@redhat.com" <sgarzare@redhat.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "mst@redhat.com" <mst@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "kys@microsoft.com" <kys@microsoft.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "virtualization@lists.linux-foundation.org" 
        <virtualization@lists.linux-foundation.org>,
        "Yamahata, Isaku" <isaku.yamahata@intel.com>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        "Kleen, Andi" <andi.kleen@intel.com>,
        Andra Paraschiv <andraprs@amazon.com>
Subject: Re: [RFC] hypercall-vsock: add a new vsock transport
Message-ID: <YYuSKEqj3UMLNAfw@stefanha-x1.localdomain>
References: <71d7b0463629471e9d4887d7fcef1d8d@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="6kCy5STPFCJ1ef5p"
Content-Disposition: inline
In-Reply-To: <71d7b0463629471e9d4887d7fcef1d8d@intel.com>
Precedence: bulk


--6kCy5STPFCJ1ef5p
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 10, 2021 at 07:12:36AM +0000, Wang, Wei W wrote:
> We plan to add a new vsock transport based on hypercall (e.g. vmcall on I=
ntel CPUs).
> It transports AF_VSOCK packets between the guest and host, which is simil=
ar to
> virtio-vsock, vmci-vsock and hyperv-vsock.
>=20
> Compared to the above listed vsock transports which are designed for high=
 performance,
> the main advantages of hypercall-vsock are:
>=20
> 1)       It is VMM agnostic. For example, one guest working on hypercall-=
vsock can run on
>=20
> either KVM, Hyperv, or VMware.
>=20
> 2)       It is simpler. It doesn't rely on any complex bus enumeration
>=20
> (e.g. virtio-pci based vsock device may need the whole implementation of =
PCI).
>=20
> An example usage is the communication between MigTD and host (Page 8 at
> https://static.sched.com/hosted_files/kvmforum2021/ef/TDX%20Live%20Migrat=
ion_Wei%20Wang.pdf).
> MigTD communicates to host to assist the migration of the target (user) T=
D.
> MigTD is part of the TCB, so its implementation is expected to be as simp=
le as possible
> (e.g. bare mental implementation without OS, no PCI driver support).

AF_VSOCK is designed to allow multiple transports, so why not. There is
a cost to developing and maintaining a vsock transport though.

I think Amazon Nitro enclaves use virtio-vsock and I've CCed Andra in
case she has thoughts on the pros/cons and how to minimize the trusted
computing base.

If simplicity is the top priority then VIRTIO's MMIO transport without
indirect descriptors and using the packed virtqueue layout reduces the
size of the implementation:
https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x=
1-1440002

Stefan

--6kCy5STPFCJ1ef5p
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmGLkigACgkQnKSrs4Gr
c8iPyAf8COmUtjvTHk5gX6zSZeAiKXrfyy3bnkP9NrNwxXTHGg7f6dECVUz9Gg73
+YqbL+Li11VWyTGCltsAWVkcVmmeuW+vdAUhuxBRRoWw8VCoLKbMUif/rJV48Ms8
KQN5ZEoGSMVFpNj6P7V6qlPMC8MRGLfeqouNZpbL5z/gTfef+vQvKGjR7NF3CegG
CtVR2NXN+sE+bOPHB9VY11YzBlSLNcuivqb4k288LkTqemVcMQloN2w6bYkzaUP5
IwdGx3PP13yFkDDKYv4PnJ3VJPDYVrL0Y1mxNAlFhtQ2bBnk8l3DapR/Z906kVYb
bG7G+2Sb/uf0m34bQgrAokLNk8nWGA==
=bN/Z
-----END PGP SIGNATURE-----

--6kCy5STPFCJ1ef5p--