On Wed, Jul 01, 2020 at 11:23:25PM -0700, John G Johnson wrote:
>
> 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/mast
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
On Thu, Jun 25, 2020 at 08:54:25PM -0700, John G Johnson wrote:
>
>
> > 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 pass
> 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
>>> once the file descriptor has been
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
> > once the file descriptor has been passed. memfd supports sealing with
> > fnctl(F_ADD_SEALS) it d
> 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
On Tue, Jun 09, 2020 at 11:25:41PM -0700, John G Johnson wrote:
> > 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 see
> 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 server with access to the
>>> entire GPA space, wh
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 server with access to the
> > entire GPA space, while the latter indicates an IOVA to GPA mapping of
> > those regions.
> 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
On Thu, 14 May 2020 09:32:15 -0700
John G Johnson wrote:
> 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
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
On Mon, May 04, 2020 at 10:49:11AM -0700, John G Johnson wrote:
>
>
> > 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,
> >>>
> O
> 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
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 importantly, considering:
> > a) Marc-André's comments abou
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 importantly, considering:
> a) Marc-André's comments about data alignment etc., and
> b) the possibility to run the server on another gu
Hi,
> On Apr 30, 2020, at 4:20 PM, Thanos Makatos
> wrote:
>
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 supp
> > > 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 for
On Thu, Apr 30, 2020 at 11:23:34AM +, Thanos Makatos wrote:
> > > > 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/ed
> > > 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 t
On Mon, Apr 20, 2020 at 11:05:25AM +, Thanos Makatos wrote:
> > 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 soc
> 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, Apr 02, 2020 at 11:46:45AM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 02, 2020 at 11:19:42AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Apr 01, 2020 at 06:58:20PM +0200, Marc-André Lureau wrote:
> > > On Wed, Apr 1, 2020 at 5:51 PM Thanos Makatos
> > > wrote:
> > > > > > Bear in mind th
On Thu, Apr 02, 2020 at 11:19:42AM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 01, 2020 at 06:58:20PM +0200, Marc-André Lureau wrote:
> > On Wed, Apr 1, 2020 at 5:51 PM Thanos Makatos
> > wrote:
> > > > > Bear in mind that since this is just a PoC lots of things can break,
> > > > > e.g. some
> >
On Wed, Apr 01, 2020 at 06:58:20PM +0200, Marc-André Lureau wrote:
> On Wed, Apr 1, 2020 at 5:51 PM Thanos Makatos
> wrote:
> > > On Thu, Mar 26, 2020 at 09:47:38AM +, Thanos Makatos wrote:
> > > > Build MUSER with vfio-over-socket:
> > > >
> > > > git clone --single-branch --branch vf
Hi
On Wed, Apr 1, 2020 at 5:51 PM Thanos Makatos
wrote:
>
> > On Thu, Mar 26, 2020 at 09:47:38AM +, Thanos Makatos wrote:
> > > Build MUSER with vfio-over-socket:
> > >
> > > git clone --single-branch --branch vfio-over-socket
> > g...@github.com:tmakatos/muser.git
> > > cd mu
> On Thu, Mar 26, 2020 at 09:47:38AM +, 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 submodule update --init
> > make
> >
> > Ru
On Thu, Mar 26, 2020 at 09:47:38AM +, 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 submodule update --init
> make
>
> Run device emulat
>
> 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 di
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 m
31 matches
Mail list logo
