er...@vger.kernel.org; linux-
> p...@vger.kernel.org; lpieral...@kernel.org; manivannan.sadhasi...@linaro.org;
> Marcel Apfelbaum ; Michael S. Tsirkin
> ; Paolo Bonzini ; qemu-
> de...@nongnu.org; r...@kernel.org; Thanos Makatos
> ; vaishna...@ti.com; William Henderson
>
> Subjec
bkost.net; Marcel Apfelbaum ;
> Eric Blake ; Markus Armbruster ;
> Juan Quintela ; dgilb...@redhat.com; John Levon
> ; Thanos Makatos ;
> Elena Ufimtseva ; John Johnson
> ; Kanth Ghatraju
> Subject: Re: [PATCH v6 15/19] vfio-user: handle device interrupts
>
>
>
>
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Alex
> Williamson
> Sent: 09 March 2022 22:35
> To: John Johnson
> Cc: qemu-devel@nongnu.org
> Subject: Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol
> specification
>
>
> -Original Message-
> From: John Johnson
> Sent: 16 February 2022 02:10
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org
> Subject: Re: [RFC v4 08/21] vfio-user: define socket receive functions
>
>
>
> > On Feb 15, 2022, at
> -Original Message-
> From: John Johnson
> Sent: 14 February 2022 18:50
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org
> Subject: Re: [RFC v4 20/21] vfio-user: migration support
>
>
>
> > On Feb 11, 2022, at 5:31 AM, Thanos Makatos
> wrote
> > +/*
> > + * Receive and process one incoming message.
> > + *
> > + * For replies, find matching outgoing request and wake any waiters.
> > + * For requests, queue in incoming list and run request BH.
> > + */
> > +static int vfio_user_recv_one(VFIOProxy *proxy)
> > +{
> > +VFIOUserMsg
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 08/21] vfio-user: define socket receive functions
>
> Add infrastructure needed to receive
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 01/21] vfio-user: introduce vfio-user protocol specification
>
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 20/21] vfio-user: migration support
>
> Signed-off-by: John G Johnson
> Signed-off-by: Elena
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Thanos
> Makatos
> Sent: 03 February 2022 21:54
> To: John Johnson ; qemu-devel@nongnu.org
> Subject: RE: [RFC v4 08/21] vfio-user: define soc
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 08/21] vfio-user: define socket receive functions
>
> Add infrastructure needed to receive
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 28 January 2022 08:29
> To: Jag Raman
> Cc: John Levon ; Thanos Makatos
> ; qemu-devel ;
> Marc-André Lureau ; Philippe Mathieu-Daudé
> ; Paolo Bonzini ; Beraldo Leal
> ; Daniel P. Berrangé ;
> edua...@h
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 12/21] vfio-user: region read/write
>
> Add support for posted writes on remote devices
>
>
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Johnson
> Sent: 12 January 2022 00:44
> To: qemu-devel@nongnu.org
> Subject: [RFC v4 09/21] vfio-user: define socket send functions
>
> Also negotiate protocol version with remote
> -Original Message-
> From: Jag Raman
> Sent: 17 December 2021 18:00
> To: Stefan Hajnoczi ; John Levon
> ; Thanos Makatos
> Cc: qemu-devel ; Alex Williamson
> ; Marc-André Lureau
> ; Philippe Mathieu-Daudé
> ; pbonz...@redhat.com; alex.ben...@linaro.
> On Mon, Jul 12, 2021 at 01:24:07PM +0000, Thanos Makatos wrote:
> > We're working on implementing a virtual NVMe controller based on SPDK
> and a multiprocess-qemu branch that uses the vfio-user. We're facing a
> problem where the existing API doesn't allow us to tell QEMU fr
> -Original Message-
> From: Jagannathan Raman
> Sent: 19 July 2021 21:00
> To: qemu-devel@nongnu.org
> Cc: stefa...@redhat.com; alex.william...@redhat.com;
> elena.ufimts...@oracle.com; John Levon ;
> john.g.john...@oracle.com; Thanos Makatos
> ; Swapnil Ingle
> -Original Message-
> From: Jagannathan Raman
> Sent: 19 July 2021 21:00
> To: qemu-devel@nongnu.org
> Cc: stefa...@redhat.com; alex.william...@redhat.com;
> elena.ufimts...@oracle.com; John Levon ;
> john.g.john...@oracle.com; Thanos Makatos
> ; Swapnil Ingle
> -Original Message-
> From: Jagannathan Raman
> Sent: 19 July 2021 21:00
> To: qemu-devel@nongnu.org
> Cc: stefa...@redhat.com; alex.william...@redhat.com;
> elena.ufimts...@oracle.com; John Levon ;
> john.g.john...@oracle.com; Thanos Makatos
> ; Swapnil Ingle
> -Original Message-
> From: Jagannathan Raman
> Sent: 19 July 2021 21:00
> To: qemu-devel@nongnu.org
> Cc: stefa...@redhat.com; alex.william...@redhat.com;
> elena.ufimts...@oracle.com; John Levon ;
> john.g.john...@oracle.com; Thanos Makatos
> ; Swapnil Ingle
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Thanos
> Makatos
> Sent: 19 July 2021 19:02
> To: Peter Xu
> Cc: Paolo Bonzini ; John Levon
> ; John G Johnson ;
> Markus Armbruster ; QEMU Devel Mailing List
Omg I don't know how I missed that, of course I'll ignore SIGUSR1 and retest!
From: Peter Xu
Sent: Monday, 19 July 2021, 16:58
To: Thanos Makatos
Cc: Paolo Bonzini; Markus Armbruster; QEMU Devel Mailing List; John Levon; John
G Johnson
Subject: Re: Question
> -Original Message-
> From: Peter Xu
> Sent: 16 July 2021 15:19
> To: Thanos Makatos
> Cc: Paolo Bonzini ; Markus Armbruster
> ; QEMU Devel Mailing List de...@nongnu.org>; John Levon ; John G
> Johnson
> Subject: Re: Question on memory commit during MR fin
> -Original Message-
> From: Peter Xu
> Sent: 15 July 2021 19:35
> To: Thanos Makatos
> Cc: Paolo Bonzini ; Markus Armbruster
> ; QEMU Devel Mailing List de...@nongnu.org>; John Levon ; John G
> Johnson
> Subject: Re: Question on memory commit during MR fin
Hi Peter,
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Peter
> Xu
> Sent: 21 April 2020 11:44
> To: Paolo Bonzini
> Cc: Markus Armbruster ; QEMU Devel Mailing List
>
> Subject: Re: Question on memory commit during MR finalize()
>
We're working on implementing a virtual NVMe controller based on SPDK and a
multiprocess-qemu branch that uses the vfio-user. We're facing a problem where
the existing API doesn't allow us to tell QEMU from which NVMe namespace we'd
like SeaBIOS to boot from.
How can we solve this problem? Can
in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
Signed-off-by: John Levon
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to To
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 04 May 2021 14:52
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; John Levon ;
> John G Johnson ;
> benjamin.wal...@intel.com; Elena Ufimtseva
> ; jag.ra...@oracle.com;
> james.r.har...@intel.com;
> > Are there rules for avoiding deadlock between client->server and
> > server->client messages? For example, the client sends
> > VFIO_USER_REGION_WRITE and the server sends
> VFIO_USER_VM_INTERRUPT
> > before replying to the write message.
> >
> > Multi-threaded clients and servers could end up
> > > +VFIO_USER_DMA_UNMAP
> > > +---
> > > +
> > > +This command message is sent by the client to the server to inform
> > > +it that a DMA region, previously made available via a
> > > +VFIO_USER_DMA_MAP command message, is no longer available for
> DMA.
> > > +It typically
> -Original Message-
> From: Alex Williamson
> Sent: 07 May 2021 16:42
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; Raphael Norwitz
>
> Subject: Re: question regarding QEMU adding overlapping memory regions
> to VFIO
>
> On Fri, 7 May 2021 13:51:52
> -Original Message-
> From: John Levon
> Sent: 05 May 2021 17:20
> To: Stefan Hajnoczi
> Cc: Thanos Makatos ; qemu-
> de...@nongnu.org; John Levon ; John G
> Johnson ; benjamin.wal...@intel.com; Elena
> Ufimtseva ; jag.ra...@oracle.com;
> james.r.har.
I've noticed that QEMU adds overlapping memory regions to VFIO, e.g.:
vfio_listener_region_add_ram region_add [ram] 0xc - 0xc0fff [0x7f6702c0]
vfio_listener_region_del region_del 0xc4000 - 0xd
vfio_listener_region_add_ram region_add [ram] 0xc1000 - 0xc3fff [0x7f66406c1000]
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 26 April 2021 16:48
> To: Thanos Makatos ; Peter Maydell
> ; Michael S. Tsirkin
> Cc: qemu-devel@nongnu.org; John Levon ;
> John G Johnson ;
> benjamin.wal...@intel.com; Elena Ufimtseva
> ; jag.ra..
in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
Signed-off-by: John Levon
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to To
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Gerd
> Hoffmann
> Sent: 17 March 2021 10:17
> To: Dr. David Alan Gilbert
> Cc: victort...@redhat.com; berra...@redhat.com; qemu-
> de...@nongnu.org
> Subject: Re: Half a usb-redir idea
> > I understand that this framework is targetting KVM and mostly PCI
> > devices but I was wondering if it could be of any use for full system
> > emulation. Would it possible to use this framework to interconnect
> > QEMU processes emulating different machines but sharing a common bus
> ?
Not
in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Changed since v2:
* fix
> +Version Data Format
> +^^^
> +
> +The version data is an optional JSON byte array with the following format:
> +
> ++--+--+---+
> +| Name | Type | Description
>
> VFIO Migration
> ==
> This document describes how to ensure migration compatibility for VFIO
> devices,
> including mdev and vfio-user devices.
Is this something all VFIO/user devices will have to support? If it's not
mandatory, how can a device advertise support?
> Multiple
in:
"RFC: use VFIO over a UNIX domain socket to implement device
oading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Changed since v2:
* fix
> -Original Message-
> From: John Levon
> Sent: 07 November 2020 12:26
> To: John G Johnson
> Cc: Thanos Makatos ;
> benjamin.wal...@intel.com; Elena Ufimtseva
> ; tomassetti.and...@gmail.com;
> jag.ra...@oracle.com; james.r.har...@intel.com; Swapnil Ingle
&g
> > > * *Error* in a reply message indicates the command being
> acknowledged
> > had
> > > an error. In this case, the *Error* field will be valid.
> > >
> > > * *Error* in a reply message is a UNIX errno value. It is reserved in a
> > command message.
> >
> > I'm not quite following why we
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of John
> Levon
> Sent: 02 November 2020 11:41
> To: Thanos Makatos
> Cc: benjamin.wal...@intel.com; Elena Ufimtseva
> ; jag.ra...@oracle.com;
> james.r.har.
> -Original Message-
> From: John Levon
> Sent: 30 October 2020 17:03
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; benjamin.wal...@intel.com; Elena Ufimtseva
> ; tomassetti.and...@gmail.com;
> john.g.john...@oracle.com; jag.ra...@oracle.com; Swapnil
FYI here's v5 of the vfio-user protocol, my --cc in git send-email got messed
up somehow
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Thanos
> Makatos
> Sent: 28 October 2020 16:10
> To: qemu-devel@nongnu.org
&g
in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Changed since v2:
* fix
> -Original Message-
> From: Qemu-devel bounces+thanos.makatos=nutanix@nongnu.org> On Behalf Of Thanos
> Makatos
> Sent: 28 October 2020 09:32
> To: Stefan Hajnoczi ; qemu-devel@nongnu.org
> Cc: Elena Ufimtseva ;
> john.g.john...@oracle.com; m...@redhat.com
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 27 October 2020 15:14
> To: qemu-devel@nongnu.org
> Cc: Alex Bennée ; m...@redhat.com
> ; john.g.john...@oracle.com; Elena Ufimtseva
> ; kra...@redhat.com;
> jag.ra...@oracle.com; Thanos Makatos ;
> Felipe Fr
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 24 September 2020 09:22
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; Michael S. Tsirkin ;
> alex.william...@redhat.com; benjamin.wal...@intel.com;
> elena.ufimts...@oracle.com; jag.ra...@orac
in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Changed since v2:
* fix
> -Original Message-
> From: Nikos Dragazis
> Sent: 21 July 2020 17:34
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; benjamin.wal...@intel.com;
> elena.ufimts...@oracle.com; tomassetti.and...@gmail.com; John G
> Johnson ; jag.ra...@oracle.com; Swapnil
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 17 July 2020 13:18
> To: Thanos Makatos
> Cc: qemu-devel@nongnu.org; alex.william...@redhat.com;
> benjamin.wal...@intel.com; elena.ufimts...@oracle.com;
> jag.ra...@oracle.com; Swapnil Ingle ;
> james.r.ha
UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Changed since v2:
* fix whitespace
Regarding
UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
Changed since v1:
* fix coding style issues
* update MAINTAINERS for VFIO-over-socket
* add vfio-over-socket to ToC
Regarding the build failure, I have not
UNIX domain socket to implement device offloading"
Signed-off-by: John G Johnson
Signed-off-by: Thanos Makatos
---
docs/devel/vfio-over-socket.rst | 1135 +++
1 files changed, 1135 insertions(+), 0 deletions(-)
create mode 100644 docs/devel/vfio-over-
> -Original Message-
> From: kvm-ow...@vger.kernel.org On
> Behalf Of Stefan Hajnoczi
> Sent: 15 July 2020 12:24
> To: Nikos Dragazis ; Jan Kiszka
>
> Cc: Michael S. Tsirkin ; Thanos Makatos
> ; John G. Johnson
> ; Andra-Irina Paraschiv
> ; Alexander Graf
We have an issue when using the VFIO-over-socket libmuser PoC
(https://www.mail-archive.com/qemu-devel@nongnu.org/msg692251.html) instead of
the VFIO kernel module: we notice that DMA regions used by the emulated device
can be abruptly removed while the device is still using them.
The PCI device
> > > More importantly, considering:
> > > a) Marc-André's comments about data alignment etc., and
> > > b) the possibility to run the server on another guest or host,
> > > we won't be able to use native VFIO types. If we do want to support that
> > > then
> > > we'll have to redefine all data
> > > I've just shared with you the Google doc we've working on with John
> > where we've
> > > been drafting the protocol specification, we think it's time for some
> > > first
> > > comments. Please feel free to comment/edit and suggest more people
> to
> > be on the
> > > reviewers list.
> > >
> > I've just shared with you the Google doc we've working on with John
> where we've
> > been drafting the protocol specification, we think it's time for some first
> > comments. Please feel free to comment/edit and suggest more people to
> be on the
> > reviewers list.
> >
> > You can also find
> 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
> 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
> g...@github.com:tmakatos/muser.git
> > cd muser/
> > git subm
>
> Next I explain how to test the PoC.
>
> Build MUSER with vfio-over-socket:
>
> git clone --single-branch --branch vfio-over-socket
> g...@github.com:tmakatos/muser.git
> cd muser/
> git submodule update --init
> make
Yesterday's version had a bug where it
I want to continue the discussion regarding using MUSER
(https://github.com/nutanix/muser) as a device offloading mechanism. The main
drawback of MUSER is that it requires a kernel module, so I've experimented
with a proof of concept of how MUSER would look like if we somehow didn't need
a kernel
> > 3) Muser.ko pins the pages (in get_dma_map(), called from below)
> > (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_nutanix_muser_blob_master_kmod_muser.c-
> 23L711=DwICAg=s883GpUCOChKOHiocYtGcg=XTpYsh5Ps2zJvtw6ogtt
>
> > I'm passing through a virtual PCI device to a QEMU guest via VFIO/mdev
> and I
> > notice that MSI-X interrupts are disabled in the device (MSIXCAP.MXC.MXE
> is
> > zero) and the BARs containing the table and PBA (4 and 5 in my case) are
> never
> > accessed. However, whenever I fire an MSI-X
I'm passing through a virtual PCI device to a QEMU guest via VFIO/mdev and I
notice that MSI-X interrupts are disabled in the device (MSIXCAP.MXC.MXE is
zero) and the BARs containing the table and PBA (4 and 5 in my case) are never
accessed. However, whenever I fire an MSI-X interrupt from the
I have a Ubuntu VM (4.15.0-48-generic) to which I pass through a PCI device,
specifically a virtual NVMe controller. The problem I have is that only one I/O
queue
is initialized, while there should be more (e.g. four). I'm using upstream QEMU
v4.1.0 confgiured without any additional options. Most
> > > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > > index 4374cc6176..d9d3b1277a 100644
> > > --- a/hw/vfio/common.c
> > > +++ b/hw/vfio/common.c
> > > @@ -430,6 +430,9 @@ static void
> > vfio_listener_region_add(MemoryListener *listener,
> > > VFIOHostDMAWindow *hostwin;
> > >
> > Indeed. Could we decide whether or not to register an address space with
> > VFIO in a more intelligent manner? E.g. the following simplistic patch
> > solves
> > our problem:
> >
> > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > index 4374cc6176..d9d3b1277a 100644
> > ---
> > When configuring device pass-through via VFIO to a VM, I noticed that
> > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > only RAM). That includes firmware regions like "pc.rom".
Would a
> > physical device ever need access to those?
>
> Probably not,
When configuring device pass-through via VFIO to a VM, I noticed that QEMU
tries to register (DMA_MAP) all memory regions of a guest (not only RAM). That
includes firmware regions like "pc.rom". Would a physical device ever need
access to those? Am I missing something?
]
Sent: 14 November 2012 16:36
To: Thanos Makatos
Cc: Stefano Stabellini; Charles Arnold; qemu-devel@nongnu.org; Kevin
Wolf; stefa...@redhat.com; xen-de...@lists.xensource.com
Subject: Re: [PATCH] block: vpc support for ~2 TB disks
Il 14/11/2012 17:25, Thanos Makatos ha scritto:
We don't
...@eu.citrix.com]
Sent: 13 November 2012 10:56
To: Paolo Bonzini
Cc: Charles Arnold; qemu-devel@nongnu.org; Kevin Wolf;
stefa...@redhat.com; Stefano Stabellini; xen-de...@lists.xensource.com;
Thanos Makatos
Subject: Re: [PATCH] block: vpc support for ~2 TB disks
On Tue, 13 Nov 2012, Paolo Bonzini wrote
75 matches
Mail list logo
