On Mon, 20 Jun 2016 16:02:59 +0200 Laszlo Ersek <ler...@redhat.com> wrote:
> Hi, > > I posted a related question in > > http://thread.gmane.org/gmane.comp.bios.edk2.devel/13381 > > but I thought I'd approach it from another angle, more succinctly. > > If I set PcdSrIovSupport to FALSE, what functionality exactly will > become unavailable in the firmware? I tried to grep the source for it, > but since I'm not familiar with virtual functions at all, I couldn't > learn much from the code. > > From > <https://en.wikipedia.org/wiki/Single-root_input/output_virtualization>, > > The SR-IOV allows different virtual machines (VMs) in a virtual > environment to share a single PCI Express hardware interface. > > Furthermore, the following edk2 commit: > > https://github.com/tianocore/edk2/commit/d40483911c83 > > says > > Change type of PcdSrIovSupport, PcdAriSupport, PcdMrIovSupport from > FeatureFlag to [FixAtBuild, PcdDynamics], which allows > SR-IOV/MR-IOV/ARI feature can be turn on/off dynamically, typically > via a setup option. > > Thus it seems to me that PcdSrIovSupport only makes sense in firmware > for physical hosts, not virtual machines (unless we talk nested virt of > course, but I believe nested virt with QEMU/KVM/VFIO isn't that far > advanced yet). I believe PcdSrIovSupport controls, in the host UEFI > firmware, whether the SR-IOV capability will be available to the > *hypervisor* that runs on the host machine. > > Is that correct? If it is, then I'm going to submit a patch that > disables PcdSrIovSupport for OVMF. As I noted in the bz that spawned this discussion, there are folks that seem to think that enabling SR-IOV from a guest owned PF is not a completely insane thing to do: http://www.spinics.net/lists/kvm/msg134370.html They would probably be sad to see such a change and re-introducing OVMF SR-IOV support in the cases where it's needed seems painful. As I mentioned last week, I'm open to vfio fixes for this as well, whether it's in QEMU or the kernel. The more I think about it, the more I suspect we're asking something unreasonable of OVMF to detect fixed VFBARs, no matter how convenient or robust we might think it would be to do so. Now I'm wondering if we should a) hide the capability from the VM in QEMU (or host kernel?) or b) enable virtualization of the VFBARs for proper sizing while leaving the rest of the capability read-only. I'm not sure the latter has much value, it may just lead to further issues. Thanks, Alex _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
