On Thu, 11 Feb 2021 08:44:26 +
Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 04:59:23PM -0700, Alex Williamson wrote:
> > vfio-pci-igd support knows very little about the device, we're
> > effectively just exposing a firmware table and some of the host bridge
> > config space (read-only)
On Thu, 11 Feb 2021 11:29:37 -0500
Matthew Rosato wrote:
> On 2/11/21 10:47 AM, Max Gurtovoy wrote:
> >
> > On 2/2/2021 7:10 PM, Jason Gunthorpe wrote:
> >> On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote:
> >>
> >>> On the other side, we have the zdev support, which both requi
On 2/11/21 10:47 AM, Max Gurtovoy wrote:
On 2/2/2021 7:10 PM, Jason Gunthorpe wrote:
On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote:
On the other side, we have the zdev support, which both requires s390
and applies to any pci device on s390.
Is there a reason why CONFIG_VFIO_P
On 2/2/2021 7:10 PM, Jason Gunthorpe wrote:
On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote:
On the other side, we have the zdev support, which both requires s390
and applies to any pci device on s390.
Is there a reason why CONFIG_VFIO_PCI_ZDEV exists? Why not just always
retur
On Thu, Feb 11, 2021 at 08:50:21AM +, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 11:12:49AM +0200, Max Gurtovoy wrote:
> > But the PCI function (the bounded BDF) is GPU function or NVLINK function ?
> >
> > If it's NVLINK function then we should fail probing in the host vfio-pci
> > dr
On Thu, Feb 11, 2021 at 08:47:03AM +, Christoph Hellwig wrote:
> On Wed, Feb 03, 2021 at 09:54:48AM -0400, Jason Gunthorpe wrote:
> > If people are accepting that these device-specific drivers are
> > required then we need to come to a community consensus to decide what
> > direction to pursue:
On Wed, Feb 03, 2021 at 09:54:48AM -0400, Jason Gunthorpe wrote:
> If people are accepting that these device-specific drivers are
> required then we need to come to a community consensus to decide what
> direction to pursue:
>
> * Do we embrace the driver core and use it to load VFIO modules like
On Tue, Feb 02, 2021 at 04:59:23PM -0700, Alex Williamson wrote:
> vfio-pci-igd support knows very little about the device, we're
> effectively just exposing a firmware table and some of the host bridge
> config space (read-only). So the idea that the host kernel needs to
> have updated i915 suppo
On Thu, Feb 04, 2021 at 11:12:49AM +0200, Max Gurtovoy wrote:
> But the PCI function (the bounded BDF) is GPU function or NVLINK function ?
>
> If it's NVLINK function then we should fail probing in the host vfio-pci
> driver.
>
> if its a GPU function so it shouldn't been called nvlink2 vfio-pci
On 08/02/2021 23:44, Max Gurtovoy wrote:
On 2/5/2021 2:42 AM, Alexey Kardashevskiy wrote:
On 04/02/2021 23:51, Jason Gunthorpe wrote:
On Thu, Feb 04, 2021 at 12:05:22PM +1100, Alexey Kardashevskiy wrote:
It is system firmware (==bios) which puts stuff in the device tree. The
stuff is:
1
On 09/02/2021 05:13, Jason Gunthorpe wrote:
On Fri, Feb 05, 2021 at 11:42:11AM +1100, Alexey Kardashevskiy wrote:
A real nvswitch function?
What do you mean by this exactly? The cpu side of nvlink is "emulated pci
devices", the gpu side is not in pci space at all, the nvidia driver manages
On Fri, Feb 05, 2021 at 11:42:11AM +1100, Alexey Kardashevskiy wrote:
> > A real nvswitch function?
>
> What do you mean by this exactly? The cpu side of nvlink is "emulated pci
> devices", the gpu side is not in pci space at all, the nvidia driver manages
> it via the gpu's mmio or/and cfg space.
On 2/5/2021 2:42 AM, Alexey Kardashevskiy wrote:
On 04/02/2021 23:51, Jason Gunthorpe wrote:
On Thu, Feb 04, 2021 at 12:05:22PM +1100, Alexey Kardashevskiy wrote:
It is system firmware (==bios) which puts stuff in the device tree. The
stuff is:
1. emulated pci devices (custom pci bridges),
On 04/02/2021 23:51, Jason Gunthorpe wrote:
On Thu, Feb 04, 2021 at 12:05:22PM +1100, Alexey Kardashevskiy wrote:
It is system firmware (==bios) which puts stuff in the device tree. The
stuff is:
1. emulated pci devices (custom pci bridges), one per nvlink, emulated by
the firmware, the driv
On Thu, Feb 04, 2021 at 12:05:22PM +1100, Alexey Kardashevskiy wrote:
> It is system firmware (==bios) which puts stuff in the device tree. The
> stuff is:
> 1. emulated pci devices (custom pci bridges), one per nvlink, emulated by
> the firmware, the driver is "ibmnpu" and it is a part on the nvi
On 2/3/2021 5:24 AM, Alexey Kardashevskiy wrote:
On 03/02/2021 04:41, Max Gurtovoy wrote:
On 2/2/2021 6:06 PM, Cornelia Huck wrote:
On Mon, 1 Feb 2021 11:42:30 -0700
Alex Williamson wrote:
On Mon, 1 Feb 2021 12:49:12 -0500
Matthew Rosato wrote:
On 2/1/21 12:14 PM, Cornelia Huck wrote
On 2/3/2021 5:24 AM, Alexey Kardashevskiy wrote:
On 03/02/2021 04:41, Max Gurtovoy wrote:
On 2/2/2021 6:06 PM, Cornelia Huck wrote:
On Mon, 1 Feb 2021 11:42:30 -0700
Alex Williamson wrote:
On Mon, 1 Feb 2021 12:49:12 -0500
Matthew Rosato wrote:
On 2/1/21 12:14 PM, Cornelia Huck wrote
On Tue, Feb 02, 2021 at 04:59:23PM -0700, Alex Williamson wrote:
> On Tue, 2 Feb 2021 19:06:04 -0400
> Jason Gunthorpe wrote:
>
> > On Tue, Feb 02, 2021 at 02:30:13PM -0700, Alex Williamson wrote:
> >
> > > The first set of users already fail this specification though, we can't
> > > base it str
On Tue, 2 Feb 2021 19:06:04 -0400
Jason Gunthorpe wrote:
> On Tue, Feb 02, 2021 at 02:30:13PM -0700, Alex Williamson wrote:
>
> > The first set of users already fail this specification though, we can't
> > base it strictly on device and vendor IDs, we need wildcards, class
> > codes, revision ID
On Tue, Feb 02, 2021 at 02:30:13PM -0700, Alex Williamson wrote:
> The first set of users already fail this specification though, we can't
> base it strictly on device and vendor IDs, we need wildcards, class
> codes, revision IDs, etc., just like any other PCI drvier. We're not
> going to mainta
On Tue, 2 Feb 2021 22:59:27 +0200
Max Gurtovoy wrote:
> On 2/2/2021 10:44 PM, Jason Gunthorpe wrote:
> > On Tue, Feb 02, 2021 at 12:37:23PM -0700, Alex Williamson wrote:
> >
> >> For the most part, this explicit bind interface is redundant to
> >> driver_override, which already avoids the dupli
On 2/2/2021 10:44 PM, Jason Gunthorpe wrote:
On Tue, Feb 02, 2021 at 12:37:23PM -0700, Alex Williamson wrote:
For the most part, this explicit bind interface is redundant to
driver_override, which already avoids the duplicate ID issue.
No, the point here is to have the ID tables in the PCI d
On Tue, Feb 02, 2021 at 12:37:23PM -0700, Alex Williamson wrote:
> For the most part, this explicit bind interface is redundant to
> driver_override, which already avoids the duplicate ID issue.
No, the point here is to have the ID tables in the PCI drivers because
they fundamentally only work
On Tue, 2 Feb 2021 14:50:17 -0400
Jason Gunthorpe wrote:
> On Tue, Feb 02, 2021 at 10:54:55AM -0700, Alex Williamson wrote:
>
> > As noted previously, if we start adding ids for vfio drivers then we
> > create conflicts with the native host driver. We cannot register a
> > vfio PCI driver that
On Tue, Feb 02, 2021 at 06:55:18PM +, Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 02:50:17PM -0400, Jason Gunthorpe wrote:
> > For uAPI compatability vfio_pci.ko would need some
> > request_module()/symbol_get() trick to pass control over to the device
> > specific module.
>
> Err, don'
On Tue, Feb 02, 2021 at 02:50:17PM -0400, Jason Gunthorpe wrote:
> For uAPI compatability vfio_pci.ko would need some
> request_module()/symbol_get() trick to pass control over to the device
> specific module.
Err, don't go there.
Please do the DRIVER_EXPLICIT_BIND_ONLY thing first, which avoids
On Tue, Feb 02, 2021 at 10:54:55AM -0700, Alex Williamson wrote:
> As noted previously, if we start adding ids for vfio drivers then we
> create conflicts with the native host driver. We cannot register a
> vfio PCI driver that automatically claims devices.
We can't do that in vfio_pci.ko, but a
On Tue, 2 Feb 2021 19:41:16 +0200
Max Gurtovoy wrote:
> On 2/2/2021 6:06 PM, Cornelia Huck wrote:
> > On Mon, 1 Feb 2021 11:42:30 -0700
> > Alex Williamson wrote:
> >
> >> On Mon, 1 Feb 2021 12:49:12 -0500
> >> Matthew Rosato wrote:
> >>
> >>> On 2/1/21 12:14 PM, Cornelia Huck wrote:
> >>
On 2/2/2021 6:06 PM, Cornelia Huck wrote:
On Mon, 1 Feb 2021 11:42:30 -0700
Alex Williamson wrote:
On Mon, 1 Feb 2021 12:49:12 -0500
Matthew Rosato wrote:
On 2/1/21 12:14 PM, Cornelia Huck wrote:
On Mon, 1 Feb 2021 16:28:27 +
Max Gurtovoy wrote:
This patch doesn't change any
On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote:
> On the other side, we have the zdev support, which both requires s390
> and applies to any pci device on s390.
Is there a reason why CONFIG_VFIO_PCI_ZDEV exists? Why not just always
return the s390 specific data in VFIO_DEVICE_GET_I
On Mon, 1 Feb 2021 11:42:30 -0700
Alex Williamson wrote:
> On Mon, 1 Feb 2021 12:49:12 -0500
> Matthew Rosato wrote:
>
> > On 2/1/21 12:14 PM, Cornelia Huck wrote:
> > > On Mon, 1 Feb 2021 16:28:27 +
> > > Max Gurtovoy wrote:
> > >
> > >> This patch doesn't change any logic but only
On Mon, 1 Feb 2021 12:49:12 -0500
Matthew Rosato wrote:
> On 2/1/21 12:14 PM, Cornelia Huck wrote:
> > On Mon, 1 Feb 2021 16:28:27 +
> > Max Gurtovoy wrote:
> >
> >> This patch doesn't change any logic but only align to the concept of
> >> vfio_pci_core extensions. Extensions that are rel
On 2/1/21 12:14 PM, Cornelia Huck wrote:
On Mon, 1 Feb 2021 16:28:27 +
Max Gurtovoy wrote:
This patch doesn't change any logic but only align to the concept of
vfio_pci_core extensions. Extensions that are related to a platform
and not to a specific vendor of PCI devices should be part of
On Mon, 1 Feb 2021 16:28:27 +
Max Gurtovoy wrote:
> This patch doesn't change any logic but only align to the concept of
> vfio_pci_core extensions. Extensions that are related to a platform
> and not to a specific vendor of PCI devices should be part of the core
> driver. Extensions that are
This patch doesn't change any logic but only align to the concept of
vfio_pci_core extensions. Extensions that are related to a platform
and not to a specific vendor of PCI devices should be part of the core
driver. Extensions that are specific for PCI device vendor should go
to a dedicated vendor
35 matches
Mail list logo
