From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [PATCH 2/4] pcie: update slot power status only is power control is enabled
Date: Fri, 25 Feb 2022 05:05:23 -0500 [thread overview]
Message-ID: <20220225045956-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220224174411.3296848-3-imammedo@redhat.com>
On Thu, Feb 24, 2022 at 12:44:09PM -0500, Igor Mammedov wrote:
> on creation a PCIDevice has power turned on at the end of pci_qdev_realize()
> however later on if PCIe slot isn't populated with any children
> it's power is turned off. It's fine if native hotplug is used
> as plug callback will power slot on among other things.
> However when ACPI hotplug is enabled it replaces native PCIe plug
> callbacks with ACPI specific ones (acpi_pcihp_device_*plug_cb) and
> as result slot stays powered off. It works fine as ACPI hotplug
> on guest side takes care of enumerating/initializing hotplugged
> device. But when later guest is migrated, call chain introduced by [1]
>
> pcie_cap_slot_post_load()
> -> pcie_cap_update_power()
> -> pcie_set_power_device()
> -> pci_set_power()
> -> pci_update_mappings()
>
> will disable earlier initialized BARs for the hotplugged device
> in powered off slot due to commit [2] which disables BARs if
> power is off. As result guest OS after migration will be very
> much confused [3], still thinking that it has working device,
> which isn't true anymore due to disabled BARs.
>
> Fix it by honoring PCI_EXP_SLTCAP_PCP and updating power status
> only if capability is enabled.
> Follow up patch will disable
> PCI_EXP_SLTCAP_PCP overriding COMPAT_PROP_PCP property when
> PCIe slot is under ACPI PCI hotplug control.
>
> See [3] for reproducer.
>
> 1)
> Fixes: commit d5daff7d312 (pcie: implement slot power control for pcie root ports)
> 2)
> commit 23786d13441 (pci: implement power state)
> 3)
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2053584
>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
> hw/pci/pcie.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index d7d73a31e4..2339729a7c 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -383,10 +383,9 @@ static void pcie_cap_update_power(PCIDevice *hotplug_dev)
>
> if (sltcap & PCI_EXP_SLTCAP_PCP) {
> power = (sltctl & PCI_EXP_SLTCTL_PCC) == PCI_EXP_SLTCTL_PWR_ON;
> + pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
> + pcie_set_power_device, &power);
> }
> -
> - pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
> - pcie_set_power_device, &power);
Hmm I wrote I like it but now I am not sure I understand how does this
patch help fix things. here is the full function:
static void pcie_cap_update_power(PCIDevice *hotplug_dev)
{
uint8_t *exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
PCIBus *sec_bus = pci_bridge_get_sec_bus(PCI_BRIDGE(hotplug_dev));
uint32_t sltcap = pci_get_long(exp_cap + PCI_EXP_SLTCAP);
uint16_t sltctl = pci_get_word(exp_cap + PCI_EXP_SLTCTL);
bool power = true;
if (sltcap & PCI_EXP_SLTCAP_PCP) {
power = (sltctl & PCI_EXP_SLTCTL_PCC) == PCI_EXP_SLTCTL_PWR_ON;
}
pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
pcie_set_power_device, &power);
}
I understand the follow up patch, but it looks to me that without the
capability, power is always on. Why does skipping that help fix
anything?
Thanks,
> }
>
> /*
> --
> 2.31.1
next prev parent reply other threads:[~2022-02-25 10:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 17:44 [PATCH 0/4] Fix broken PCIe device after migration Igor Mammedov
2022-02-24 17:44 ` [PATCH 1/4] pci: expose TYPE_XIO3130_DOWNSTREAM name Igor Mammedov
2022-02-24 17:44 ` [PATCH 2/4] pcie: update slot power status only is power control is enabled Igor Mammedov
2022-02-24 18:05 ` Michael S. Tsirkin
2022-02-25 8:18 ` Igor Mammedov
2022-02-25 9:51 ` Michael S. Tsirkin
2022-02-25 10:05 ` Michael S. Tsirkin [this message]
2022-02-25 10:12 ` Gerd Hoffmann
2022-02-25 10:35 ` Michael S. Tsirkin
2022-02-25 13:02 ` Igor Mammedov
2022-02-25 13:08 ` Michael S. Tsirkin
2022-02-25 13:35 ` Igor Mammedov
2022-02-25 13:48 ` Michael S. Tsirkin
2022-02-25 15:39 ` Igor Mammedov
2022-02-28 7:39 ` Gerd Hoffmann
2022-02-28 8:55 ` Igor Mammedov
2022-02-24 17:44 ` [PATCH 3/4] acpi: pcihp: disable power control on PCIe slot Igor Mammedov
2022-02-24 17:44 ` [PATCH 4/4] q35: compat: keep hotplugged PCIe device broken after migration for 6.2-older machine types Igor Mammedov
2022-02-24 18:11 ` Michael S. Tsirkin
2022-02-25 8:25 ` Igor Mammedov
2022-02-24 18:08 ` [PATCH 0/4] Fix broken PCIe device after migration Michael S. Tsirkin
2022-02-25 9:01 ` Igor Mammedov
2022-02-25 9:58 ` Michael S. Tsirkin
2022-02-25 13:18 ` Igor Mammedov
2022-02-25 13:50 ` Michael S. Tsirkin
2022-02-25 15:50 ` Igor Mammedov
2022-02-27 10:22 ` Michael S. Tsirkin
2022-02-28 7:49 ` Gerd Hoffmann
2022-02-25 14:32 ` Igor Mammedov
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=20220225045956-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.