On Tue, Jul 23, 2013 at 8:34 AM, Don Dutile <ddutile@xxxxxxxxxx> wrote: >> >> I suspect that is much easier said than done. We probably need somebody >> familiar with the KVM side of things to address the feasibility of >> something like that. I believe it was Greg and Don that worked on the >> original patches that made it so that we could leave the VFs in place on >> driver removal. They would likely have a better answer as to why it is >> preferable to leave the VFs in place than panic a non-compliant guest. > > > The virtual effect of leaving the VFs in place was the equivalent of > unplugging > the cable from the VF device in the guest. When the PF driver was reloaded, > it > caused the virtual effect of the network cable being reconnected. Before > that > patch set (in ixgbe & igb), a PF driver unload in the host would result in > the VF > assigned to KVM a guest caused a *host crash*. > So, start up a KVM (linux) guest, hot-remove the PF with a VF > assigned to a guest, and with these patches applied, ensure the host doesn't > crash. > if it does crash, that's a regression that can't be tolerated, and this > patch (set) > will need further work. at beginning, we have pcie native hotlpug working even with sriov enabled. later patchset (in ixgbe & igb) will not call disable_sriov, that cause hotplug does not work anymore, so that is first regression at all. Anyway, guest host crash is not regression when PF get removed, that is old behavior when guest/sriov pci passthrough support is added. So need to pci_stub to notify guest to do hotremove, when PF's driver get detached? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
