On Thu, Mar 11, 2021 at 12:37:06PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 10, 2021 at 08:31:27AM -0400, Jason Gunthorpe wrote:
> > Yes, that needs more refactoring. I'm viewing this series as a
> > "statement of intent" and once we commit to doing this we can go
> > through the bigger effort
On 3/11/2021 1:37 PM, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 08:31:27AM -0400, Jason Gunthorpe wrote:
Yes, that needs more refactoring. I'm viewing this series as a
"statement of intent" and once we commit to doing this we can go
through the bigger effort to split up vfio_pci_core an
On Wed, Mar 10, 2021 at 08:31:27AM -0400, Jason Gunthorpe wrote:
> Yes, that needs more refactoring. I'm viewing this series as a
> "statement of intent" and once we commit to doing this we can go
> through the bigger effort to split up vfio_pci_core and tidy its API.
>
> Obviously this is a big p
On Wed, Mar 10, 2021 at 09:15:08AM +0100, Christoph Hellwig wrote:
> > + vfio_pci_vf_token_user_add(vdev, -1);
> > + vfio_pci_core_spapr_eeh_release(vdev);
> > + vfio_pci_core_disable(vdev);
> > + }
> > + mutex_unlock(&vdev->reflck->lock);
>
> But more importantly
The terminology is all weird here. You don't export functionality
you move it. And this is not a "vendor" driver, but just a device
specific one.
> +struct igd_vfio_pci_device {
> + struct vfio_pci_core_device vdev;
> +};
Why do you need this separate structure? You could just use
vfio
5 matches
Mail list logo
