From 5d593bdf10aace376c83161aa6d6c828cd6fd428 Mon Sep 17 00:00:00 2001 From: Roman Kagan Date: Mon, 2 Nov 2020 08:37:50 +0300 Subject: pci/shpc: don't push attention button when ejecting powered-off device When the slot is in steady powered-off state and the device is being removed, there's no need to press the attention button. Nor is it mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0. Moreover it confuses the guest, Linux in particular, as it assumes that the attention button pressed in this state indicates that the device has been inserted and will need to be powered on. Therefore it transitions the slot into BLINKING_ON state for 5 seconds, and discovers at the end that no device is actually inserted: ... unplug request [12685.451329] shpchp 0000:01:00.0: Button pressed on Slot(2) [12685.455478] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press ... in 5 seconds OS powers off the slot, QEMU ejects the device [12690.632282] shpchp 0000:01:00.0: Latch open on Slot(2) ... excessive button press in steady powered-off state [12690.634267] shpchp 0000:01:00.0: Button pressed on Slot(2) [12690.636256] shpchp 0000:01:00.0: Card not present on Slot(2) ... the last button press spawns powering on the slot [12690.638909] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press ... in 5 more seconds attempt to power on discovers empty slot [12695.735986] shpchp 0000:01:00.0: No adapter on slot(2) Worse, if the real device insertion happens within 5 seconds from the apparent completion of the previous device removal (signaled via DEVICE_DELETED event), the new button press will be interpreted as the cancellation of that misguided powering on: [13448.965295] shpchp 0000:01:00.0: Button pressed on Slot(2) [13448.969430] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press [13454.025107] shpchp 0000:01:00.0: Latch open on Slot(2) [13454.027101] shpchp 0000:01:00.0: Button pressed on Slot(2) [13454.029165] shpchp 0000:01:00.0: Card not present on Slot(2) ... the excessive button press spawns powering on the slot ... device has already been ejected by QEMU [13454.031949] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press ... new device is inserted in the slot [13456.861545] shpchp 0000:01:00.0: Latch close on Slot(2) ... valid button press arrives before 5 s since the wrong one [13456.864894] shpchp 0000:01:00.0: Button pressed on Slot(2) [13456.869211] shpchp 0000:01:00.0: Card present on Slot(2) ... the valid button press is counted as cancellation of the wrong one [13456.873173] shpchp 0000:01:00.0: Button cancel on Slot(2) [13456.877101] shpchp 0000:01:00.0: PCI slot #2 - action canceled due to button press As a result, the newly inserted device isn't brought up by the guest. Avoid this situation by not pushing the attention button when the device in the slot is in powered-off state and is being ejected. FWIW pcie implementation doesn't suffer from this problem. Signed-off-by: Roman Kagan Message-Id: <20201102053750.2281818-1-rvkagan@yandex-team.ru> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/pci/shpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'hw') diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c index 4786a44..28e6217 100644 --- a/hw/pci/shpc.c +++ b/hw/pci/shpc.c @@ -300,7 +300,6 @@ static void shpc_slot_command(SHPCDevice *shpc, uint8_t target, shpc_set_status(shpc, slot, SHPC_SLOT_STATUS_PRSNT_EMPTY, SHPC_SLOT_STATUS_PRSNT_MASK); shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |= - SHPC_SLOT_EVENT_BUTTON | SHPC_SLOT_EVENT_MRL | SHPC_SLOT_EVENT_PRESENCE; } @@ -566,7 +565,6 @@ void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, return; } - shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |= SHPC_SLOT_EVENT_BUTTON; state = shpc_get_status(shpc, slot, SHPC_SLOT_STATE_MASK); led = shpc_get_status(shpc, slot, SHPC_SLOT_PWR_LED_MASK); if (state == SHPC_STATE_DISABLED && led == SHPC_LED_OFF) { @@ -577,6 +575,8 @@ void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |= SHPC_SLOT_EVENT_MRL | SHPC_SLOT_EVENT_PRESENCE; + } else { + shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |= SHPC_SLOT_EVENT_BUTTON; } shpc_set_status(shpc, slot, 0, SHPC_SLOT_STATUS_66); shpc_interrupt_update(pci_hotplug_dev); -- cgit v1.1 From 6da32fe5efdd71c9d254a436ce972194ff631285 Mon Sep 17 00:00:00 2001 From: Laszlo Ersek Date: Tue, 12 Jan 2021 14:16:03 +0100 Subject: vhost-user-fs: add the "bootindex" property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit virtio-fs qualifies as a bootable device minimally under OVMF, but currently the necessary "bootindex" property is missing. Add the property. Expose the property only in the PCI device, for now. There is no boot support for virtiofs on s390x (ccw) for the time being [1] [2], so leave the CCW device unchanged. Add the property to the base device still, because adding the alias to the CCW device later will be easier this way [3]. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01745.html [2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01870.html [3] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01751.html Example OpenFirmware device path for the "vhost-user-fs-pci" device in the "bootorder" fw_cfg file: /pci@i0cf8/pci-bridge@1,6/pci1af4,105a@0/filesystem@0 Cc: "Dr. David Alan Gilbert" Cc: "Michael S. Tsirkin" Cc: Ján Tomko Cc: Stefan Hajnoczi Cc: virtio-fs@redhat.com Signed-off-by: Laszlo Ersek Acked-by: Dr. David Alan Gilbert Message-Id: <20210112131603.12686-1-lersek@redhat.com> Acked-by: Stefan Hajnoczi Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/virtio/vhost-user-fs-pci.c | 2 ++ hw/virtio/vhost-user-fs.c | 10 ++++++++++ 2 files changed, 12 insertions(+) (limited to 'hw') diff --git a/hw/virtio/vhost-user-fs-pci.c b/hw/virtio/vhost-user-fs-pci.c index 8bb389b..2ed8492 100644 --- a/hw/virtio/vhost-user-fs-pci.c +++ b/hw/virtio/vhost-user-fs-pci.c @@ -68,6 +68,8 @@ static void vhost_user_fs_pci_instance_init(Object *obj) virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev), TYPE_VHOST_USER_FS); + object_property_add_alias(obj, "bootindex", OBJECT(&dev->vdev), + "bootindex"); } static const VirtioPCIDeviceTypeInfo vhost_user_fs_pci_info = { diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c index ed036ad..ac4fc34 100644 --- a/hw/virtio/vhost-user-fs.c +++ b/hw/virtio/vhost-user-fs.c @@ -22,6 +22,7 @@ #include "qemu/error-report.h" #include "hw/virtio/vhost-user-fs.h" #include "monitor/monitor.h" +#include "sysemu/sysemu.h" static void vuf_get_config(VirtIODevice *vdev, uint8_t *config) { @@ -279,6 +280,14 @@ static Property vuf_properties[] = { DEFINE_PROP_END_OF_LIST(), }; +static void vuf_instance_init(Object *obj) +{ + VHostUserFS *fs = VHOST_USER_FS(obj); + + device_add_bootindex_property(obj, &fs->bootindex, "bootindex", + "/filesystem@0", DEVICE(obj)); +} + static void vuf_class_init(ObjectClass *klass, void *data) { DeviceClass *dc = DEVICE_CLASS(klass); @@ -300,6 +309,7 @@ static const TypeInfo vuf_info = { .name = TYPE_VHOST_USER_FS, .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VHostUserFS), + .instance_init = vuf_instance_init, .class_init = vuf_class_init, }; -- cgit v1.1 From e41ee855283b79dfd0734e573e9b8d091070190b Mon Sep 17 00:00:00 2001 From: Jiahui Cen Date: Thu, 14 Jan 2021 18:06:38 +0800 Subject: acpi: Add addr offset in build_crs AML needs Address Translation offset to describe how a bridge translates addresses accross the bridge when using an address descriptor, and especially on ARM, the translation offset of pio resource is usually non zero. Therefore, it's necessary to pass offset for pio, mmio32, mmio64 and bus number into build_crs. Acked-by: Igor Mammedov Signed-off-by: Jiahui Cen Message-Id: <20210114100643.10617-4-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/acpi/aml-build.c | 18 ++++++++++-------- hw/i386/acpi-build.c | 3 ++- hw/pci-host/gpex-acpi.c | 3 ++- 3 files changed, 14 insertions(+), 10 deletions(-) (limited to 'hw') diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c index f976aa6..7b6ebb0 100644 --- a/hw/acpi/aml-build.c +++ b/hw/acpi/aml-build.c @@ -2076,7 +2076,9 @@ void build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog) tpm2_ptr, "TPM2", table_data->len - tpm2_start, 4, NULL, NULL); } -Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set) +Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set, uint32_t io_offset, + uint32_t mmio32_offset, uint64_t mmio64_offset, + uint16_t bus_nr_offset) { Aml *crs = aml_resource_template(); CrsRangeSet temp_range_set; @@ -2189,10 +2191,10 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set) for (i = 0; i < temp_range_set.io_ranges->len; i++) { entry = g_ptr_array_index(temp_range_set.io_ranges, i); aml_append(crs, - aml_word_io(AML_MIN_FIXED, AML_MAX_FIXED, - AML_POS_DECODE, AML_ENTIRE_RANGE, - 0, entry->base, entry->limit, 0, - entry->limit - entry->base + 1)); + aml_dword_io(AML_MIN_FIXED, AML_MAX_FIXED, + AML_POS_DECODE, AML_ENTIRE_RANGE, + 0, entry->base, entry->limit, io_offset, + entry->limit - entry->base + 1)); crs_range_insert(range_set->io_ranges, entry->base, entry->limit); } @@ -2205,7 +2207,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set) aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, AML_NON_CACHEABLE, AML_READ_WRITE, - 0, entry->base, entry->limit, 0, + 0, entry->base, entry->limit, mmio32_offset, entry->limit - entry->base + 1)); crs_range_insert(range_set->mem_ranges, entry->base, entry->limit); } @@ -2217,7 +2219,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set) aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, AML_NON_CACHEABLE, AML_READ_WRITE, - 0, entry->base, entry->limit, 0, + 0, entry->base, entry->limit, mmio64_offset, entry->limit - entry->base + 1)); crs_range_insert(range_set->mem_64bit_ranges, entry->base, entry->limit); @@ -2230,7 +2232,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet *range_set) 0, pci_bus_num(host->bus), max_bus, - 0, + bus_nr_offset, max_bus - pci_bus_num(host->bus) + 1)); return crs; diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index f18b71d..f56d699 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -1360,7 +1360,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, } aml_append(dev, build_prt(false)); - crs = build_crs(PCI_HOST_BRIDGE(BUS(bus)->parent), &crs_range_set); + crs = build_crs(PCI_HOST_BRIDGE(BUS(bus)->parent), &crs_range_set, + 0, 0, 0, 0); aml_append(dev, aml_name_decl("_CRS", crs)); aml_append(scope, dev); aml_append(dsdt, scope); diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c index 7f20ee1..11b3db8 100644 --- a/hw/pci-host/gpex-acpi.c +++ b/hw/pci-host/gpex-acpi.c @@ -168,7 +168,8 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg) * 1. The resources the pci-brige/pcie-root-port need. * 2. The resources the devices behind pxb need. */ - crs = build_crs(PCI_HOST_BRIDGE(BUS(bus)->parent), &crs_range_set); + crs = build_crs(PCI_HOST_BRIDGE(BUS(bus)->parent), &crs_range_set, + cfg->pio.base, 0, 0, 0); aml_append(dev, aml_name_decl("_CRS", crs)); acpi_dsdt_add_pci_osc(dev); -- cgit v1.1 From 0cf8882fd06ba0aeb1e90fa6f23fce85504d7e14 Mon Sep 17 00:00:00 2001 From: Jiahui Cen Date: Thu, 14 Jan 2021 18:06:39 +0800 Subject: acpi/gpex: Inform os to keep firmware resource map There may be some differences in pci resource assignment between guest os and firmware. Eg. A Bridge with Bus [d2] -+-[0000:d2]---01.0-[d3]----01.0 where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256] [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K] BAR4 (mem, 64-bit, pref) [size=64M] In EDK2, the Resource Map would be: PciBus: Resource Map for Bridge [D2|01|00] Type = PMem64; Base = 0x8004000000; Length = 0x4100000; Alignment = 0x3FFFFFF Base = 0x8004000000; Length = 0x4000000; Alignment = 0x3FFFFFF; Owner = PCI [D3|01|00:20] Base = 0x8008000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [D3|01|00:10] Type = Mem64; Base = 0x8008100000; Length = 0x100; Alignment = 0xFFF It would use 0x4100000 to calculate the root bus's PMem64 resource window. While in Linux, kernel will use 0x1FFFFFF as the alignment to calculate the PMem64 size, which would be 0x6000000. So kernel would try to allocate 0x6000000 from the PMem64 resource window, but since the window size is 0x4100000 as assigned by EDK2, the allocation would fail. The diffences could result in resource assignment failure. Using _DSM #5 method to inform guest os not to ignore the PCI configuration that firmware has done at boot time could handle the differences. Acked-by: Igor Mammedov Signed-off-by: Jiahui Cen Message-Id: <20210114100643.10617-5-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/pci-host/gpex-acpi.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) (limited to 'hw') diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c index 11b3db8..cb13e75 100644 --- a/hw/pci-host/gpex-acpi.c +++ b/hw/pci-host/gpex-acpi.c @@ -112,10 +112,26 @@ static void acpi_dsdt_add_pci_osc(Aml *dev) UUID = aml_touuid("E5C937D0-3553-4D7A-9117-EA4D19C3434D"); ifctx = aml_if(aml_equal(aml_arg(0), UUID)); ifctx1 = aml_if(aml_equal(aml_arg(2), aml_int(0))); - uint8_t byte_list[1] = {1}; - buf = aml_buffer(1, byte_list); + uint8_t byte_list[] = { + 0x1 << 0 /* support for functions other than function 0 */ | + 0x1 << 5 /* support for function 5 */ + }; + buf = aml_buffer(ARRAY_SIZE(byte_list), byte_list); aml_append(ifctx1, aml_return(buf)); aml_append(ifctx, ifctx1); + + /* + * PCI Firmware Specification 3.1 + * 4.6.5. _DSM for Ignoring PCI Boot Configurations + */ + /* Arg2: Function Index: 5 */ + ifctx1 = aml_if(aml_equal(aml_arg(2), aml_int(5))); + /* + * 0 - The operating system must not ignore the PCI configuration that + * firmware has done at boot time. + */ + aml_append(ifctx1, aml_return(aml_int(0))); + aml_append(ifctx, ifctx1); aml_append(method, ifctx); byte_list[0] = 0; -- cgit v1.1 From aee519c210f2508b5070c4f85ed0e09892042e05 Mon Sep 17 00:00:00 2001 From: Jiahui Cen Date: Thu, 14 Jan 2021 18:06:40 +0800 Subject: acpi/gpex: Exclude pxb's resources from PCI0 Exclude the resources of extra root bridges from PCI0's _CRS. Otherwise, the resource windows would overlap in guest, and the IO resource window would fail to be registered. Acked-by: Igor Mammedov Signed-off-by: Jiahui Cen Message-Id: <20210114100643.10617-6-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/pci-host/gpex-acpi.c | 64 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 21 deletions(-) (limited to 'hw') diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c index cb13e75..446912d 100644 --- a/hw/pci-host/gpex-acpi.c +++ b/hw/pci-host/gpex-acpi.c @@ -146,6 +146,8 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg) Aml *method, *crs, *dev, *rbuf; PCIBus *bus = cfg->bus; CrsRangeSet crs_range_set; + CrsRangeEntry *entry; + int i; /* start to construct the tables for pxb */ crs_range_set_init(&crs_range_set); @@ -193,7 +195,6 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg) aml_append(scope, dev); } } - crs_range_set_free(&crs_range_set); /* tables for the main */ dev = aml_device("%s", "PCI0"); @@ -211,36 +212,55 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg) aml_append(method, aml_return(aml_int(cfg->ecam.base))); aml_append(dev, method); + /* + * At this point crs_range_set has all the ranges used by pci + * busses *other* than PCI0. These ranges will be excluded from + * the PCI0._CRS. + */ rbuf = aml_resource_template(); aml_append(rbuf, aml_word_bus_number(AML_MIN_FIXED, AML_MAX_FIXED, AML_POS_DECODE, 0x0000, 0x0000, nr_pcie_buses - 1, 0x0000, nr_pcie_buses)); if (cfg->mmio32.size) { - aml_append(rbuf, - aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, - AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000, - cfg->mmio32.base, - cfg->mmio32.base + cfg->mmio32.size - 1, - 0x0000, - cfg->mmio32.size)); + crs_replace_with_free_ranges(crs_range_set.mem_ranges, + cfg->mmio32.base, + cfg->mmio32.base + cfg->mmio32.size - 1); + for (i = 0; i < crs_range_set.mem_ranges->len; i++) { + entry = g_ptr_array_index(crs_range_set.mem_ranges, i); + aml_append(rbuf, + aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, + AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000, + entry->base, entry->limit, + 0x0000, entry->limit - entry->base + 1)); + } } if (cfg->pio.size) { - aml_append(rbuf, - aml_dword_io(AML_MIN_FIXED, AML_MAX_FIXED, AML_POS_DECODE, - AML_ENTIRE_RANGE, 0x0000, 0x0000, - cfg->pio.size - 1, - cfg->pio.base, - cfg->pio.size)); + crs_replace_with_free_ranges(crs_range_set.io_ranges, + 0x0000, + cfg->pio.size - 1); + for (i = 0; i < crs_range_set.io_ranges->len; i++) { + entry = g_ptr_array_index(crs_range_set.io_ranges, i); + aml_append(rbuf, + aml_dword_io(AML_MIN_FIXED, AML_MAX_FIXED, AML_POS_DECODE, + AML_ENTIRE_RANGE, 0x0000, entry->base, + entry->limit, cfg->pio.base, + entry->limit - entry->base + 1)); + } } if (cfg->mmio64.size) { - aml_append(rbuf, - aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, - AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000, - cfg->mmio64.base, - cfg->mmio64.base + cfg->mmio64.size - 1, - 0x0000, - cfg->mmio64.size)); + crs_replace_with_free_ranges(crs_range_set.mem_64bit_ranges, + cfg->mmio64.base, + cfg->mmio64.base + cfg->mmio64.size - 1); + for (i = 0; i < crs_range_set.mem_64bit_ranges->len; i++) { + entry = g_ptr_array_index(crs_range_set.mem_64bit_ranges, i); + aml_append(rbuf, + aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, + AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000, + entry->base, + entry->limit, 0x0000, + entry->limit - entry->base + 1)); + } } aml_append(dev, aml_name_decl("_CRS", rbuf)); @@ -259,4 +279,6 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg) aml_append(dev_res0, aml_name_decl("_CRS", crs)); aml_append(dev, dev_res0); aml_append(scope, dev); + + crs_range_set_free(&crs_range_set); } -- cgit v1.1 From cc9346e4a9794a8db79a90119f64cdc87cf3e4bc Mon Sep 17 00:00:00 2001 From: Jiahui Cen Date: Thu, 14 Jan 2021 18:06:41 +0800 Subject: Kconfig: Compile PXB for ARM_VIRT PXB is now supported on ARM, so let's compile for arm_virt machine. Acked-by: Igor Mammedov Signed-off-by: Jiahui Cen Message-Id: <20210114100643.10617-7-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/pci-bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hw') diff --git a/hw/pci-bridge/Kconfig b/hw/pci-bridge/Kconfig index a51ec71..f8df431 100644 --- a/hw/pci-bridge/Kconfig +++ b/hw/pci-bridge/Kconfig @@ -5,7 +5,7 @@ config PCIE_PORT config PXB bool - default y if Q35 + default y if Q35 || ARM_VIRT config XIO3130 bool -- cgit v1.1