<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 10/17/17 8:51 AM, Bjorn Helgaas wrote:<br>
</p>
<blockquote type="cite"
cite="mid:20171017135123.GA5641@bhelgaas-glaptop.roam.corp.google.com">
<pre wrap="">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?</pre>
</blockquote>
Correct, we are not changing anything related to how the VF gets
initialized<br>
in the Linux kernel.
<blockquote type="cite"
cite="mid:20171017135123.GA5641@bhelgaas-glaptop.roam.corp.google.com">
<pre wrap="">
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? </pre>
</blockquote>
Correct, this is how PHYP does normal adapter assignment.<br>
<br>
<blockquote type="cite"
cite="mid:20171017135123.GA5641@bhelgaas-glaptop.roam.corp.google.com">
<pre wrap=""> I'm not a VFIO or KVM expert but that sounds vaguely like
what they would do when assigning a VF to a guest.</pre>
</blockquote>
I do not know the specifics on VFIO and KVM. However, in this <br>
case there is no KVM running on the Linux (LPAR) logical partition.<br>
PHYP owns all the system resources.<br>
<blockquote type="cite"
cite="mid:20171017135123.GA5641@bhelgaas-glaptop.roam.corp.google.com">
<pre wrap="">
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
Firmware basically adds a device node to the device tree as defined<br>
in the (PAPR) Power Architecture Platform Requirements document.<br>
<br>
Juan J. Alvarez<br>
</body>
</html>