[vfio-users] Passthru of one GPU with a PC with 2 identical GPUs installed

[James Courtier-Dutton]

On Wed, 22 May 2019 at 00:11, Alex Williamson <alex.williamson at redhat.com>
wrote:

>
> I think a better approach would be to extend the pci= kernel command
> line option to include driver_override support, perhaps something like:
>
> pci=...,driver_overrides=<pci_dev1>=<driver1>;<pci_dev2>=<driver2>,
>
>
> OK, lets assume for a moment, that I will try to implement the above.
Mindful of the fact that if there is a bug in this code, it might upset a
far wider amount of people than my previous suggestion that would only
affect vfio-pci users.
I understand that rather than the driver selectively ignoring a device
probe for a specific device, this method would restrict the probe call
itself, to only call the mentioned driver.

Use Case 1: I can understand how the pci=...  line can go in the kernel
boot command line and kind of force the driver_binding of pci_dev and its
driver.
Use Case 2: What I am not so sure about is how this behavior can be
modified after boot. Say, after boot, someone wished to un-bind it from one
driver, and then bind it to a different one, how would we undo the
driver_overrides so that it could then call a device probe on a different
driver?
Use Case 3: A pci_dev is set on the command line, but it is not yet present
in the system, but we wish the setting to be there for when that device is
hot-plugged.

Are there any other use cases I should consider?
Might we wish to consider an option so the user can, for a specific device,
unbind it from one driver and bind it to a different one.

I have also noticed this interface:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci
Where 0000:00:19.0 format is used for the bind/unbind methods, and not your
device path suggestion.
For consistency, would we need to add support for device path to the
bind/unbind methods?

Kind Regards

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20190522/6b81c6f8/attachment.htm>