All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: qemu-devel@nongnu.org, lersek@redhat.com
Cc: Marcel Apfelbaum <marcel@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Qemu-devel] [PATCH v6 4/7] hw/pci-bridge: disable hotplug in PXB
Date: Wed, 17 Jun 2015 14:45:02 +0200	[thread overview]
Message-ID: <1434545105-5811-5-git-send-email-lersek@redhat.com> (raw)
In-Reply-To: <1434545105-5811-1-git-send-email-lersek@redhat.com>

OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI
Bus driver globally signals the firmware that PCI enumeration and resource
allocation have completed. At this point QEMU regenerates the ACPI payload
in an fw_cfg read callback, and this is when the PXB's _CRS gets
populated.

Unfortunately, when this happens, the PCI_COMMAND_MEMORY bit is clear in
the root bus's command register, *unlike* under SeaBIOS. The consequences
unfold as follows:

- When build_crs() fetches dev->io_regions[i].addr, it is all-bits-one,
  because pci_update_mappings() --> pci_bar_address() calculated it as
  PCI_BAR_UNMAPPED, due to the PCI_COMMAND_MEMORY bit being clear.

- Consequently, the SHPC MMIO BAR (bar 0) of the bridge is not added to
  the _CRS, *despite* having been programmed in PCI config space.

- Similarly, the SHPC MMIO BAR of the PXB is not removed from the main
  root bus's DWordMemory descriptor.

- Guest OSes (Linux and Windows alike) notice the pre-programmed SHPC BAR
  within the PXB's config space, and notice that it conflicts with the
  main root bus's memory resource descriptors. Linux reports

  pci 0000:04:00.0: BAR 0: can't assign mem (size 0x100)
  pci 0000:04:00.0: BAR 0: trying firmware assignment [mem
                           0x88200000-0x882000ff 64bit]
  pci 0000:04:00.0: BAR 0: [mem 0x88200000-0x882000ff 64bit] conflicts
                           with PCI Bus 0000:00 [mem
                           0x88200000-0xfebfffff]

  While Windows Server 2012 R2 reports

    https://technet.microsoft.com/en-us/library/cc732199%28v=ws.10%29.aspx

    This device cannot find enough free resources that it can use. If you
    want to use this device, you will need to disable one of the other
    devices on this system. (Code 12)

This issue was apparently encountered earlier, see the "hack" in:

  https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02983.html

and the current hole-punching logic in build_crs() and build_ssdt() is
probably supposed to remedy exactly that problem -- however, for OVMF they
don't work, because at the end of the PCI enumeration and resource
allocation, which cues the ACPI linker/loader client, the command register
is clear.

The "hotplug" property of "pci-bridge", introduced in the previous
patches, enables us to disable the standard hotplug controller cleanly,
eliminating the SHPC bar and the conflict.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---

Notes:
    v6:
    - new in v6 (replaces "hw/pci-bridge: create interrupt-less,
      hotplug-less bridge for PXB" from v5) [Michael]

 hw/pci-bridge/pci_expander_bridge.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c
index ec2bb45..4398d98 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -176,6 +176,7 @@ static int pxb_dev_initfn(PCIDevice *dev)
     bds = qdev_create(BUS(bus), "pci-bridge");
     bds->id = dev_name;
     qdev_prop_set_uint8(bds, "chassis_nr", pxb->bus_nr);
+    qdev_prop_set_bit(bds, "hotplug", false);
 
     PCI_HOST_BRIDGE(ds)->bus = bus;
 
-- 
1.8.3.1

  parent reply	other threads:[~2015-06-17 12:45 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17 12:44 [Qemu-devel] [PATCH v6 0/7] PXB changes Laszlo Ersek
2015-06-17 12:44 ` [Qemu-devel] [PATCH v6 1/7] migration: introduce VMSTATE_BUFFER_UNSAFE_INFO_TEST() Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 2/7] hw/pci-bridge: expose _test parameter in SHPC_VMSTATE() Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 3/7] hw/pci-bridge: introduce "hotplug" property Laszlo Ersek
2015-06-17 13:42   ` Michael S. Tsirkin
2015-06-17 13:55     ` Laszlo Ersek
2015-06-17 14:02       ` Michael S. Tsirkin
2015-06-17 14:15         ` Laszlo Ersek
2015-06-17 19:54           ` Marcel Apfelbaum
2015-06-18 13:47         ` Paolo Bonzini
2015-06-18 14:44           ` Michael S. Tsirkin
2015-06-17 12:45 ` Laszlo Ersek [this message]
2015-06-17 13:45   ` [Qemu-devel] [PATCH v6 4/7] hw/pci-bridge: disable hotplug in PXB Michael S. Tsirkin
2015-06-17 19:52     ` Marcel Apfelbaum
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 5/7] hw/core: rebase sysbus_get_fw_dev_path() to g_strdup_printf() Laszlo Ersek
2015-06-17 13:46   ` Michael S. Tsirkin
2015-06-17 13:56     ` Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 6/7] hw/core: explicit OFW unit address callback for SysBusDeviceClass Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 7/7] hw/pci-bridge: format SeaBIOS-compliant OFW device node for PXB Laszlo Ersek
2015-06-17 13:57   ` Michael S. Tsirkin
2015-06-17 14:00     ` Laszlo Ersek
2015-06-17 14:03       ` Michael S. Tsirkin
2015-06-17 14:18     ` Kevin O'Connor
2015-06-17 14:45       ` Laszlo Ersek
2015-06-17 15:05         ` Michael S. Tsirkin
2015-06-17 18:16           ` Laszlo Ersek
2015-06-17 18:54             ` Michael S. Tsirkin
2015-06-17 19:15               ` Laszlo Ersek
2015-06-17 19:28                 ` Kevin O'Connor
2015-06-17 19:32                   ` Michael S. Tsirkin
2015-06-17 19:44                     ` Laszlo Ersek
2015-06-17 21:50                       ` Michael S. Tsirkin
2015-06-18 13:22                         ` Laszlo Ersek
2015-06-18 13:40                           ` Michael S. Tsirkin
2015-06-18 15:42                             ` Laszlo Ersek
2015-06-17 19:09             ` Kevin O'Connor
2015-06-17 19:21   ` Michael S. Tsirkin
2015-06-17 19:35     ` Laszlo Ersek
2015-06-17 21:49       ` Michael S. Tsirkin
2015-06-18 13:18         ` Laszlo Ersek
2015-06-17 19:38     ` Kevin O'Connor

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=1434545105-5811-5-git-send-email-lersek@redhat.com \
    --to=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@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.