On Tue, Feb 11, 2020 at 10:36 PM Alex Williamson
wrote:
>
> On Tue, 11 Feb 2020 16:48:47 +0530
> Jerin Jacob wrote:
>
> > On Wed, Feb 5, 2020 at 4:35 AM Alex Williamson
> > wrote:
> > >
> > > There seems to be an ongoing desire to use userspace, vfio-based
> > > drivers for both SR-IOV PF and VF
On Tue, 11 Feb 2020 16:48:47 +0530
Jerin Jacob wrote:
> On Wed, Feb 5, 2020 at 4:35 AM Alex Williamson
> wrote:
> >
> > There seems to be an ongoing desire to use userspace, vfio-based
> > drivers for both SR-IOV PF and VF devices. The fundamental issue
> > with this concept is that the VF is n
11/02/2020 12:18, Jerin Jacob:
> On Wed, Feb 5, 2020 at 4:35 AM Alex Williamson wrote:
> >
> > There seems to be an ongoing desire to use userspace, vfio-based
> > drivers for both SR-IOV PF and VF devices. The fundamental issue
> > with this concept is that the VF is not fully independent of the
On Wed, Feb 5, 2020 at 4:35 AM Alex Williamson
wrote:
>
> There seems to be an ongoing desire to use userspace, vfio-based
> drivers for both SR-IOV PF and VF devices. The fundamental issue
> with this concept is that the VF is not fully independent of the PF
> driver. Minimally the PF driver mi
On Wed, 5 Feb 2020 07:57:36 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, February 5, 2020 7:18 AM
> > To: k...@vger.kernel.org
> > Subject: Re: [RFC PATCH 0/7] vfio/pci: SR-IOV support
> >
> >
> > Promised example QEMU test case...
> >
> > commit 3557c63bcb286c71f3f
On Wed, 5 Feb 2020 07:57:21 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> Silly questions on the background:
>
> > From: Alex Williamson
> > Sent: Wednesday, February 5, 2020 7:06 AM
> > Subject: [RFC PATCH 0/7] vfio/pci: SR-IOV support
> >
> > There seems to be an ongoing desire to use userspace,
On Tue, 4 Feb 2020 23:01:09 -0800
Christoph Hellwig wrote:
> On Tue, Feb 04, 2020 at 04:05:34PM -0700, Alex Williamson wrote:
> > We address this in a few ways in this series. First, we can use a bus
> > notifier and the driver_override facility to make sure VFs are bound
> > to the vfio-pci dri
> From: Alex Williamson
> Sent: Wednesday, February 5, 2020 7:18 AM
> To: k...@vger.kernel.org
> Subject: Re: [RFC PATCH 0/7] vfio/pci: SR-IOV support
>
>
> Promised example QEMU test case...
>
> commit 3557c63bcb286c71f3f7242cad632edd9e297d26
> Author: Alex Williamson
> Date: Tue Feb 4 13:4
Hi Alex,
Silly questions on the background:
> From: Alex Williamson
> Sent: Wednesday, February 5, 2020 7:06 AM
> Subject: [RFC PATCH 0/7] vfio/pci: SR-IOV support
>
> There seems to be an ongoing desire to use userspace, vfio-based
> drivers for both SR-IOV PF and VF devices.
Is this series
On Tue, Feb 04, 2020 at 04:05:34PM -0700, Alex Williamson wrote:
> We address this in a few ways in this series. First, we can use a bus
> notifier and the driver_override facility to make sure VFs are bound
> to the vfio-pci driver by default. This should eliminate the chance
> that a VF is acci
Promised example QEMU test case...
commit 3557c63bcb286c71f3f7242cad632edd9e297d26
Author: Alex Williamson
Date: Tue Feb 4 13:47:41 2020 -0700
vfio-pci: QEMU support for vfio-pci VF tokens
Example support for using a vf_token to gain access to a device as
well as using the V
There seems to be an ongoing desire to use userspace, vfio-based
drivers for both SR-IOV PF and VF devices. The fundamental issue
with this concept is that the VF is not fully independent of the PF
driver. Minimally the PF driver might be able to deny service to the
VF, VF data paths might be dep
12 matches
Mail list logo
