Re: [PATCH v5] introduce vfio-user protocol specification

2020-11-05 Thread John G Johnson
> On Nov 2, 2020, at 3:51 AM, Thanos Makatos wrote: > > > >> -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 >>

Re: [PATCH v4] introduce vfio-user protocol specification

2020-09-29 Thread John G Johnson
> On Sep 29, 2020, at 3:37 AM, Stefan Hajnoczi wrote: > > On Mon, Sep 28, 2020 at 09:58:37AM +, Thanos Makatos wrote: >>> It should be accompanied by a test in tests/. PCI-level testing APIS for >>> BARs, configuration space, interrupts, etc are available in >>> tests/qtest/libqos/pci.h. T

Re: [PATCH] introduce VFIO-over-socket protocol specificaion

2020-08-07 Thread John G Johnson
Updated doc to address comments. Many changes are typos, but some are more more substantive. JJ Version title is a hyperlink the versioning section Rewrote concurrency section to be less concurrent Removed disconnection re

Re: [PATCH] introduce VFIO-over-socket protocol specificaion

2020-07-30 Thread John G Johnson
use VFIO over a 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, 1

Re: [PATCH] introduce VFIO-over-socket protocol specificaion

2020-07-29 Thread John G Johnson
Thanos is on vacation. My comments embedded. JJ > On Jul 29, 2020, at 5:48 AM, Stefan Hajnoczi wrote: > > On Wed, Jul 22, 2020 at 11:42:26AM +, Thanos Makatos wrote: diff --git a/docs/devel/vfio-over-socket.rst b/docs/devel/vfio-over

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-07-01 Thread John G Johnson
We’ve made the review changes to the doc, and moved to RST format, so the doc can go into the QEMU sources. Thanos & JJ https://github.com/tmakatos/qemu/blob/master/docs/devel/vfio-over-socket.rst

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-06-25 Thread John G Johnson
> On Jun 23, 2020, at 5:27 AM, Stefan Hajnoczi wrote: > > On Thu, Jun 18, 2020 at 02:38:04PM -0700, John G Johnson wrote: >>> On Jun 15, 2020, at 3:49 AM, Stefan Hajnoczi wrote: >>> An issue with file descriptor passing is that it's hard to revoke access >&

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-06-18 Thread John G Johnson
> On Jun 15, 2020, at 3:49 AM, Stefan Hajnoczi wrote: > > > It's challenging to implement a fast and secure IOMMU. The simplest > approach is secure but not fast: add protocol messages for > DMA_READ(iova, length) and DMA_WRITE(iova, buffer, length). > We do have protocol messages f

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-06-09 Thread John G Johnson
> On Jun 2, 2020, at 8:06 AM, Alex Williamson > wrote: > > On Wed, 20 May 2020 17:45:13 -0700 > John G Johnson wrote: > >>> I'm confused by VFIO_USER_ADD_MEMORY_REGION vs VFIO_USER_IOMMU_MAP_DMA. >>> The former seems intended to provide the serve

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-05-20 Thread John G Johnson
> I'm confused by VFIO_USER_ADD_MEMORY_REGION vs VFIO_USER_IOMMU_MAP_DMA. > The former seems intended to provide the server with access to the > entire GPA space, while the latter indicates an IOVA to GPA mapping of > those regions. Doesn't this break the basic isolation of a vIOMMU? > This ess

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-05-14 Thread John G Johnson
Thanos and I have made some changes to the doc in response to the feedback we’ve received. The biggest difference is that it is less reliant on the reader being familiar with the current VFIO implementation. We’d appreciate any additional feedback you could give on the changes. Thanks

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

2020-05-04 Thread John G Johnson
> On May 4, 2020, at 2:45 AM, Stefan Hajnoczi wrote: > > On Fri, May 01, 2020 at 04:28:25PM +0100, Daniel P. Berrangé wrote: >> On Fri, May 01, 2020 at 03:01:01PM +, Felipe Franciosi wrote: >>> Hi, >>> On Apr 30, 2020, at 4:20 PM, Thanos Makatos wrote: >>> More impor

Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update

2020-01-13 Thread John G Johnson
> On Jan 3, 2020, at 7:59 AM, Stefan Hajnoczi wrote: > > On Thu, Jan 02, 2020 at 11:03:22AM +, Felipe Franciosi wrote: >>> On Jan 2, 2020, at 10:42 AM, Stefan Hajnoczi wrote: >>> On Fri, Dec 20, 2019 at 10:22:37AM +, Daniel P. Berrangé wrote: On Fri, Dec 20, 2019 at 09:47:12AM +0

Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update

2019-12-20 Thread John G Johnson
> On Dec 19, 2019, at 5:36 AM, Stefan Hajnoczi wrote: > > On Wed, Dec 18, 2019 at 01:00:55AM +0100, Paolo Bonzini wrote: >> On 17/12/19 23:57, Felipe Franciosi wrote: >>> Doing it in userspace was the flow we proposed back in last year's KVM >>> Forum (Edinburgh), but it got turned down. >> >

Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

2019-03-21 Thread John G Johnson
> On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote: > >> On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi wrote: >>> >>> On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote: I guess one obvious answer is that the existing security mechanisms like SELin

Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

2019-03-07 Thread John G Johnson
> On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi wrote: > > On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote: >> On Thu, Mar 07, 2019 at 02:26:09PM +, Stefan Hajnoczi wrote: >>> On Wed, Mar 06, 2019 at 11:22:53PM -0800, elena.ufimts...@oracle.com wrote: diff --git a/do