Re: [Qemu-devel] [PATCH for-2.11 0/5] qmp-shell non-interactive mode, delete scripts/qmp/qmp

[Eduardo Habkost]

On Sat, Aug 05, 2017 at 10:56:20PM +0800, Fam Zheng wrote:
> On Fri, 08/04 18:36, Eduardo Habkost wrote:
> > This series adds the ability to run QMP commands
> > non-interactively to qmp-shell, and deletes scripts/qmp/qmp.
> 
> Hmm, not so simple:
> 
> $ git grep 'import qmp'
> scripts/qemu.py:import qmp.qmp
> scripts/qmp/qemu-ga-client:import qmp
> scripts/qmp/qmp-shell:import qmp
> scripts/qtest.py:import qmp.qmp
> tests/migration/guestperf/engine.py:import qmp.qmp

I'm deleting scripts/qmp/qmp, not scripts/qmp/qmp.py.

-- 
Eduardo

[Qemu-devel] [PATCH v4 1/5] hw/i386: allow SHPC for Q35 machine

[Aleksandr Bezzubikov]

Unmask previously masked SHPC feature in _OSC method.

Signed-off-by: Aleksandr Bezzubikov 
Reviewed-by: Marcel Apfelbaum 
---
 hw/i386/acpi-build.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b9c245c..98dd424 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1862,9 +1862,9 @@ static Aml *build_q35_osc_method(void)
 
 /*
  * Always allow native PME, AER (no dependencies)
- * Never allow SHPC (no SHPC controller in this system)
+ * Allow SHPC (PCI bridges can have SHPC controller)
  */
