From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Jiang Liu <liuj97@gmail.com>, Donald Dutile <ddutile@redhat.com>,
Greg Rose <gregory.v.rose@intel.com>
Subject: Re: [PATCH] PCI: Stop sriov before remove PF
Date: Fri, 19 Jul 2013 16:22:23 -0700 [thread overview]
Message-ID: <51E9CA2F.5050307@intel.com> (raw)
In-Reply-To: <CAE9FiQXUgSVO8h=+JTY-giQ_jz9DryOXDsFJJeMT-y1J9Sv+fA@mail.gmail.com>
On 07/19/2013 03:44 PM, Yinghai Lu wrote:
> On Fri, Jul 19, 2013 at 2:46 PM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>> On 07/19/2013 12:14 PM, Yinghai Lu wrote:
>>> After commit dc087f2f6a2925e81831f3016b9cbb6e470e7423
>>> (PCI: Simplify IOV implementation and fix reference count races)
>>> VF need to be removed via virtfn_remove to make sure ref to PF
>>> is put back.
>>>
>>> Some driver (like ixgbe) does not call pci_disable_sriov() if
>>> sriov is enabled via /sys/.../sriov_numvfs setting.
>>> ixgbe does allow driver for PF get detached, but still have VFs
>>> around.
>>>
>>> But how about PF get removed via /sys or pciehp?
>>>
>>> During hot-remove, VF will still hold one ref to PF and it
>>> prevent PF to be removed.
>>> That make the next hot-add fails, as old PF dev struct is still around.
>>>
>>> We need to add pci_disable_sriov() calling during pci dev removing.
>>>
>>> Need this one for v3.11
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>> Cc: Jiang Liu <liuj97@gmail.com>
>>> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
>>> Cc: Donald Dutile <ddutile@redhat.com>
>>> Cc: Greg Rose <gregory.v.rose@intel.com>
>>>
>>> ---
>>> drivers/pci/remove.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> Index: linux-2.6/drivers/pci/remove.c
>>> ===================================================================
>>> --- linux-2.6.orig/drivers/pci/remove.c
>>> +++ linux-2.6/drivers/pci/remove.c
>>> @@ -34,6 +34,9 @@ static void pci_stop_dev(struct pci_dev
>>>
>>> static void pci_destroy_dev(struct pci_dev *dev)
>>> {
>>> + /* remove VF, if PF driver skip that */
>>> + pci_disable_sriov(dev);
>>> +
>>> down_write(&pci_bus_sem);
>>> list_del(&dev->bus_list);
>>> up_write(&pci_bus_sem);
>>>
>> How are you able to hot-remove the PF if the VFs are still holding
>> references to it?
> usually pci_stop_and_remove_bus_device always successfully, and
> power get turned off for that card.
I'm not an expert in this area, but that doesn't seem right. How is it
you can remove a device if there are still outstanding references to
it? Is this one of those cases where we have to succeed because the
system is removing the device and there is nothing we can do to stop it?
>> The issue I see with this patch is that if the PF has any VFs direct
>> assigned, hot plug removing the PF will cause the guests containing
>> those VFs to panic.
> Then you should make guest support hotplug or suprise removal.
>
> If the guest does panic because it does support hotplug, that is right behavior.
>
> Just like in bare metal machine, if it does not support hotplug, and user would
> know what is going to happen if he remove one pcie card.
>
> Thanks
>
> Yinghai
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.
Thanks,
Alex
next prev parent reply other threads:[~2013-07-19 23:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-19 19:14 [PATCH] PCI: Fix hotplug remove with sriov again Yinghai Lu
2013-07-19 19:14 ` [PATCH] PCI: Separate stop and remove devices in pciehp Yinghai Lu
2013-07-22 21:23 ` Bjorn Helgaas
2013-07-23 2:32 ` Yinghai Lu
2013-07-23 15:56 ` Bjorn Helgaas
2013-07-23 22:44 ` Yinghai Lu
2013-07-23 23:15 ` Yinghai Lu
2013-07-24 4:00 ` Yijing Wang
2013-07-26 22:05 ` Bjorn Helgaas
2013-07-27 14:30 ` Yinghai Lu
2013-07-19 19:14 ` [PATCH] PCI: Stop sriov before remove PF Yinghai Lu
2013-07-19 21:46 ` Alexander Duyck
2013-07-19 22:44 ` Yinghai Lu
2013-07-19 23:22 ` Alexander Duyck [this message]
2013-07-23 15:34 ` Don Dutile
2013-07-23 16:10 ` Yinghai Lu
2013-07-22 23:15 ` Bjorn Helgaas
2013-07-23 1:59 ` Yinghai Lu
2013-07-22 7:07 ` [PATCH] PCI: Fix hotplug remove with sriov again Yijing Wang
2013-07-22 17:39 ` Bjorn Helgaas
2013-07-22 17:48 ` Yinghai Lu
2013-07-23 17:40 ` Bjorn Helgaas
2013-07-24 2:01 ` Yijing Wang
2013-07-24 2:04 ` Yinghai Lu
2013-07-24 2:15 ` Yinghai Lu
2013-07-24 2:25 ` Yijing Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E9CA2F.5050307@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=ddutile@redhat.com \
--cc=gregory.v.rose@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).