On Tue, Oct 17, 2017 at 09:33:34AM -0500, Juan Alvarez wrote: > On 10/17/17 8:51 AM, Bjorn Helgaas wrote: > > This is where I get confused. I guess the Linux that sets > > PCI_SRIOV_CTRL_VFE to enable the VFs can also perform config accesses > > to the VFs, since it can enumerate them and build pci_dev structs for > > them, right? > > Correct, we are not changing anything related to how the VF gets initialized > in the kernel. > > > > And the Linux in the "Hosting Partition" is a guest that cannot see a > > VF until a management console attaches the VF to the Hosting > > Partition? > > Correct, this is how PHYP does normal adapter assignment. > > > I'm not a VFIO or KVM expert but that sounds vaguely like > > what they would do when assigning a VF to a guest. > > I do not know the specifics on VFIO and KVM. However, in this > case there is no KVM running on the Linux LPAR. PHYP owns all > the system resources. To pop back up to the top of the stack, I think the main point of this patch is to keep from binding a driver to the VFs in the kernel that set PCI_SRIOV_CTRL_VFE. This patch does that by setting pdev->match_driver to -1 in powerpc-specific code. I think all systems, not just powerpc, want to prevent this VF driver binding, so I hope there's a generic solution that everybody can use. > >> So like existing way of enabling SRIOV we still rely on the PF driver to > >> enable VFs - but in this case the attachment phase is done via a user > >> action via a management console in our case (novalink or hmc) triggered > >> event that will essentially act like a hotplug. > >> > >> So in the fine details of that user triggered action the system > >> firmware will bind the VFs, allowing resources to be allocated to > >> the VF. - Which essentially does all the attaching as we know it > >> today but is managed by PHYP not by the kernel. > > > > What exactly does "firmware binding the VFs" mean? I guess this must > > mean assigning a VF to a partition, injecting a hotplug add event to > > that partition, and making the VF visible in config space? > > Firmware basically adds a device node to the device tree as defined > in the (PAPR) Power Architecture Platform Requirements document. >From the point of view of the kernel that consumes this device tree and owns the VF, I guess this looks like a hot-add. It would be nice if this could be exposed to that kernel by having the firmware inject a normal PCIe hotplug interrupt, but I'm guessing it's not that simple. But if I understand correctly, this patch series isn't concerned with that kernel; it's concerned with the kernel that owns the PF and sets PCI_SRIOV_CTRL_VFE. Bjorn