-aml_append(if_ctx, aml_and(a_ctrl, aml_int(0x1D), a_ctrl));
+aml_append(if_ctx, aml_and(a_ctrl, aml_int(0x1F), a_ctrl));
 
 if_ctx2 = aml_if(aml_lnot(aml_equal(aml_arg(1), aml_int(1;
 /* Unknown revision */
-- 
2.7.4

[Qemu-devel] [PATCH v4 2/5] hw/pci: introduce pcie-pci-bridge device

[Aleksandr Bezzubikov]

Introduce a new PCIExpress-to-PCI Bridge device,
which is a hot-pluggable PCI Express device and
supports devices hot-plug with SHPC.

This device is intended to replace the DMI-to-PCI
Bridge in an overwhelming majority of use-cases.

Signed-off-by: Aleksandr Bezzubikov 
---
 hw/pci-bridge/Makefile.objs |   2 +-
 hw/pci-bridge/pcie_pci_bridge.c | 212 
 include/hw/pci/pci.h|   1 +
 3 files changed, 214 insertions(+), 1 deletion(-)
 create mode 100644 hw/pci-bridge/pcie_pci_bridge.c

diff --git a/hw/pci-bridge/Makefile.objs b/hw/pci-bridge/Makefile.objs
index c4683cf..666db37 100644
--- a/hw/pci-bridge/Makefile.objs
+++ b/hw/pci-bridge/Makefile.objs
@@ -1,4 +1,4 @@
-common-obj-y += pci_bridge_dev.o
+common-obj-y += pci_bridge_dev.o pcie_pci_bridge.o
 common-obj-$(CONFIG_PCIE_PORT) += pcie_root_port.o gen_pcie_root_port.o
 common-obj-$(CONFIG_PXB) += pci_expander_bridge.o
 common-obj-$(CONFIG_XIO3130) += xio3130_upstream.o xio3130_downstream.o
diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
new file mode 100644
index 000..4127725
--- /dev/null
+++ b/hw/pci-bridge/pcie_pci_bridge.c
@@ -0,0 +1,212 @@
+/*
+ * QEMU Generic PCIE-PCI Bridge
+ *
+ * Copyright (c) 2017 Aleksandr Bezzubikov
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/pci/pci.h"
+#include "hw/pci/pci_bus.h"
+#include "hw/pci/pci_bridge.h"
+#include "hw/pci/msi.h"
+#include "hw/pci/shpc.h"
+#include "hw/pci/slotid_cap.h"
+
+typedef struct PCIEPCIBridge {
+/*< private >*/
+PCIBridge parent_obj;
+
+OnOffAuto msi;
+MemoryRegion shpc_bar;
+/*< public >*/
+} PCIEPCIBridge;
+
+#define TYPE_PCIE_PCI_BRIDGE_DEV  "pcie-pci-bridge"
+#define PCIE_PCI_BRIDGE_DEV(obj) \
+OBJECT_CHECK(PCIEPCIBridge, (obj), TYPE_PCIE_PCI_BRIDGE_DEV)
+
+static void pcie_pci_bridge_realize(PCIDevice *d, Error **errp)
+{
+PCIBridge *br = PCI_BRIDGE(d);
+PCIEPCIBridge *pcie_br = PCIE_PCI_BRIDGE_DEV(d);
+int rc, pos;
+
+pci_bridge_initfn(d, TYPE_PCI_BUS);
+
+d->config[PCI_INTERRUPT_PIN] = 0x1;
+memory_region_init(_br->shpc_bar, OBJECT(d), "shpc-bar",
+   shpc_bar_size(d));
+rc = shpc_init(d, >sec_bus, _br->shpc_bar, 0, errp);
+if (rc) {
+goto error;
+}
+
+rc = pcie_cap_init(d, 0, PCI_EXP_TYPE_PCI_BRIDGE, 0, errp);
+if (rc < 0) {
+goto cap_error;
+}
+
+pos = pci_add_capability(d, PCI_CAP_ID_PM, 0, PCI_PM_SIZEOF, errp);
+if (pos < 0) {
+goto pm_error;
+}
+d->exp.pm_cap = pos;
+pci_set_word(d->config + pos + PCI_PM_PMC, 0x3);
+
+pcie_cap_arifwd_init(d);
+pcie_cap_deverr_init(d);
+
+rc = pcie_aer_init(d, PCI_ERR_VER, 0x100, PCI_ERR_SIZEOF, errp);
+if (rc < 0) {
+goto aer_error;
+}
+
+if (pcie_br->msi != ON_OFF_AUTO_OFF) {
+rc = msi_init(d, 0, 1, true, true, errp);
+if (rc < 0) {
+goto msi_error;
+}
+}
+pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_TYPE_64, _br->shpc_bar);
+return;
+
+msi_error:
+pcie_aer_exit(d);
+aer_error:
+pm_error:
+pcie_cap_exit(d);
+cap_error:
+shpc_free(d);
+error:
+pci_bridge_exitfn(d);
+}
+
+static void pcie_pci_bridge_exit(PCIDevice *d)
+{
+PCIEPCIBridge *bridge_dev = PCIE_PCI_BRIDGE_DEV(d);
+pcie_cap_exit(d);
+shpc_cleanup(d, _dev->shpc_bar);
+pci_bridge_exitfn(d);
+}
+
+static void pcie_pci_bridge_reset(DeviceState *qdev)
+{
+PCIDevice *d = PCI_DEVICE(qdev);
+pci_bridge_reset(qdev);
+msi_reset(d);
+shpc_reset(d);
+}
+
+static void pcie_pci_bridge_write_config(PCIDevice *d,
+uint32_t address, uint32_t val, int len)
+{
+pci_bridge_write_config(d, address, val, len);
+msi_write_config(d, address, val, len);
+

[Qemu-devel] [PATCH v4 0/5] Generic PCIE-PCI Bridge

[Aleksandr Bezzubikov]

This series introduces a new device - Generic PCI Express to PCI bridge,
and also makes all necessary changes to enable hotplug of the bridge itself
and any device into the bridge.

Changes v3->v4:
1. PCIE-PCI Bridge device: "msi_enable"->"msi", "shpc"->"shpc_bar", remove 
local_err,
   make "msi" property OnOffAuto, shpc_present() is still here 
   to avoid SHPC_VMSTATE refactoring (address Marcel's comments). 
2. Change QEMU PCI capability layout (SeaBIOS side has the same changes):
  - change reservation fields types: bus_res - uint32_t, others - uint64_t
  - rename 'non_pref' and 'pref' fields
  - interpret -1 value as 'ignore'
3. Use parent_realize in Generic PCI Express Root Port properly.
4. Fix documentation: fully replace the DMI-PCI bridge references with the new 
PCIE-PCI bridge,
"PCIE"->"PCI Express", small mistakes and typos - address Laszlo's and Marcel's 
comments.
5. Rename QEMU PCI cap creation fucntion - addresses Marcel's comment.

Changes v2->v3:
(0). 'do_not_use' capability field flag is still _not_ in here since we haven't 
come to consesus on it yet.
1. Merge commits 5 (bus_reserve property creation) and 6 (property usage) 
together - addresses Michael's comment.
2. Add 'bus_reserve' property and QEMU PCI capability only to Generic PCIE Root 
Port - addresses Michael's and Marcel's comments.
3. Change 'bus_reserve' property's default value to 0 - addresses Michael's 
comment.
4. Rename QEMU bridge-specific PCI capability creation function - addresses 
Michael's comment.
5. Init the whole QEMU PCI capability with zeroes - addresses Michael's and 
Laszlo's comments.
6. Change QEMU PCI capability layout (SeaBIOS side has the same changes)
  - add 'type' field to distinguish multiple 
RedHat-specific capabilities - addresses Michael's comment
  - do not mimiс PCI Config space register layout, but use mutually exclusive 
differently
sized fields for IO and prefetchable memory limits - addresses Laszlo's 
comment
7. Correct error handling in PCIE-PCI bridge realize function.
8. Replace a '2' constant with PCI_CAP_FLAGS in the capability creation 
function - addresses Michael's comment.
9. Remove a comment on _OSC which isn't correct anymore - address Marcel's 
comment.
10. Add documentation for the Generic PCIE-PCI Bridge and QEMU PCI capability - 
addresses Michael's comment.

Changes v1->v2:
1. Enable SHPC for the bridge.
2. Enable SHPC support for the Q35 machine (ACPI stuff).
3. Introduce PCI capability to help firmware on the system init.
   This allows the bridge to be hotpluggable. Now it's supported 
   only for pcie-root-port. Now it's supposed to used with 
   SeaBIOS only, look at the SeaBIOS corresponding series
   "Allow RedHat PCI bridges reserve more buses than necessary during init".

Aleksandr Bezzubikov (5):
  hw/i386: allow SHPC for Q35 machine
  hw/pci: introduce pcie-pci-bridge device
  hw/pci: introduce bridge-only vendor-specific capability to provide
some hints to firmware
  hw/pci: add QEMU-specific PCI capability to the Generic PCI Express
Root Port
  docs: update documentation considering PCIE-PCI bridge

 docs/pcie.txt  |  49 +
 docs/pcie_pci_bridge.txt   | 110 +++
 hw/i386/acpi-build.c   |   4 +-
 hw/pci-bridge/Makefile.objs|   2 +-
 hw/pci-bridge/gen_pcie_root_port.c |  33 ++
 hw/pci-bridge/pcie_pci_bridge.c| 212 +
 hw/pci/pci_bridge.c|  29 +
 include/hw/pci/pci.h   |   1 +
 include/hw/pci/pci_bridge.h|  21 
 include/hw/pci/pcie_port.h |   1 +
 10 files changed, 436 insertions(+), 26 deletions(-)
 create mode 100644 docs/pcie_pci_bridge.txt
 create mode 100644 hw/pci-bridge/pcie_pci_bridge.c

-- 
2.7.4

Re: [Qemu-devel] [PATCH v2 10/13] vvfat: correctly generate numeric-tail of short file names

[Pranith Kumar]

FYI,

This commit breaks the build with gcc-7:

  CC  block/vvfat.o
qemu/block/vvfat.c: In function ‘read_directory’:
qemu/block/vvfat.c:605:37: error: ‘__builtin___sprintf_chk’ may write
a terminating nul past the end of the destination
[-Werror=format-overflow=]
 int len = sprintf(tail, "~%d", i);
 ^
In file included from /usr/include/stdio.h:938:0,
 from qemu/include/qemu/osdep.h:68,
 from qemu/block/vvfat.c:25:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note:
‘__builtin___sprintf_chk’ output between 3 and 12 bytes into a
destination of size 11
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  ^~
   __bos (__s), __fmt, __va_arg_pack ());
   ~
cc1: all warnings being treated as errors
qemu/rules.mak:66: recipe for target 'block/vvfat.o' failed
make: *** [block/vvfat.o] Error 1


Thanks,

On Mon, May 22, 2017 at 5:12 PM, Hervé Poussineau  wrote:
> More specifically:
> - try without numeric-tail only if LFN didn't have invalid short chars
> - start at ~1 (instead of ~0)
> - handle case if numeric tail is more than one char (ie > 10)
>
> Windows 9x Scandisk doesn't see anymore mismatches between short file names 
> and
> long file names for non-ASCII filenames.
>
> Specification: "FAT: General overview of on-disk format" v1.03, page 31
> Signed-off-by: Hervé Poussineau 
> ---
>  block/vvfat.c | 62 
> ---
>  1 file changed, 29 insertions(+), 33 deletions(-)
>
> diff --git a/block/vvfat.c b/block/vvfat.c
> index 3cb65493cd..414bca6dee 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -529,7 +529,8 @@ static uint8_t to_valid_short_char(gunichar c)
>  }
>
>  static direntry_t *create_short_filename(BDRVVVFATState *s,
> - const char *filename)
> + const char *filename,
> + unsigned int directory_start)
>  {
>  int i, j = 0;
>  direntry_t *entry = array_get_next(&(s->directory));
> @@ -587,8 +588,32 @@ static direntry_t *create_short_filename(BDRVVVFATState 
> *s,
>  }
>  }
>  }
> -(void)lossy_conversion;
> -return entry;
> +
> +/* numeric-tail generation */
> +for (j = 0; j < 8; j++) {
> +if (entry->name[j] == ' ') {
> +break;
> +}
> +}
> +for (i = lossy_conversion ? 1 : 0; i < 99; i++) {
> +direntry_t *entry1;
> +if (i > 0) {
> +int len = sprintf(tail, "~%d", i);
> +memcpy(entry->name + MIN(j, 8 - len), tail, len);
> +}
> +for (entry1 = array_get(&(s->directory), directory_start);
> + entry1 < entry; entry1++) {
> +if (!is_long_name(entry1) &&
> +!memcmp(entry1->name, entry->name, 11)) {
> +break; /* found dupe */
> +}
> +}
> +if (entry1 == entry) {
> +/* no dupe found */
> +return entry;
> +}
> +}
> +return NULL;
>  }
>
>  /* fat functions */
> @@ -701,36 +726,7 @@ static inline direntry_t* 
> create_short_and_long_name(BDRVVVFATState* s,
>  }
>
>  entry_long=create_long_filename(s,filename);
> -entry = create_short_filename(s, filename);
> -
> -/* mangle duplicates */
> -while(1) {
> -direntry_t* entry1=array_get(&(s->directory),directory_start);
> -int j;
> -
> -for(;entry1 -if(!is_long_name(entry1) && !memcmp(entry1->name,entry->name,11))
> -break; /* found dupe */
> -if(entry1==entry) /* no dupe found */
> -break;
> -
> -/* use all 8 characters of name */
> -if(entry->name[7]==' ') {
> -int j;
> -for(j=6;j>0 && entry->name[j]==' ';j--)
> -entry->name[j]='~';
> -}
> -
> -/* increment number */
> -for(j=7;j>0 && entry->name[j]=='9';j--)
> -entry->name[j]='0';
> -if(j>0) {
> -if(entry->name[j]<'0' || entry->name[j]>'9')
> -entry->name[j]='0';
> -else
> -entry->name[j]++;
> -}
> -}
> +entry = create_short_filename(s, filename, directory_start);
>
>  /* calculate checksum; propagate to long name */
>  if(entry_long) {
> --
> 2.11.0
>
>

-- 
Pranith

Re: [Qemu-devel] [PATCH] pc/acpi: Fix booting of macOS with Clover EFI bootloader

[Laszlo Ersek]

On 08/05/17 13:46, Dhiru Kholia wrote:
> On Sat, Aug 5, 2017 at 2:00 PM, Dhiru Kholia  wrote:
>> On Fri, Aug 4, 2017 at 8:44 PM, Igor Mammedov  wrote:
>>> On Fri, 4 Aug 2017 16:17:07 +0530
>>> Dhiru Kholia  wrote:
>>>
 On Fri, Aug 4, 2017 at 2:35 PM, Igor Mammedov  wrote:
> On Fri,  4 Aug 2017 12:15:40 +0530
> Dhiru Kholia  wrote:
>
>> This was tested with macOS 10.12.5 and Clover r4114.
>>
>> Without this patch, the macOS boot process gets stuck at the Apple logo
>> without showing any progress bar.
>>
>> I have documented the process of running macOS on QEMU/KVM at,
>>
>> https://github.com/kholia/OSX-KVM/
>>
>> Instead of using this patch, adding an additional command-line knob
>> which exposes this setting (force_rev1_fadt) to the user might be a more
>> general solution.
>
> it's been reported that OVMF had issues that were fixed,
> you probably want to read this thread:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg468456.html

 Hi Igor,

 I have now tested various OVMF versions with the latest QEMU (commit
 aaaec6acad7c).

 When using edk2.git-ovmf-x64-0-20170726.b2826.gbb4831c03d.noarch.rpm
 from [1] macOS does not boot and gets stuck. The CPU usage goes to
 100%. I haven't confirmed this but this OVMF build should have both
 198a46d and 072060a edk2 commits in it, based on the build date.

 The OVMF blob from Gabriel Somlo [2] hangs on the OVMF logo screen and
 it too results in 100% CPU usage after hanging.

 I am using "boot-clover.sh" script from my repository [4] to test the
 various OVMF versions.

 The only OVMF blob which works with the current QEMU for booting macOS
 is the one from Proxmox [3]. Unfortunately, I don't know the
 corresponding commit in the edk2 repository for this working OVMF
 blob.
>>> So it's guest side issue, I'd prefer if it fixed there if possible
>>> instead of adding new CLI options to QEMU to work around issue.
>>>
>>> Added to CC BALATON Zoltan for whom updating OVMF fixed the problem,
>>> perhaps you'll be able to figure out what your setup is missing.
>>
>> I ran git bisect on OVMF repository [5] to find the commit that broke
>> booting of macOS + Clover combination in QEMU/KVM.
>>
>> It seems that commit 805762252733bb is problematic for some reason.
>> Reverting this commit fixes the macOS booting problem.
>>
>> In summary, I am able to boot macOS 10.12.5 + Clover combination with
>> latest OVMF (commit 1fceaddb12b with 805762252733bb reverted) +
>> updated QEMU (commit aaaec6acad7c with patch from this thread
>> applied).
> 
> After some more testing,
> 
> I am also able to boot macOS 10.12.5 + Clover combination with latest
> OVMF (commit 1fceaddb12b with 805762252733bb reverted) + updated QEMU
> (commit ac44ed2afb7c60 *without* my patch from this thread).

I don't know how edk2 commit 805762252733 ("OvmfPkg/AcpiPlatformDxe:
save fw_cfg boot script with QemuFwCfgS3Lib", 2017-02-23) can cause your
symptoms.

Let me give you some background on this commit. (See also
.)

The PI (Platform Init) spec defines a thing called "ACPI S3 Boot
Script", which is basically a simple / limited, opcode based script
language. (Think reading and writing memory or MMIO locations, reading
and writing IO ports, reading and writing PCI config space registers,
and such.) During normal boot, some DXE drivers (= platform drivers) in
the firmware configure low-level hardware, and they can "record" such
script fragments, to be replayed (executed) during S3 resume. The point
of this feature is that the S3 boot script is supposed to run in a lot
more limited environment (during S3 resume) than the full-blown DXE
("driver execution environment") where the normal boot time firmware
drivers run.

The commit you mention is (remotely) related to the WRITE_POINTER
command of QEMU's ACPI linker/loader. At normal boot, this linker/loader
command basically instructs the firmware to pass firmware-allocated
addresses back to QEMU. (The execution of a WRITE_POINTER command boils
down to "select", "skip" (= seek) and "write" fw_cfg DMA operations.)

Effectively a WRITE_POINTER command creates a guest RAM reference in
QEMU. Thus, when the guest is reset (and its memory contents are wholly
invalidated), QEMU forgets all these addresses.

Except, on S3 resume (which looks like a kind of reset to QEMU), the
guest memory contents remain valid / intact. Therefore the firmware has
to "replay" all WRITE_POINTER commands, in order to restore those guest
RAM references in QEMU.

In OvmfPkg, the DXE driver that handles WRITE_POINTER (among other
things) at normal boot is OvmfPkg/AcpiPlatformDxe. It also records an S3
boot script fragment so that at S3 resume, the WRITE_POINTER 

[Qemu-devel] [PATCH v4 3/3] pci: enable RedHat PCI bridges to reserve additional buses on PCI init

[Aleksandr Bezzubikov]

In case of Red Hat Generic PCIE Root Port reserve additional buses,
which number is provided in a vendor-specific capability.

Signed-off-by: Aleksandr Bezzubikov 
---
 src/fw/pciinit.c | 69 
 src/hw/pci_ids.h |  3 +++
 2 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 864954f..d241d66 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -15,6 +15,7 @@
 #include "hw/pcidevice.h" // pci_probe_devices
 #include "hw/pci_ids.h" // PCI_VENDOR_ID_INTEL
 #include "hw/pci_regs.h" // PCI_COMMAND
+#include "fw/dev-pci.h" // qemu_pci_cap
 #include "list.h" // struct hlist_node
 #include "malloc.h" // free
 #include "output.h" // dprintf
@@ -578,9 +579,42 @@ pci_bios_init_bus_rec(int bus, u8 *pci_bus)
 pci_bios_init_bus_rec(secbus, pci_bus);
 
 if (subbus != *pci_bus) {
+u8 res_bus = 0;
+if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
+pci_config_readw(bdf, PCI_DEVICE_ID) ==
+PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
+u8 cap;
+do {
+cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, 0);
+} while (cap &&
+ pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE) !=
+REDHAT_CAP_TYPE_QEMU);
+if (cap) {
+u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
+if (cap_len != QEMU_PCI_CAP_SIZE) {
+dprintf(1, "PCI: QEMU cap length %d is invalid\n",
+cap_len);
+} else {
+u32 tmp_res_bus = pci_config_readl(bdf,
+   cap + QEMU_PCI_CAP_BUS_RES);
+if (tmp_res_bus != (u32)-1) {
+res_bus = tmp_res_bus & 0xFF;
+if ((u8)(res_bus + secbus) < secbus ||
+(u8)(res_bus + secbus) < res_bus) {
+dprintf(1, "PCI: bus_reserve value %d is 
invalid\n",
+res_bus);
+res_bus = 0;
+}
+}
+}
+}
+res_bus = (*pci_bus > secbus + res_bus) ? *pci_bus
+  : secbus + res_bus;
+}
 dprintf(1, "PCI: subordinate bus = 0x%x -> 0x%x\n",
-subbus, *pci_bus);
-subbus = *pci_bus;
+subbus, res_bus);
+subbus = res_bus;
+*pci_bus = res_bus;
 } else {
 dprintf(1, "PCI: subordinate bus = 0x%x\n", subbus);
 }
