[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191009131643.GL5747@stefanha-x1.localdomain>
Date: Wed, 9 Oct 2019 14:16:43 +0100
From: Stefan Hajnoczi <stefanha@...il.com>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: netdev@...r.kernel.org, Sasha Levin <sashal@...nel.org>,
linux-hyperv@...r.kernel.org,
Stephen Hemminger <sthemmin@...rosoft.com>,
kvm@...r.kernel.org, "Michael S. Tsirkin" <mst@...hat.com>,
Dexuan Cui <decui@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
Stefan Hajnoczi <stefanha@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Jorgen Hansen <jhansen@...are.com>
Subject: Re: [RFC PATCH 11/13] vsock: add 'transport_hg' to handle g2h\h2g
transports
On Fri, Sep 27, 2019 at 01:27:01PM +0200, Stefano Garzarella wrote:
> VMCI transport provides both g2h and h2g behaviors in a single
> transport.
> We are able to set (or not) the g2h behavior, detecting if we
> are in a VMware guest (or not), but the h2g feature is always set.
> This prevents to load other h2g transports while we are in a
> VMware guest.
In the vhost_vsock.ko case we only register the h2g transport when
userspace has loaded the module (by opening /dev/vhost-vsock).
VMCI has something kind of similar: /dev/vmci and the
vmci_host_active_users counter. Maybe we can use this instead of
introducing the transport_hg concept?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists