qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Thanos Makatos <thanos.makatos@nutanix.com>
Cc: "Walker, Benjamin" <benjamin.walker@intel.com>,
	"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	john.g.johnson@oracle.com, "Jag Raman" <jag.raman@oracle.com>,
	"Harris, James R" <james.r.harris@intel.com>,
	"Swapnil Ingle" <swapnil.ingle@nutanix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Kirti Wankhede" <kwankhede@nvidia.com>,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Kanth Ghatraju" <Kanth.Ghatraju@oracle.com>,
	"Felipe Franciosi" <felipe@nutanix.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Zhang, Tina" <tina.zhang@intel.com>,
	"Liu, Changpeng" <changpeng.liu@intel.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: RFC: use VFIO over a UNIX domain socket to implement device offloading
Date: Wed, 1 Apr 2020 10:17:12 +0100	[thread overview]
Message-ID: <20200401091712.GA221892@stefanha-x1.localdomain> (raw)
In-Reply-To: <MN2PR02MB62052E54C752229C115EAD898BCF0@MN2PR02MB6205.namprd02.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

On Thu, Mar 26, 2020 at 09:47:38AM +0000, Thanos Makatos wrote:
> Build MUSER with vfio-over-socket:
> 
>         git clone --single-branch --branch vfio-over-socket git@github.com:tmakatos/muser.git
>         cd muser/
>         git submodule update --init
>         make
> 
> Run device emulation, e.g.
> 
>         ./build/dbg/samples/gpio-pci-idio-16 -s <N>
> 
> Where <N> is an available IOMMU group, essentially the device ID, which must not
> previously exist in /dev/vfio/.
> 
> Run QEMU using the vfio wrapper library and specifying the MUSER device:
> 
>         LD_PRELOAD=muser/build/dbg/libvfio/libvfio.so qemu-system-x86_64 \
>                 ... \
>                 -device vfio-pci,sysfsdev=/dev/vfio/<N> \
>                 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=mem,share=yes,size=1073741824 \
>                 -numa node,nodeid=0,cpus=0,memdev=ram-node0
> 
> Bear in mind that since this is just a PoC lots of things can break, e.g. some
> system call not intercepted etc.

Cool, I had a quick look at libvfio and how the transport integrates
into libmuser.  The integration on the libmuser side is nice and small.

It seems likely that there will be several different implementations of
the vfio-over-socket device side (server):
1. libmuser
2. A Rust equivalent to libmuser
3. Maybe a native QEMU implementation for multi-process QEMU (I think JJ
   has been investigating this?)

In order to interoperate we'll need to maintain a protocol
specification.  Mayb You and JJ could put that together and CC the vfio,
rust-vmm, and QEMU communities for discussion?

It should cover the UNIX domain socket connection semantics (does a
listen socket only accept 1 connection at a time?  What happens when the
client disconnects?  What happens when the server disconnects?), how
VFIO structs are exchanged, any vfio-over-socket specific protocol
messages, etc.  Basically everything needed to write an implementation
(although it's not necessary to copy the VFIO struct definitions from
the kernel headers into the spec or even document their semantics if
they are identical to kernel VFIO).

The next step beyond the LD_PRELOAD library is a native vfio-over-socket
client implementation in QEMU.  There is a prototype here:
https://github.com/elmarco/qemu/blob/wip/vfio-user/hw/vfio/libvfio-user.c

If there are any volunteers for working on that then this would be a
good time to discuss it.

Finally, has anyone looked at CrosVM's out-of-process device model?  I
wonder if it has any features we should consider...

Looks like a great start to vfio-over-socket!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-04-01  9:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26  9:47 RFC: use VFIO over a UNIX domain socket to implement device offloading Thanos Makatos
2020-03-27 10:37 ` Thanos Makatos
2020-04-01  9:17 ` Stefan Hajnoczi [this message]
2020-04-01 15:49   ` Thanos Makatos
2020-04-01 16:58     ` Marc-André Lureau
2020-04-02 10:19       ` Stefan Hajnoczi
2020-04-02 10:46         ` Daniel P. Berrangé
2020-04-03 12:03           ` Stefan Hajnoczi
2020-04-20 11:05   ` Thanos Makatos
2020-04-22 15:29     ` Stefan Hajnoczi
2020-04-27 10:58       ` Thanos Makatos
2020-04-30 11:23         ` Thanos Makatos
2020-04-30 11:40           ` Daniel P. Berrangé
2020-04-30 15:20             ` Thanos Makatos
2020-05-01 15:01               ` Felipe Franciosi
2020-05-01 15:28                 ` Daniel P. Berrangé
2020-05-04  9:45                   ` Stefan Hajnoczi
2020-05-04 17:49                     ` John G Johnson
2020-05-11 14:37                       ` Stefan Hajnoczi
2020-05-14 16:32     ` John G Johnson
2020-05-14 19:20       ` Alex Williamson
2020-05-21  0:45       ` John G Johnson
2020-06-02 15:06         ` Alex Williamson
2020-06-10  6:25           ` John G Johnson
2020-06-15 10:49             ` Stefan Hajnoczi
2020-06-18 21:38               ` John G Johnson
2020-06-23 12:27                 ` Stefan Hajnoczi
2020-06-26  3:54                   ` John G Johnson
2020-06-26 13:30                     ` Stefan Hajnoczi
2020-07-02  6:23                       ` John G Johnson
2020-07-15 10:15                         ` Stefan Hajnoczi

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=20200401091712.GA221892@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=Kanth.Ghatraju@oracle.com \
    --cc=alex.williamson@redhat.com \
    --cc=benjamin.walker@intel.com \
    --cc=changpeng.liu@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=felipe@nutanix.com \
    --cc=jag.raman@oracle.com \
    --cc=james.r.harris@intel.com \
    --cc=john.g.johnson@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kwankhede@nvidia.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=swapnil.ingle@nutanix.com \
    --cc=thanos.makatos@nutanix.com \
    --cc=tina.zhang@intel.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;
as well as URLs for NNTP newsgroup(s).