@@ -951,11 +985,38 @@ pci_region_map_one_entry(struct pci_region_entry *entry, 
u64 addr)
 
 u16 bdf = entry->dev->bdf;
 u64 limit = addr + entry->size - 1;
+
+if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
+pci_config_readw(bdf, PCI_DEVICE_ID) ==
+PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
+u8 cap;
+do {
+cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, 0);
+} while (cap &&
+ pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE) !=
+REDHAT_CAP_TYPE_QEMU);
+if (cap) {
+u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
+if (cap_len != QEMU_PCI_CAP_SIZE) {
+dprintf(1, "PCI: QEMU cap length %d is invalid\n",
+cap_len);
+} else {
+u32 offset = cap + QEMU_PCI_CAP_LIMITS_OFFSET + entry->type * 
8;
+u64 tmp_limit = (pci_config_readl(bdf, offset) |
+(u64)pci_config_readl(bdf, offset + 4) << 32);
+if (tmp_limit != (u64)-1) {
+tmp_limit += addr - 1;
+limit = (limit > tmp_limit) ? limit : tmp_limit;
+}
+}
+}
+}
+
 if (entry->type == PCI_REGION_TYPE_IO) {
 pci_config_writeb(bdf, PCI_IO_BASE, addr >> PCI_IO_SHIFT);
-pci_config_writew(bdf, PCI_IO_BASE_UPPER16, 0);
+pci_config_writew(bdf, PCI_IO_BASE_UPPER16, limit >> 16);
 pci_config_writeb(bdf, PCI_IO_LIMIT, limit >> PCI_IO_SHIFT);
-pci_config_writew(bdf, PCI_IO_LIMIT_UPPER16, 0);
+pci_config_writew(bdf, PCI_IO_LIMIT_UPPER16, limit >> 16);
 }
 if (entry->type == PCI_REGION_TYPE_MEM) {
 pci_config_writew(bdf, PCI_MEMORY_BASE, addr >> PCI_MEMORY_SHIFT);
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 4ac73b4..38fa2ca 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2263,6 +2263,9 @@
 #define PCI_DEVICE_ID_KORENIX_JETCARDF00x1600
 #define 

Re: [Qemu-devel] [Qemu-arm] [PATCH 2/8] cpu: Define new cpu_transaction_failed() hook

[Peter Maydell]

On 5 August 2017 at 02:06, Edgar E. Iglesias  wrote:
> On Fri, Aug 04, 2017 at 06:20:43PM +0100, Peter Maydell wrote:
>> @@ -85,8 +85,10 @@ struct TranslationBlock;
>>   * @has_work: Callback for checking if there is work to do.
>>   * @do_interrupt: Callback for interrupt handling.
>>   * @do_unassigned_access: Callback for unassigned access handling.
>> + * (this is deprecated: new targets should use do_transaction_failed 
>> instead)
>>   * @do_unaligned_access: Callback for unaligned access handling, if
>>   * the target defines #ALIGNED_ONLY.
>> + * @do_transaction_failed: Callback for handling failed memory transactions
>
> Looks OK but I wonder if there you might want to clarify that this is a
> bus/slave failure and not a failure within the CPU (e.g not an MMU fault).

Yes, we could add
"(ie bus faults or external aborts; not MMU faults)"
just to clarify.

thanks
-- PMM

[Qemu-devel] [PATCH v4 4/5] hw/pci: add QEMU-specific PCI capability to the Generic PCI Express Root Port

[Aleksandr Bezzubikov]

To enable hotplugging of a newly created pcie-pci-bridge,
we need to tell firmware (SeaBIOS in this case) to reserve
additional buses or IO/MEM/PREF space for pcie-root-port.
Additional bus reservation allows us to hotplug pcie-pci-bridge into this root 
port.
The number of buses to reserve is provided to the device via a corresponding
property, and to the firmware via new PCI capability.
The properties' default value is -1 to keep default behavior unchanged.

Signed-off-by: Aleksandr Bezzubikov 
---
 hw/pci-bridge/gen_pcie_root_port.c | 33 +
 include/hw/pci/pcie_port.h |  1 +
 2 files changed, 34 insertions(+)

diff --git a/hw/pci-bridge/gen_pcie_root_port.c 
b/hw/pci-bridge/gen_pcie_root_port.c
index cb694d6..ff8d04c 100644
--- a/hw/pci-bridge/gen_pcie_root_port.c
+++ b/hw/pci-bridge/gen_pcie_root_port.c
@@ -16,6 +16,8 @@
 #include "hw/pci/pcie_port.h"
 
 #define TYPE_GEN_PCIE_ROOT_PORT"pcie-root-port"
+#define GEN_PCIE_ROOT_PORT(obj) \
+OBJECT_CHECK(GenPCIERootPort, (obj), TYPE_GEN_PCIE_ROOT_PORT)
 
 #define GEN_PCIE_ROOT_PORT_AER_OFFSET   0x100
 #define GEN_PCIE_ROOT_PORT_MSIX_NR_VECTOR   1
@@ -26,6 +28,12 @@ typedef struct GenPCIERootPort {
 /*< public >*/
 
 bool migrate_msix;
+
+/* additional buses to reserve on firmware init */
+uint32_t bus_reserve;
+uint64_t io_reserve;
+uint64_t mem_reserve;
+uint64_t pref_reserve;
 } GenPCIERootPort;
 
 static uint8_t gen_rp_aer_vector(const PCIDevice *d)
@@ -60,6 +68,23 @@ static bool gen_rp_test_migrate_msix(void *opaque, int 
version_id)
 return rp->migrate_msix;
 }
 
+static void gen_rp_realize(DeviceState *dev, Error **errp)
+{
+PCIDevice *d = PCI_DEVICE(dev);
+GenPCIERootPort *grp = GEN_PCIE_ROOT_PORT(d);
+PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(d);
+
+rpc->parent_realize(dev, errp);
+
+int rc = pci_bridge_qemu_reserve_cap_init(d, 0, grp->bus_reserve,
+grp->io_reserve, grp->mem_reserve, grp->pref_reserve, errp);
+
+if (rc < 0) {
+rpc->parent_class.exit(d);
+return;
+}
+}
+
 static const VMStateDescription vmstate_rp_dev = {
 .name = "pcie-root-port",
 .version_id = 1,
@@ -78,6 +103,10 @@ static const VMStateDescription vmstate_rp_dev = {
 
 static Property gen_rp_props[] = {
 DEFINE_PROP_BOOL("x-migrate-msix", GenPCIERootPort, migrate_msix, true),
+DEFINE_PROP_UINT32("bus-reserve", GenPCIERootPort, bus_reserve, -1),
+DEFINE_PROP_UINT64("io-reserve", GenPCIERootPort, io_reserve, -1),
+DEFINE_PROP_UINT64("mem-reserve", GenPCIERootPort, mem_reserve, -1),
+DEFINE_PROP_UINT64("pref-reserve", GenPCIERootPort, pref_reserve, -1),
 DEFINE_PROP_END_OF_LIST()
 };
 
@@ -92,6 +121,10 @@ static void gen_rp_dev_class_init(ObjectClass *klass, void 
*data)
 dc->desc = "PCI Express Root Port";
 dc->vmsd = _rp_dev;
 dc->props = gen_rp_props;
+
+rpc->parent_realize = dc->realize;
+dc->realize = gen_rp_realize;
+
 rpc->aer_vector = gen_rp_aer_vector;
 rpc->interrupts_init = gen_rp_interrupts_init;
 rpc->interrupts_uninit = gen_rp_interrupts_uninit;
diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
index 1333266..0736014 100644
--- a/include/hw/pci/pcie_port.h
+++ b/include/hw/pci/pcie_port.h
@@ -65,6 +65,7 @@ void pcie_chassis_del_slot(PCIESlot *s);
 
 typedef struct PCIERootPortClass {
 PCIDeviceClass parent_class;
+DeviceRealize parent_realize;
 
 uint8_t (*aer_vector)(const PCIDevice *dev);
 int (*interrupts_init)(PCIDevice *dev, Error **errp);
-- 
2.7.4

[Qemu-devel] [PATCH v4 3/5] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

[Aleksandr Bezzubikov]

On PCI init PCI bridges may need some extra info about bus number,
IO, memory and prefetchable memory to reserve. QEMU can provide this
with a special vendor-specific PCI capability.

Signed-off-by: Aleksandr Bezzubikov 
---
 hw/pci/pci_bridge.c | 29 +
 include/hw/pci/pci_bridge.h | 21 +
 2 files changed, 50 insertions(+)

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 720119b..889950d 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -408,6 +408,35 @@ void pci_bridge_map_irq(PCIBridge *br, const char* 
bus_name,
 br->bus_name = bus_name;
 }
 
+
+int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int cap_offset,
+  uint32_t bus_reserve, uint64_t io_reserve,
+  uint64_t non_pref_mem_reserve,
+  uint64_t pref_mem_reserve,
+  Error **errp)
+{
+size_t cap_len = sizeof(PCIBridgeQemuCap);
+PCIBridgeQemuCap cap = {
+.len = cap_len,
+.type = REDHAT_PCI_CAP_QEMU_RESERVE,
+.bus_res = bus_reserve,
+.io = io_reserve,
+.mem = non_pref_mem_reserve,
+.mem_pref = pref_mem_reserve
+};
+
+int offset = pci_add_capability(dev, PCI_CAP_ID_VNDR,
+cap_offset, cap_len, errp);
+if (offset < 0) {
+return offset;
+}
+
+memcpy(dev->config + offset + PCI_CAP_FLAGS,
+(char *) + PCI_CAP_FLAGS,
+cap_len - PCI_CAP_FLAGS);
+return 0;
+}
+
 static const TypeInfo pci_bridge_type_info = {
 .name = TYPE_PCI_BRIDGE,
 .parent = TYPE_PCI_DEVICE,
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ff7cbaa..be565f7 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -67,4 +67,25 @@ void pci_bridge_map_irq(PCIBridge *br, const char* bus_name,
 #define  PCI_BRIDGE_CTL_DISCARD_STATUS 0x400   /* Discard timer status */
 #define  PCI_BRIDGE_CTL_DISCARD_SERR   0x800   /* Discard timer SERR# enable */
 
+typedef struct PCIBridgeQemuCap {
+uint8_t id; /* Standard PCI capability header field */
+uint8_t next;   /* Standard PCI capability header field */
+uint8_t len;/* Standard PCI vendor-specific capability header field */
+uint8_t type;   /* Red Hat vendor-specific capability type.
+   Types are defined with REDHAT_PCI_CAP_ prefix */
+
+uint32_t bus_res;   /* Minimum number of buses to reserve */
+uint64_t io;/* IO space to reserve */
+uint64_t mem;   /* Non-prefetchable memory to reserve */
+uint64_t mem_pref;  /* Prefetchable memory to reserve */
+} PCIBridgeQemuCap;
+
+#define REDHAT_PCI_CAP_QEMU_RESERVE 1
+
+int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int cap_offset,
+  uint32_t bus_reserve, uint64_t io_reserve,
+  uint64_t non_pref_mem_reserve,
+  uint64_t pref_mem_reserve,
+  Error **errp);
+
 #endif /* QEMU_PCI_BRIDGE_H */
-- 
2.7.4

[Qemu-devel] [PATCH v4 5/5] docs: update documentation considering PCIE-PCI bridge

[Aleksandr Bezzubikov]

Signed-off-by: Aleksandr Bezzubikov 
---
 docs/pcie.txt|  49 +++--
 docs/pcie_pci_bridge.txt | 110 +++
 2 files changed, 136 insertions(+), 23 deletions(-)
 create mode 100644 docs/pcie_pci_bridge.txt

diff --git a/docs/pcie.txt b/docs/pcie.txt
index 5bada24..76b85ec 100644
--- a/docs/pcie.txt
+++ b/docs/pcie.txt
@@ -46,7 +46,7 @@ Place only the following kinds of devices directly on the 
Root Complex:
 (2) PCI Express Root Ports (ioh3420), for starting exclusively PCI Express
 hierarchies.
 
-(3) DMI-PCI Bridges (i82801b11-bridge), for starting legacy PCI
+(3) PCI Express to PCI Bridge (pcie-pci-bridge), for starting legacy PCI
 hierarchies.
 
 (4) Extra Root Complexes (pxb-pcie), if multiple PCI Express Root Buses
@@ -55,18 +55,18 @@ Place only the following kinds of devices directly on the 
Root Complex:
pcie.0 bus

 |||  |
-   ---   --   --   --
-   | PCI Dev |   | PCIe Root Port |   | DMI-PCI Bridge |   |  pxb-pcie  |
-   ---   --   --   --
+   ---   --   ---   --
+   | PCI Dev |   | PCIe Root Port |   | PCIe-PCI Bridge |   |  pxb-pcie  |
+   ---   --   ---   --
 
 2.1.1 To plug a device into pcie.0 as a Root Complex Integrated Endpoint use:
   -device [,bus=pcie.0]
 2.1.2 To expose a new PCI Express Root Bus use:
   -device pxb-pcie,id=pcie.1,bus_nr=x[,numa_node=y][,addr=z]
-  Only PCI Express Root Ports and DMI-PCI bridges can be connected
-  to the pcie.1 bus:
+  PCI Express Root Ports and PCI Express to PCI bridges can be
+  connected to the pcie.1 bus:
   -device 
ioh3420,id=root_port1[,bus=pcie.1][,chassis=x][,slot=y][,addr=z]
 \
-  -device i82801b11-bridge,id=dmi_pci_bridge1,bus=pcie.1
+  -device pcie-pci-bridge,id=pcie_pci_bridge1,bus=pcie.1
 
 
 2.2 PCI Express only hierarchy
@@ -130,24 +130,24 @@ Notes:
 Legacy PCI devices can be plugged into pcie.0 as Integrated Endpoints,
 but, as mentioned in section 5, doing so means the legacy PCI
 device in question will be incapable of hot-unplugging.
-Besides that use DMI-PCI Bridges (i82801b11-bridge) in combination
-with PCI-PCI Bridges (pci-bridge) to start PCI hierarchies.
+Besides that use PCI Express to PCI Bridges (pcie-pci-bridge) in
+combination with PCI-PCI Bridges (pci-bridge) to start PCI hierarchies.
 
-Prefer flat hierarchies. For most scenarios a single DMI-PCI Bridge
+Prefer flat hierarchies. For most scenarios a single PCI Express to PCI Bridge
 (having 32 slots) and several PCI-PCI Bridges attached to it
 (each supporting also 32 slots) will support hundreds of legacy devices.
-The recommendation is to populate one PCI-PCI Bridge under the DMI-PCI Bridge
-until is full and then plug a new PCI-PCI Bridge...
+The recommendation is to populate one PCI-PCI Bridge under the
+PCI Express to PCI Bridge until is full and then plug a new PCI-PCI Bridge...
 
pcie.0 bus
--
 ||
-   ---   --
-   | PCI Dev |   | DMI-PCI BRIDGE |
-   ----
+   ---   ---
+   | PCI Dev |   | PCIe-PCI Bridge |
+   ---   ---
||
   ----
-  | PCI-PCI Bridge || PCI-PCI Bridge |   ...
+  | PCI-PCI Bridge || PCI-PCI Bridge |
   ----
  |   |
   --- ---
@@ -157,11 +157,11 @@ until is full and then plug a new PCI-PCI Bridge...
 2.3.1 To plug a PCI device into pcie.0 as an Integrated Endpoint use:
   -device [,bus=pcie.0]
 2.3.2 Plugging a PCI device into a PCI-PCI Bridge:
-  -device i82801b11-bridge,id=dmi_pci_bridge1[,bus=pcie.0] 
   \
-  -device 
pci-bridge,id=pci_bridge1,bus=dmi_pci_bridge1[,chassis_nr=x][,addr=y]   \
+  -device pcie-pci-bridge,id=pcie_pci_bridge1[,bus=pcie.0] \
+  -device 
pci-bridge,id=pci_bridge1,bus=pcie_pci_bridge1[,chassis_nr=x][,addr=y] \
   -device ,bus=pci_bridge1[,addr=x]
   Note that 'addr' cannot be 0 unless shpc=off parameter is passed to
-  the PCI Bridge.
+  the PCI Bridge/PCI Express to PCI Bridge.
 
 3. IO space issues
 ===
@@ -219,14 +219,16 @@ do not support hot-plug, so 

Re: [Qemu-devel] [Qemu-arm] [PATCH 2/8] cpu: Define new cpu_transaction_failed() hook

[Peter Maydell]

On 5 August 2017 at 02:12, Edgar E. Iglesias  wrote:
> BTW, a question. I don't know of any from memory but does any arch
> have the ability to report the payload that failed for stores?
> I guess it's easy enough to add that if needed though.

I think maybe m68k bus fault stack frames have
store payload data? The description of them is pretty
complicated though and I'm not sure how much of the
frame is "stuff we actually need to emulate" vs "data
that's only important if your implementation pipelines
instruction execution"...

As you say, we can easily add a 'uint64_t data' (only valid
when access_type == MMU_DATA_STORE), either now or later.

thanks
-- PMM

[Qemu-devel] [PATCH v4 0/3] Allow RedHat PCI bridges reserve more buses than necessary during init

[Aleksandr Bezzubikov]

Now PCI bridges get a bus range number on a system init,
basing on currently plugged devices. That's why when one wants to hotplug 
another bridge,
it needs his child bus, which the parent is unable to provide (speaking about 
virtual device).
The suggested workaround is to have vendor-specific capability in Red Hat PCI 
bridges
that contains number of additional bus to reserve (as well as IO/MEM/PREF space 
limit hints) 
on BIOS PCI init.
So this capability is intented only for pure QEMU->SeaBIOS usage.

Considering all aforesaid, this series is directly connected with
QEMU series "Generic PCIE-PCI Bridge".

Although the new PCI capability is supposed to contain various limits along with
bus number to reserve, now only its full layout is proposed. And
only bus_reserve field is used in QEMU and BIOS. Limits usage
is still a subject for implementation as now
the main goal of this series to provide necessary support from the 
firmware side to PCIE-PCI bridge hotplug. 

Changes v3->v4:
1. Use all QEMU PCI capability fields - addresses Michael's comment
2. Changes of the capability layout (QEMU side has the same changes):
- change reservation fields types: bus_res - uint32_t, others - uint64_t
- interpret -1 value as 'ignore'

Changes v2->v3:
1. Merge commit 2 (Red Hat vendor ID) into commit 4 - addresses Marcel's 
comment,
and add Generic PCIE Root Port device ID - addresses Michael's comment.
2. Changes of the capability layout  (QEMU side has the same changes):
- add 'type' field to distinguish multiple 
RedHat-specific capabilities - addresses Michael's comment
- do not mimiс PCI Config space register layout, but use mutually 
exclusive differently
sized fields for IO and prefetchable memory limits - addresses 
Laszlo's comment
- use defines instead of structure and offsetof - addresses Michael's 
comment
3. Interpret 'bus_reserve' field as a minimum necessary
 range to reserve - addresses Gerd's comment
4. pci_find_capability moved to pci.c - addresses Kevin's comment
5. Move capability layout header to src/fw/dev-pci.h - addresses Kevin's comment
6. Add the capability documentation - addresses Michael's comment
7. Add capability length and bus_reserve field sanity checks - addresses 
Michael's comment

Changes v1->v2:
1. New #define for Red Hat vendor added (addresses Konrad's comment).
2. Refactored pci_find_capability function (addresses Marcel's comment).
3. Capability reworked:
- data type added;
- reserve space in a structure for IO, memory and 
  prefetchable memory limits.

Aleksandr Bezzubikov (3):
  pci: refactor pci_find_capapibilty to get bdf as the first argument
instead of the whole pci_device
  pci: add QEMU-specific PCI capability structure
  pci: enable RedHat PCI bridges to reserve additional buses on PCI init

 src/fw/dev-pci.h| 50 
 src/fw/pciinit.c| 73 -
 src/hw/pci.c| 25 ++
 src/hw/pci.h|  1 +
 src/hw/pci_ids.h|  3 +++
 src/hw/pcidevice.c  | 24 --
 src/hw/pcidevice.h  |  1 -
 src/hw/virtio-pci.c |  6 ++---
 8 files changed, 149 insertions(+), 34 deletions(-)
 create mode 100644 src/fw/dev-pci.h

-- 
2.7.4

[Qemu-devel] [PATCH v4 2/3] pci: add QEMU-specific PCI capability structure

[Aleksandr Bezzubikov]

On PCI init PCI bridge devices may need some
extra info about bus number to reserve, IO, memory and
prefetchable memory limits. QEMU can provide this
with special vendor-specific PCI capability.

This capability is intended to be used only
for Red Hat PCI bridges, i.e. QEMU cooperation.

Signed-off-by: Aleksandr Bezzubikov 
---
 src/fw/dev-pci.h | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 src/fw/dev-pci.h

diff --git a/src/fw/dev-pci.h b/src/fw/dev-pci.h
new file mode 100644
index 000..2c8ddb0
--- /dev/null
+++ b/src/fw/dev-pci.h
@@ -0,0 +1,50 @@
+#ifndef _PCI_CAP_H
+#define _PCI_CAP_H
+
+#include "types.h"
+
+/*
+
+QEMU-specific vendor(Red Hat)-specific capability.
+It's intended to provide some hints for firmware to init PCI devices.
+
+Its structure is shown below:
+
+Header:
+
+u8 id;   Standard PCI Capability Header field
+u8 next; Standard PCI Capability Header field
+u8 len;  Standard PCI Capability Header field
+u8 type; Red Hat vendor-specific capability type:
+   now only REDHAT_CAP_TYP_QEMU=1 exists
+Data:
+
+u32 bus_res;minimum bus number to reserve;
+this is necessary for PCI Express Root Ports
+to support PCIE-to-PCI bridge hotplug
+u64 io; IO space to reserve
+u64 mem;non-prefetchable memory space to reserve
+u64 prefetchable_mem;   prefetchable memory space to reserve
+
+If any field value in Data section is -1,
+it means that such kind of reservation
+is not needed and must be ignored.
+
+*/
+
+/* Offset of vendor-specific capability type field */
+#define PCI_CAP_REDHAT_TYPE  3
+
+/* List of valid Red Hat vendor-specific capability types */
+#define REDHAT_CAP_TYPE_QEMU1
+
+
+/* Offsets of QEMU capability fields */
+#define QEMU_PCI_CAP_BUS_RES4
+#define QEMU_PCI_CAP_LIMITS_OFFSET  8
+#define QEMU_PCI_CAP_IO 8
+#define QEMU_PCI_CAP_MEM16
+#define QEMU_PCI_CAP_PREF_MEM   24
+#define QEMU_PCI_CAP_SIZE   32
+
+#endif /* _PCI_CAP_H */
-- 
2.7.4

Re: [Qemu-devel] [PATCH v3] build-sys: add --disable-vhost-user

[Thomas Huth]

On 03.08.2017 11:07, Marc-André Lureau wrote:
> Learn to compile out vhost-user (net, scsi & upcoming users). Keep it
> enabled by default on non-win32, that is assumed to be POSIX. Fail if
> trying to enable it on win32.
> 
> When trying to make a vhost-user netdev, it gives the following error:
> 
> -netdev vhost-user,id=foo,chardev=chr-test: Parameter 'type' expects a netdev 
> backend type
> 
> And similar error with the HMP/QMP monitors.
> 
> While at it, rename CONFIG_VHOST_NET_TEST CONFIG_VHOST_USER_NET_TEST
> since it's a vhost-user specific variable.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  hw/virtio/virtio-pci.c|  4 ++--
>  configure | 28 ++--
>  default-configs/pci.mak   |  2 +-
>  default-configs/s390x-softmmu.mak |  2 +-
>  tests/Makefile.include|  6 +++---
>  5 files changed, 33 insertions(+), 9 deletions(-)
> 
> v3:
> - user error_exit in configure
> - drop patch to compile out net/vhost-user.c
> 
> v2:
> - remove some #ifdef, reuse CONFIG_VHOST_NET_USED
> - split the patch to have net/vhost-user.c compiled out (adding 2 ifdefs)
> - fail if --enable-vhost-user on win32
> 
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 5d14bd66dc..8b0d6b69cd 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2135,7 +2135,7 @@ static const TypeInfo vhost_scsi_pci_info = {
>  };
>  #endif
>  
> -#ifdef CONFIG_LINUX
> +#if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
>  /* vhost-user-scsi-pci */
>  static Property vhost_user_scsi_pci_properties[] = {
>  DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
> @@ -2665,7 +2665,7 @@ static void virtio_pci_register_types(void)
>  #ifdef CONFIG_VHOST_SCSI
>  type_register_static(_scsi_pci_info);
>  #endif
> -#ifdef CONFIG_LINUX
> +#if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
>  type_register_static(_user_scsi_pci_info);
>  #endif
>  #ifdef CONFIG_VHOST_VSOCK
> diff --git a/configure b/configure
> index 987f59ba88..dd73cce62f 100755
> --- a/configure
> +++ b/configure
> @@ -306,6 +306,7 @@ tcg="yes"
>  vhost_net="no"
>  vhost_scsi="no"
>  vhost_vsock="no"
> +vhost_user=""
>  kvm="no"
>  hax="no"
>  rdma=""
> @@ -1282,6 +1283,14 @@ for opt do
>;;
>--enable-vxhs) vxhs="yes"
>;;
> +  --disable-vhost-user) vhost_user="no"
> +  ;;
> +  --enable-vhost-user)
> +  vhost_user="yes"
> +  if test "$mingw32" = "yes"; then
> +  error_exit "vhost-user isn't available on win32"
> +  fi
> +  ;;
>*)
>echo "ERROR: unknown option $opt"
>echo "Try '$0 --help' for more information"
> @@ -1290,6 +1299,14 @@ for opt do
>esac
>  done
>  
> +if test "$vhost_user" = ""; then
> +if test "$mingw32" = "yes"; then
> +vhost_user="no"
> +else
> +vhost_user="yes"
> +fi
> +fi
> +
>  case "$cpu" in
>  ppc)
> CPU_CFLAGS="-m32"
> @@ -1518,6 +1535,7 @@ disabled with --disable-FEATURE, default is enabled if 
> available:
>tools   build qemu-io, qemu-nbd and qemu-image tools
>vxhsVeritas HyperScale vDisk backend support
>crypto-afalgLinux AF_ALG crypto backend driver
> +  vhost-user  vhost-user support
>  
>  NOTE: The object files are built at the place where configure is launched
>  EOF
> @@ -5348,6 +5366,7 @@ echo "libcap-ng support $cap_ng"
>  echo "vhost-net support $vhost_net"
>  echo "vhost-scsi support $vhost_scsi"
>  echo "vhost-vsock support $vhost_vsock"
> +echo "vhost-user support $vhost_user"
>  echo "Trace backends$trace_backends"
>  if have_backend "simple"; then
>  echo "Trace output file $trace_file-"
> @@ -5757,12 +5776,15 @@ fi
>  if test "$vhost_scsi" = "yes" ; then
>echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
>  fi
> -if test "$vhost_net" = "yes" ; then
> +if test "$vhost_net" = "yes" -a "$vhost_user" = "yes"; then
>echo "CONFIG_VHOST_NET_USED=y" >> $config_host_mak
>  fi
>  if test "$vhost_vsock" = "yes" ; then
>echo "CONFIG_VHOST_VSOCK=y" >> $config_host_mak
>  fi
> +if test "$vhost_user" = "yes" ; then
> +  echo "CONFIG_VHOST_USER=y" >> $config_host_mak
> +fi
>  if test "$blobs" = "yes" ; then
>echo "INSTALL_BLOBS=yes" >> $config_host_mak
>  fi
> @@ -6358,7 +6380,9 @@ if supported_kvm_target $target; then
>  echo "CONFIG_KVM=y" >> $config_target_mak
>  if test "$vhost_net" = "yes" ; then
>  echo "CONFIG_VHOST_NET=y" >> $config_target_mak
> -echo "CONFIG_VHOST_NET_TEST_$target_name=y" >> $config_host_mak
> +if test "$vhost_user" = "yes" ; then
> +echo "CONFIG_VHOST_USER_NET_TEST_$target_name=y" >> 
> $config_host_mak
> +fi
>  fi
>  fi
>  if supported_hax_target $target; then
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index acaa70301a..a758630d30 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -43,4 +43,4 @@ CONFIG_VGA=y
>  

Re: [Qemu-devel] [PATCH] pc/acpi: Fix booting of macOS with Clover EFI bootloader

[Dhiru Kholia]

On Fri, Aug 4, 2017 at 8:44 PM, Igor Mammedov  wrote:
> On Fri, 4 Aug 2017 16:17:07 +0530
> Dhiru Kholia  wrote:
>
>> On Fri, Aug 4, 2017 at 2:35 PM, Igor Mammedov  wrote:
>> > On Fri,  4 Aug 2017 12:15:40 +0530
>> > Dhiru Kholia  wrote:
>> >
>> >> This was tested with macOS 10.12.5 and Clover r4114.
>> >>
>> >> Without this patch, the macOS boot process gets stuck at the Apple logo
>> >> without showing any progress bar.
>> >>
>> >> I have documented the process of running macOS on QEMU/KVM at,
>> >>
>> >> https://github.com/kholia/OSX-KVM/
>> >>
>> >> Instead of using this patch, adding an additional command-line knob
>> >> which exposes this setting (force_rev1_fadt) to the user might be a more
>> >> general solution.
>> >
>> > it's been reported that OVMF had issues that were fixed,
>> > you probably want to read this thread:
>> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg468456.html
>>
>> Hi Igor,
>>
>> I have now tested various OVMF versions with the latest QEMU (commit
>> aaaec6acad7c).
>>
>> When using edk2.git-ovmf-x64-0-20170726.b2826.gbb4831c03d.noarch.rpm
>> from [1] macOS does not boot and gets stuck. The CPU usage goes to
>> 100%. I haven't confirmed this but this OVMF build should have both
>> 198a46d and 072060a edk2 commits in it, based on the build date.
>>
>> The OVMF blob from Gabriel Somlo [2] hangs on the OVMF logo screen and
>> it too results in 100% CPU usage after hanging.
>>
>> I am using "boot-clover.sh" script from my repository [4] to test the
>> various OVMF versions.
>>
>> The only OVMF blob which works with the current QEMU for booting macOS
>> is the one from Proxmox [3]. Unfortunately, I don't know the
>> corresponding commit in the edk2 repository for this working OVMF
>> blob.
> So it's guest side issue, I'd prefer if it fixed there if possible
> instead of adding new CLI options to QEMU to work around issue.
>
> Added to CC BALATON Zoltan for whom updating OVMF fixed the problem,
> perhaps you'll be able to figure out what your setup is missing.

I ran git bisect on OVMF repository [5] to find the commit that broke
booting of macOS + Clover combination in QEMU/KVM.

It seems that commit 805762252733bb is problematic for some reason.
Reverting this commit fixes the macOS booting problem.

In summary, I am able to boot macOS 10.12.5 + Clover combination with
latest OVMF (commit 1fceaddb12b with 805762252733bb reverted) +
updated QEMU (commit aaaec6acad7c with patch from this thread
applied).

I don't know what commit 805762252733bb does yet but I will look at it
again. I am CC'ing Laszlo Ersek, the author of this OVMF commit.

[5] https://github.com/tianocore/edk2

Thanks,
Dhiru

>> References,
>>
>> [1] https://www.kraxel.org/repos/jenkins/edk2/
>>
>> [2] https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
>>
>> [3] https://git.proxmox.com/?p=pve-qemu-kvm.git;a=tree;f=debian
>>
>> [4] https://github.com/kholia/OSX-KVM/

Re: [Qemu-devel] [Qemu-arm] [PATCH 4/8] boards.h: Define new flag ignore_memory_transaction_failures

[Peter Maydell]

On 4 August 2017 at 20:23, Richard Henderson
 wrote:
> On 08/04/2017 11:09 AM, Philippe Mathieu-Daudé wrote:
>> Since create_unimplemented_device() register overlapped with low priority, 
>> why
>> not register it as default device directly, over the whole address space?
>
> That's a good suggestion.  It makes more sense to me than adding a flag on the
> MachineClass.

