On 10/17/17 8:36 PM, Alexey Kardashevskiy wrote: > PowerNV KVM guest is a pseries machine so this code will execute there. > The configure sriov path will fail and not enable sriov if resources are not met. I.e. the IOV Bar is not set in PF IOV Resources, which in this case gets assigned by firmware. We have separated the calls to put PowerNV and PSeries as machine dependent calls. Furthermore, we are adding device node properties in the device tree to identify if this is an SR-IOV slot on Phyp Pseries platform. Verification will be in place to distinguish between platforms that support SR-IOV in PSeries. >> Which is the reason for >> the separation of calls to the machine dependent stuff. >>> We also use the pseries platform when running under KVM. >>> >>> cheers >>> >> If anyone plans to enable SR-IOV on Pseries platform, firmware must provide the >> resources to enable the VFs and map them with system resources. > This is what the PowerNV platform does. Again, we have separated the machine dependent calls to different platforms. In our case we don't use opal and our dependent on phyp to associate resources. > >> A new version >> of the PAPR Document will be added to document these system resources. > The guest simply gets yet another PCI device, how is IOV different here? > > In regard of EEH, the API does not change afaik, it is up to the hypervisor > (KVM+QEMU) to handle IOV case correctly. I don't understand your question entirely, can you rephrase?
