qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org,
	Anthony Liguori <aliguori@amazon.com>,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 2/2] acpi-build: skip hotplugged bridges
Date: Thu, 29 Jan 2015 12:13:22 +0100	[thread overview]
Message-ID: <20150129121322.7fd29833@nial.brq.redhat.com> (raw)
In-Reply-To: <1422462623-2887-2-git-send-email-mst@redhat.com>

On Wed, 28 Jan 2015 18:30:38 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> hotplugged bridges don't get bsel allocated so acpi hotplug doesn't work
> for them anyway.  OTOH adding them in ACPI creates a host of problems,
> e.g. they can't be hot-unplugged themselves which is surprising to
> users.
> 
> So let's just skip these.

While reviewing this patch I've found out that in current master
hotplug bridge + reboot creates shrunk SSDT  which leads to
RSDT offset shift -> static RSDP no longer points at it.

Sequence of events are following:
 
  1: on reboot create subtree with hotplugged bridge device but without slots since
       1: hotplugged bridge doesn't have BSEL -> can_eject = false for every slot
       2: every slot marked as non present since no device plugged in it
     that leads to skipping creation of slot devices inside bridge
  2. condition
       if (bus_hotplug_support || child->notify_table->len || !bus->parent_dev)
     also completely skips creation of notify_table and device_table,
     hence parent bus never adds bridge subtree to its context.
  3. since for the slot where bridge was hotplugged
       bridge_in_acpi = pc->is_bridge && child->pcihp_bridge_en;
       if (pc->class_id == PCI_CLASS_BRIDGE_ISA || bridge_in_acpi) {
            set_bit(slot, slot_device_system); 
     its parent bus, completely skips creation of slot device relying
     on it being provided by child->device_table but due to #2
     it doesn't happen.
As result of all above PCI0 tree description shrinks on 56 bytes,
size of skipped original hotplug slot.


> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  hw/i386/acpi-build.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 74586f3..ff42de5 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -857,8 +857,10 @@ static void build_pci_bus_end(PCIBus *bus, void *bus_state)
>      /*
>       * Skip bridge subtree creation if bridge hotplug is disabled
>       * to make acpi tables compatible with legacy machine types.
> +     * Skip creation for hotplugged bridges as well.
>       */
> -    if (!child->pcihp_bridge_en && bus->parent_dev) {
> +    if (bus->parent_dev && (!child->pcihp_bridge_en ||
> +                            DEVICE(bus->parent_dev)->hotplugged)) {
according to above findings this doesn't change anything,
since device_table won't be populated in the end anyway.
It just makes outcome clearer.

but following hunk makes a difference.

>          build_free_array(bus_table);
>          build_pci_bus_state_cleanup(child);
>          g_free(child);
> @@ -915,8 +917,10 @@ static void build_pci_bus_end(PCIBus *bus, void *bus_state)
>          /* When hotplug for bridges is enabled, bridges are
>           * described in ACPI separately (see build_pci_bus_end).
>           * In this case they aren't themselves hot-pluggable.
> +         * Hotplugged bridges *are* hot-pluggable.
>           */
> -        bridge_in_acpi = pc->is_bridge && child->pcihp_bridge_en;
> +        bridge_in_acpi = pc->is_bridge && child->pcihp_bridge_en &&
> +         !DEVICE(pdev)->hotplugged;
with this, current bus tree keeps hotplugged slot description for slot
where bridge was hotplugged and keeps SSDT size exactly the same across
reboot. But it has side effect that it would be possible to invoke
hot-unplug on it -> I don't know what side effects it will cause at the end.

However it doesn't fix immutable RSDP pointing to fixed RSDT offset,
i.e. it's fixing symptoms until the next time we hit shifted RSDT problem.
Proper fix would be make RSDP updated on reboot along with currently
updated ACPI tables blob.

That also rises a question: do we need to rebuild ACPI tables on
reboot at all? If yes, Why?

>  
>          if (pc->class_id == PCI_CLASS_BRIDGE_ISA || bridge_in_acpi) {
>              set_bit(slot, slot_device_system);

  reply	other threads:[~2015-01-29 11:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 16:30 [Qemu-devel] [PATCH 1/2] acpi-build: fix memory leak with bridge hp off Michael S. Tsirkin
2015-01-28 16:30 ` [Qemu-devel] [PATCH 2/2] acpi-build: skip hotplugged bridges Michael S. Tsirkin
2015-01-29 11:13   ` Igor Mammedov [this message]
2015-01-30 13:35 ` [Qemu-devel] [PATCH 1/2] acpi-build: fix memory leak with bridge hp off 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=20150129121322.7fd29833@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=zhaoshenglong@huawei.com \
    /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).