Yeah, I did think about implementing it that way, but...

That wouldn't handle the case of a device model directly
returning a MEMTX_ERROR, or a transaction dispatched to
a memory region whose MemoryRegionOps valid settings
prohibit it (eg byte accesses to a word-access-only device),
or accesses to a MemoryRegion that was created by passing
a NULL MemoryRegionOps pointer to memory_region_init_io
(I dunno why you'd do that but some code does).

In short, there are lots of ways the memory subsystem might
end up returning a transaction error -- this mechanism
ensures that none of them start generating exceptions
when they previously did not, and is (I hope) easy to
review in the sense of being sure that it does what it
intends to do without the need to audit a lot of corner
cases.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-arm] [PATCH 4/8] boards.h: Define new flag ignore_memory_transaction_failures

[Peter Maydell]

On 4 August 2017 at 19:09, Philippe Mathieu-Daudé  wrote:
> On 08/04/2017 02:20 PM, Peter Maydell wrote:
>> We need this for ARM boards, where we're about to implement support for
>> generating external aborts on memory transaction failures. Too many
>> of our legacy board models rely on the RAZ/WI behaviour and we
>> would break currently working guests when their "probe for device"
>> code provoked an external abort rather than a RAZ.

> I think some firmware will give some surprises, those probing device is not
> here and expect RAZ/WI. I remember some fw probing PCI space, or enumerating
> CS this way for ex.

PCI space is funny anyway because IIRC the PCI spec mandates
RAZ/WI (which is handled by QEMU's PCI implementation I think,
it doesn't fall out to the memory system's unmapped-address
handling).

That said: yes, possibly some guest code really wants the fault
(indeed the motivation for this patchset was having some test
guest code which wanted to see the faults), but that guest code
won't work on QEMU today, so if it doesn't boot on QEMU with
this patchsets that's not a regression. We can then (as the
issue arises) look at fixing whatever particular board model
it is to properly model or stub out all its devices so we
can boot that guest code without breaking existing working
guest code.

> RAZ/WI is a bus-feature, this is also bus-dependent to reply with abort or
> behave RAZ/WI. Maybe the effort should be done on how model/use buses in
> QEMU? Bus device would be an alias of unimplemented_device, which current
> purpose is more debugging than avoiding unassigned physical access aborts.

You can model this kind of bus-dependent behaviour by having
the bus register a background region which implements the
default behaviour that is desired. (That way accesses to
that part of the address space don't ever respond with
a transaction error, which is what's happening on hardware
where the bus doesn't report errors.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] pc/acpi: Fix booting of macOS with Clover EFI bootloader

[Dhiru Kholia]

On Sat, Aug 5, 2017 at 2:00 PM, Dhiru Kholia  wrote:
> On Fri, Aug 4, 2017 at 8:44 PM, Igor Mammedov  wrote:
>> On Fri, 4 Aug 2017 16:17:07 +0530
>> Dhiru Kholia  wrote:
>>
>>> On Fri, Aug 4, 2017 at 2:35 PM, Igor Mammedov  wrote:
>>> > On Fri,  4 Aug 2017 12:15:40 +0530
>>> > Dhiru Kholia  wrote:
>>> >
>>> >> This was tested with macOS 10.12.5 and Clover r4114.
>>> >>
>>> >> Without this patch, the macOS boot process gets stuck at the Apple logo
>>> >> without showing any progress bar.
>>> >>
>>> >> I have documented the process of running macOS on QEMU/KVM at,
>>> >>
>>> >> https://github.com/kholia/OSX-KVM/
>>> >>
>>> >> Instead of using this patch, adding an additional command-line knob
>>> >> which exposes this setting (force_rev1_fadt) to the user might be a more
>>> >> general solution.
>>> >
>>> > it's been reported that OVMF had issues that were fixed,
>>> > you probably want to read this thread:
>>> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg468456.html
>>>
>>> Hi Igor,
>>>
>>> I have now tested various OVMF versions with the latest QEMU (commit
>>> aaaec6acad7c).
>>>
>>> When using edk2.git-ovmf-x64-0-20170726.b2826.gbb4831c03d.noarch.rpm
>>> from [1] macOS does not boot and gets stuck. The CPU usage goes to
>>> 100%. I haven't confirmed this but this OVMF build should have both
>>> 198a46d and 072060a edk2 commits in it, based on the build date.
>>>
>>> The OVMF blob from Gabriel Somlo [2] hangs on the OVMF logo screen and
>>> it too results in 100% CPU usage after hanging.
>>>
>>> I am using "boot-clover.sh" script from my repository [4] to test the
>>> various OVMF versions.
>>>
>>> The only OVMF blob which works with the current QEMU for booting macOS
>>> is the one from Proxmox [3]. Unfortunately, I don't know the
>>> corresponding commit in the edk2 repository for this working OVMF
>>> blob.
>> So it's guest side issue, I'd prefer if it fixed there if possible
>> instead of adding new CLI options to QEMU to work around issue.
>>
>> Added to CC BALATON Zoltan for whom updating OVMF fixed the problem,
>> perhaps you'll be able to figure out what your setup is missing.
>
> I ran git bisect on OVMF repository [5] to find the commit that broke
> booting of macOS + Clover combination in QEMU/KVM.
>
> It seems that commit 805762252733bb is problematic for some reason.
> Reverting this commit fixes the macOS booting problem.
>
> In summary, I am able to boot macOS 10.12.5 + Clover combination with
> latest OVMF (commit 1fceaddb12b with 805762252733bb reverted) +
> updated QEMU (commit aaaec6acad7c with patch from this thread
> applied).

After some more testing,

I am also able to boot macOS 10.12.5 + Clover combination with latest
OVMF (commit 1fceaddb12b with 805762252733bb reverted) + updated QEMU
(commit ac44ed2afb7c60 *without* my patch from this thread).

However, macOS 10.12.5 + older Proxmox OVMF blob doesn't boot with the
same QEMU version without my patch from this thread.

Overall, exposing this (force_rev1_fadt) setting to the user to might
be necessary if maintaining compatibility with older OVMF blobs is
required.

It would be great if someone else could reproduce my results, and
ensure that they are correct.

Thanks,
Dhiru

> I don't know what commit 805762252733bb does yet but I will look at it
> again. I am CC'ing Laszlo Ersek, the author of this OVMF commit.
>
> [5] https://github.com/tianocore/edk2
>
>>> References,
>>>
>>> [1] https://www.kraxel.org/repos/jenkins/edk2/
>>>
>>> [2] https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
>>>
>>> [3] https://git.proxmox.com/?p=pve-qemu-kvm.git;a=tree;f=debian
>>>
>>> [4] https://github.com/kholia/OSX-KVM/

Re: [Qemu-devel] [PATCH for-2.11 0/5] qmp-shell non-interactive mode, delete scripts/qmp/qmp

[Fam Zheng]

On Fri, 08/04 18:36, Eduardo Habkost wrote:
> This series adds the ability to run QMP commands
> non-interactively to qmp-shell, and deletes scripts/qmp/qmp.

Hmm, not so simple:

$ git grep 'import qmp'
scripts/qemu.py:import qmp.qmp
scripts/qmp/qemu-ga-client:import qmp
scripts/qmp/qmp-shell:import qmp
scripts/qtest.py:import qmp.qmp
tests/migration/guestperf/engine.py:import qmp.qmp

Fam