[Qemu-devel] [PATCH qemu v3] spapr_pci: Advertise BAR reallocation capability

[Alexey Kardashevskiy]

The pseries guests do not normally allocate PCI resources and rely on
the system firmware doing so. Furthermore at least at some point in
the past the pseries guests won't even allowed to change BARs, probably
it is still the case for phyp. So since the initial commit we have [1]
which prevents resource reallocation.

This is not a problem until we want specific BAR alignments, for example,
PAGE_SIZE==64k to make sure we can still map MMIO BARs directly. For
the boot time devices we handle this in SLOF [2] but since QEMU's RTAS
does not allocate BARs, the guest does this instead and does not align
BARs even if Linux is given pci=resource_alignment=16@pci:0:0 as
PCI_PROBE_ONLY makes Linux ignore alignment requests.

ARM folks added a dial to control PCI_PROBE_ONLY via the device tree [3].
This makes use of the dial to advertise to the guest that we can handle
BAR reassignments. This limits the change to the latest pseries machine
to avoid old guests explosion.

We do not remove the flag from [1] as pseries guests are still supported
under phyp so having that removed may cause problems.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/pseries/setup.c?h=v5.1#n773
[2] 
https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/pci-phb.fs;h=06729bcf77a0d4e900c527adcd9befe2a269f65d;hb=HEAD#l338
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f81c11af
Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v3:
* moved the default setting to spapr_machine_class_init()

v2:
* limited the change by a machine version
---
 include/hw/ppc/spapr.h | 1 +
 hw/ppc/spapr.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index c79bc6a1232b..ebbd92673b34 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -121,6 +121,7 @@ struct SpaprMachineClass {
 bool legacy_irq_allocation;
 bool broken_host_serial_model; /* present real host info to the guest */
 bool pre_4_1_migration; /* don't migrate hpt-max-page-size */
+bool linux_pci_probe;
 
 void (*phb_placement)(SpaprMachineState *spapr, uint32_t index,
   uint64_t *buid, hwaddr *pio, 
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 2ee671e55e0c..4bff0cf90d4b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1164,6 +1164,7 @@ static void 
spapr_dt_ov5_platform_support(SpaprMachineState *spapr, void *fdt,
 static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt)
 {
 MachineState *machine = MACHINE(spapr);
+SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
 int chosen;
 const char *boot_device = machine->boot_order;
 char *stdout_path = spapr_vio_stdout_path(spapr->vio_bus);
@@ -1221,6 +1222,11 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, 
void *fdt)
 _FDT(fdt_setprop_string(fdt, chosen, "stdout-path", stdout_path));
 }
 
+/* We can deal with BAR reallocation just fine, advertise it to the guest 
*/
+if (smc->linux_pci_probe) {
+_FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0));
+}
+
 spapr_dt_ov5_platform_support(spapr, fdt, chosen);
 
 g_free(stdout_path);
@@ -4467,6 +4473,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 spapr_caps_add_properties(smc, _abort);
 smc->irq = _irq_dual;
 smc->dr_phb_enabled = true;
+smc->linux_pci_probe = true;
 }
 
 static const TypeInfo spapr_machine_info = {
@@ -4526,12 +4533,14 @@ DEFINE_SPAPR_MACHINE(4_2, "4.2", true);
  */
 static void spapr_machine_4_1_class_options(MachineClass *mc)
 {
+SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
 static GlobalProperty compat[] = {
 /* Only allow 4kiB and 64kiB IOMMU pagesizes */
 { TYPE_SPAPR_PCI_HOST_BRIDGE, "pgsz", "0x11000" },
 };
 
 spapr_machine_4_2_class_options(mc);
+smc->linux_pci_probe = false;
 compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
 }
 
-- 
2.17.1

Re: [Qemu-devel] [GIT PULL for qemu-pseries REPOST] pseries: Update SLOF firmware image

[David Gibson]

On Fri, Jul 19, 2019 at 12:45:55PM +1000, Alexey Kardashevskiy wrote:
> I messed up with my local git so reposting.
> 
> The following changes since commit 216965b20b04fbf74e0ce3a3175a9171dba210de:
> 
>   ppc/pnv: update skiboot to v6.4 (2019-07-18 16:49:57 +1000)
> 
> are available in the Git repository at:
> 
>   g...@github.com:aik/qemu.git tags/qemu-slof-20190719
> 
> for you to fetch changes up to 300118db53cc454b049d64418c7b2588165a1c35:
> 
>   pseries: Update SLOF firmware image (2019-07-19 12:43:27 +1000)
> 
> 
> Alexey Kardashevskiy (1):
>   pseries: Update SLOF firmware image
> 
>  pc-bios/README   |   2 +-
>  pc-bios/slof.bin | Bin 926432 -> 926784 bytes
>  roms/SLOF|   2 +-
>  3 files changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [GIT PULL for qemu-pseries REPOST] pseries: Update SLOF firmware image

[Alexey Kardashevskiy]

I messed up with my local git so reposting.

The following changes since commit 216965b20b04fbf74e0ce3a3175a9171dba210de:

  ppc/pnv: update skiboot to v6.4 (2019-07-18 16:49:57 +1000)

are available in the Git repository at:

  g...@github.com:aik/qemu.git tags/qemu-slof-20190719

for you to fetch changes up to 300118db53cc454b049d64418c7b2588165a1c35:

  pseries: Update SLOF firmware image (2019-07-19 12:43:27 +1000)


Alexey Kardashevskiy (1):
  pseries: Update SLOF firmware image

 pc-bios/README   |   2 +-
 pc-bios/slof.bin | Bin 926432 -> 926784 bytes
 roms/SLOF|   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)


*** Note: this is not for master, this is for pseries

Re: [Qemu-devel] [PATCH v6 1/4] spapr: Implement dispatch tracking for tcg

[David Gibson]

On Fri, Jul 19, 2019 at 09:12:16AM +1000, Nicholas Piggin wrote:
> Greg Kurz's on July 18, 2019 8:13 pm:
> > On Thu, 18 Jul 2019 13:42:11 +1000
> > Nicholas Piggin  wrote:
> > 
> >> Implement cpu_exec_enter/exit on ppc which calls into new methods of
> >> the same name in PPCVirtualHypervisorClass. These are used by spapr
> >> to implement the splpar VPA dispatch counter initially.
> >> 
> >> Signed-off-by: Nicholas Piggin 
> >> ---
> >> Changes since v5:
> >> - Move 'prod' into next patch.
> >> - Use uint32_t type for dispatch counter.
> >> - Add guest error message for incorrect dispatch counter.
> >> - Conditionally compile away if CONFIG_USER_ONLY
> >> - Small cleanups
> >> 
> >> Changes since v4:
> >> - Store to VPA on the way out as well.
> >> - Increment the dispatch counter directly in the VPA, which means it will
> >>   migrate with guest memory the same as KVM.
> >> - Prod need not be migrated, add a comment.
> >> 
> >>  hw/ppc/spapr.c  | 52 +
> >>  hw/ppc/spapr_hcall.c|  5 
> >>  include/hw/ppc/spapr.h  |  7 +
> >>  target/ppc/cpu.h|  4 +++
> >>  target/ppc/translate_init.inc.c | 27 +
> >>  5 files changed, 90 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >> index 821f0d4a49..3e5678d467 100644
> >> --- a/hw/ppc/spapr.c
> >> +++ b/hw/ppc/spapr.c
> >> @@ -4302,6 +4302,54 @@ PowerPCCPU *spapr_find_cpu(int vcpu_id)
> >>  return NULL;
> >>  }
> >>  
> >> +#ifndef CONFIG_USER_ONLY
> > 
> > This file is for system emulation only, no need to guard here.
> > 
> > This is minor and rest looks good.
> > 
> > Reviewed-by: Greg Kurz 
> 
> Thanks for all the reviews Greg (and others), they made significant 
> improvements. David I'm not sure how you like to work with merging
> patches, but if you can add the Reviewed-by tags and this issue, then
> I won't have to resend.

I've fixed it up in my tree.

> 
> Or if you prefer I can fix it up and send to you privately to reduce
> list spam.
> 
> Thanks,
> Nick
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH qemu] spapr: Stop providing RTAS blob

[David Gibson]

On Thu, Jul 18, 2019 at 09:20:56AM +0200, Thomas Huth wrote:
> On 16/07/2019 07.35, Alexey Kardashevskiy wrote:
> > SLOF implements one itself so let's remove it from QEMU. It is one less
> > image and simpler setup as the RTAS blob never stays in its initial place
> > anyway as the guest OS always decides where to put it.
> > 
> > This totally depends on https://patchwork.ozlabs.org/patch/1132440/ ,
> > hence RFC.
> 
> Patch looks basically fine for me, but I wonder whether we should wait
> for one or two releases until we really remove it from QEMU, so that it
> is still possible to test the latest QEMU with older SLOF releases for a
> while (which is sometimes useful when hunting bugs). Or should this
> maybe even go through the official deprecation process (i.e. with an
> entry in qemu-deprecated.texi)?

I don't really like this idea.  It blocks some cleanups I'd like to do
which rely on it being truly gone, not just sometimes-gone.

I think it's reasonable to do this, since the "raw" rtas blob from
qemu was never supposed to be a guest visible artifact - any guest
that was relying on this was going out of its way to be fragile.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] Discussion: redundant process during hotplug and missed process during unplug

[Zhangbo (Oscar)]

Hi All:
I have 2 questions about (un)hotplug on pcie-root-port.
First Question (hotplug failure because of redundant PCI_EXP_LNKSTA_DLLLA bit 
set):
during VM boot, qemu sets PCI_EXP_LNKSTA_DLLLA according to this process:
pcie_cap_init() -> pcie_cap_v1_fill(), 
even if there's no pcie device added to the VM.
I noticed that during hotplug, qemu also sets PCI_EXP_LNKSTA_DLLLA in 
pcie_cap_slot_hotplug_cb().
It means that the bit PCI_EXP_LNKSTA_DLLLA is set TWICE.
why set this bit during initializing pcie-root-port? It seems unnecessary.
The bad side of this is it causes HOTPLUG FAILURE if we boot the VM and 
hotplug a pcie device at the same time:
In VM kernel，according to this bit set, it senses a PDC event, the 
process is: 
pciehp_probe -> pcie_init -> pcie_init_slot -> 
pciehp_queue_pushbutton_work. 
If the 2 PDC events get too close, the VM kernel will wrongly unplug the 
device.
Suggestion to the 1st problem:
Can I remove the PCI_EXP_LNKSTA_DLLLA bit set process during 
pcie_cap_init().

Second Question (time cost too much during pcie device unplug):
qemu only send ABP event to VM kernel during unpluging pcie devices, VM 
kernel receives the
ABP event then sleep 5s to expect a PDC event, which causes unpluging 
devices takes too long. 
Suggestion to the 2nd problem:
Can I send ABP and *PDC* events to kernet when unplug devices.

[Qemu-devel] [PULL 1/2] roms: Add OpenSBI version 0.4

[Palmer Dabbelt]

From: Alistair Francis 

Add OpenSBI version 0.4 as a git submodule and as a prebult binary.

OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
reference implementation of the RISC-V Supervisor Binary Interface (SBI)
specifications for platform-specific firmwares executing in M-mode. For all
supported platforms, OpenSBI provides several runtime firmware examples.
These example firmwares can be used to replace the legacy riscv-pk bootloader
and enable the use of well-known bootloaders such as U-Boot.

OpenSBI is distributed under the terms of the BSD 2-clause license
("Simplified BSD License" or "FreeBSD License", SPDX: BSD-2-Clause). OpenSBI
source code also contains code reused from other projects desribed here:
https://github.com/riscv/opensbi/blob/master/ThirdPartyNotices.md.

In this case all of the code we are using from OpenSBI is BSD 2-clause
as we aren't using the Kendryte code (Apache-2.0) with QEMU and libfdt
is dual licensed as BSD 2-clause (and GPL-2.0+). OpenSBI isn't being
linked with QEMU either it is just being included with QEMU.

Signed-off-by: Alistair Francis 
Reviewed-by: Bin Meng 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Palmer Dabbelt 
---
 .gitmodules  |   3 ++
 LICENSE  |  21 
 Makefile |   5 +-
 pc-bios/README   |  11 +
 pc-bios/opensbi-riscv32-virt-fw_jump.bin | Bin 0 -> 36888 bytes
 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 40968 bytes
 pc-bios/opensbi-riscv64-virt-fw_jump.bin | Bin 0 -> 40968 bytes
 roms/Makefile|  48 ++-
 roms/opensbi |   1 +
 9 files changed, 68 insertions(+), 21 deletions(-)
 create mode 100755 pc-bios/opensbi-riscv32-virt-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-virt-fw_jump.bin
 create mode 16 roms/opensbi

diff --git a/.gitmodules b/.gitmodules
index 2857eec76377..c5c474169dc7 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -55,3 +55,6 @@
 [submodule "slirp"]
path = slirp
url = https://git.qemu.org/git/libslirp.git
+[submodule "roms/opensbi"]
+   path = roms/opensbi
+   url =   https://git.qemu.org/git/opensbi.git
diff --git a/LICENSE b/LICENSE
index 0e0b4b9553a5..9389ba614f80 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,13 +1,18 @@
-The following points clarify the QEMU license:
+The QEMU distribution includes both the QEMU emulator and
+various firmware files.  These are separate programs that are
+distributed together for our users' convenience, and they have
+separate licenses.
 
-1) QEMU as a whole is released under the GNU General Public License,
-version 2.
+The following points clarify the license of the QEMU emulator:
 
-2) Parts of QEMU have specific licenses which are compatible with the
-GNU General Public License, version 2. Hence each source file contains
-its own licensing information.  Source files with no licensing information
-are released under the GNU General Public License, version 2 or (at your
-option) any later version.
+1) The QEMU emulator as a whole is released under the GNU General
+Public License, version 2.
+
+2) Parts of the QEMU emulator have specific licenses which are compatible
+with the GNU General Public License, version 2. Hence each source file
+contains its own licensing information.  Source files with no licensing
+information are released under the GNU General Public License, version
+2 or (at your option) any later version.
 
 As of July 2013, contributions under version 2 of the GNU General Public
 License (and no later version) are only accepted for the following files
diff --git a/Makefile b/Makefile
index f9791dcb8278..386e13a6ea01 100644
--- a/Makefile
+++ b/Makefile
@@ -770,7 +770,10 @@ palcode-clipper \
 u-boot.e500 u-boot-sam460-20100605.bin \
 qemu_vga.ndrv \
 edk2-licenses.txt \
-hppa-firmware.img
+hppa-firmware.img \
+opensbi-riscv32-virt-fw_jump.bin \
+opensbi-riscv64-sifive_u-fw_jump.bin opensbi-riscv64-virt-fw_jump.bin
+
 
 DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
 60-edk2-aarch64.json 60-edk2-arm.json 60-edk2-i386.json 60-edk2-x86_64.json
diff --git a/pc-bios/README b/pc-bios/README
index 0a17f3ec6df1..68b4a81103cb 100644
--- a/pc-bios/README
+++ b/pc-bios/README
@@ -63,3 +63,14 @@
   ARM. Licensing information is given in "edk2-licenses.txt". The image files
   are described by the JSON documents in the "pc-bios/descriptors" directory,
   which conform to the "docs/interop/firmware.json" schema.
+
+- OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
+  reference implementation of the RISC-V Supervisor Binary Interface (SBI)
+  specifications for platform-specific firmwares executing in M-mode. For all
+  supported platforms, OpenSBI provides several runtime 

[Qemu-devel] [PULL] RISC-V Patches for 4.2-rc2

[Palmer Dabbelt]

The following changes since commit 0b18cfb8f1828c905139b54c8644b0d8f4aad879:

  Update version for v4.1.0-rc1 release (2019-07-16 18:01:28 +0100)

are available in the Git repository at:

  git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-master-4.1-rc2

for you to fetch changes up to fdd1bda4b47cfbec61d0e63a516c614feea0b00b:

  hw/riscv: Load OpenSBI as the default firmware (2019-07-18 14:18:45 -0700)


RISC-V Patches for 4.2-rc2

This contains a pair of patches that add OpenSBI support to QEMU on
RISC-V targets.  The patches have been floating around for a bit, but
everything seems solid now.  These pass my standard test of booting
OpenEmbedded, and also works when I swap around the various command-line
arguments to use the new boot method.


Alistair Francis (2):
  roms: Add OpenSBI version 0.4
  hw/riscv: Load OpenSBI as the default firmware

 .gitmodules  |   3 ++
 LICENSE  |  21 +++
 Makefile |   5 ++-
 hw/riscv/boot.c  |  54 +++
 hw/riscv/sifive_u.c  |   7 ++--
 hw/riscv/virt.c  |  11 --
 include/hw/riscv/boot.h  |   3 ++
 pc-bios/README   |  11 ++
 pc-bios/opensbi-riscv32-virt-fw_jump.bin | Bin 0 -> 36888 bytes
 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 40968 bytes
 pc-bios/opensbi-riscv64-virt-fw_jump.bin | Bin 0 -> 40968 bytes
 qemu-deprecated.texi |  20 ++
 roms/Makefile|  48 ++--
 roms/opensbi |   1 +
 14 files changed, 157 insertions(+), 27 deletions(-)
 create mode 100755 pc-bios/opensbi-riscv32-virt-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-virt-fw_jump.bin
 create mode 16 roms/opensbi
>From Palmer Dabbelt  # This line is ignored.
From: Palmer Dabbelt 
Reply-To: 
Subject: 
In-Reply-To: 

[Qemu-devel] [PULL 2/2] hw/riscv: Load OpenSBI as the default firmware

[Palmer Dabbelt]

From: Alistair Francis 

If the user hasn't specified a firmware to load (with -bios) or
specified no bios (with -bios none) then load OpenSBI by default. This
allows users to boot a RISC-V kernel with just -kernel.

Signed-off-by: Alistair Francis 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/boot.c | 54 +
 hw/riscv/sifive_u.c |  7 +++---
 hw/riscv/virt.c | 11 ++---
 include/hw/riscv/boot.h |  3 +++
 qemu-deprecated.texi| 20 +++
 5 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index ff023f42d01d..5dee63011b43 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -18,6 +18,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu-common.h"
 #include "qemu/units.h"
 #include "qemu/error-report.h"
 #include "exec/cpu-defs.h"
@@ -32,6 +33,59 @@
 # define KERNEL_BOOT_ADDRESS 0x8020
 #endif
 
+void riscv_find_and_load_firmware(MachineState *machine,
+  const char *default_machine_firmware,
+  hwaddr firmware_load_addr)
+{
+char *firmware_filename;
+
+if (!machine->firmware) {
+/*
+ * The user didn't specify -bios.
+ * At the moment we default to loading nothing when this hapens.
+ * In the future this defaul will change to loading the prebuilt
+ * OpenSBI firmware. Let's warn the user and then continue.
+*/
+warn_report("No -bios option specified. Not loading a firmware.");
+warn_report("This default will change in QEMU 4.3. Please use the " \
+"-bios option to aviod breakages when this happens.");
+warn_report("See QEMU's deprecation documentation for details");
+return;
+}
+
+if (!strcmp(machine->firmware, "default")) {
+/*
+ * The user has specified "-bios default". That means we are going to
+ * load the OpenSBI binary included in the QEMU source.
+ *
+ * We can't load the binary by default as it will break existing users
+ * as users are already loading their own firmware.
+ *
+ * Let's try to get everyone to specify the -bios option at all times,
+ * so then in the future we can make "-bios default" the default option
+ * if no -bios option is set without breaking anything.
+ */
+firmware_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS,
+   default_machine_firmware);
+if (firmware_filename == NULL) {
+error_report("Unable to load the default RISC-V firmware \"%s\"",
+ default_machine_firmware);
+exit(1);
+}
+} else {
+firmware_filename = machine->firmware;
+}
+
+if (strcmp(firmware_filename, "none")) {
+/* If not "none" load the firmware */
+riscv_load_firmware(firmware_filename, firmware_load_addr);
+}
+
+if (!strcmp(machine->firmware, "default")) {
+g_free(firmware_filename);
+}
+}
+
 target_ulong riscv_load_firmware(const char *firmware_filename,
  hwaddr firmware_load_addr)
 {
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index ca53a9290db9..71b8083c05ed 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -49,6 +49,8 @@
 
 #include 
 
+#define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
+
 static const struct MemmapEntry {
 hwaddr base;
 hwaddr size;
@@ -269,9 +271,8 @@ static void riscv_sifive_u_init(MachineState *machine)
 /* create device tree */
 create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline);
 
-if (machine->firmware) {
-riscv_load_firmware(machine->firmware, memmap[SIFIVE_U_DRAM].base);
-}
+riscv_find_and_load_firmware(machine, BIOS_FILENAME,
+ memmap[SIFIVE_U_DRAM].base);
 
 if (machine->kernel_filename) {
 riscv_load_kernel(machine->kernel_filename);
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index ecdc77d7281f..25faf3b4178c 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -44,6 +44,12 @@
 
 #include 
 
+#if defined(TARGET_RISCV32)
+# define BIOS_FILENAME "opensbi-riscv32-virt-fw_jump.bin"
+#else
+# define BIOS_FILENAME "opensbi-riscv64-virt-fw_jump.bin"
+#endif
+
 static const struct MemmapEntry {
 hwaddr base;
 hwaddr size;
@@ -399,9 +405,8 @@ static void riscv_virt_board_init(MachineState *machine)
 memory_region_add_subregion(system_memory, memmap[VIRT_MROM].base,
 mask_rom);
 
-if (machine->firmware) {
-riscv_load_firmware(machine->firmware, memmap[VIRT_DRAM].base);
-}
+riscv_find_and_load_firmware(machine, BIOS_FILENAME,
+ memmap[VIRT_DRAM].base);
 
 if 

Re: [Qemu-devel] [Qemu-ppc] [PATCH] Allow bit 15 to be set to 1 on slbmfee and slbmfev

[David Gibson]

On Thu, Jul 18, 2019 at 10:15:52PM +0200, Ivan Warren wrote:
> 
> Le 7/18/2019 à 7:19 PM, Greg Kurz a écrit :
> > We usually mention the subsystem name in the subject, ie.
> > 
> > target/ppc: Allow bit 15 to be set to 1 on slbmfee and slbmfev
> Gotcha ! Still learning the process as I go. Next time I submit something,
> I'll follow the guidelines more accurately.
> > 
> > On Thu, 18 Jul 2019 14:44:49 +0200
> > Ivan Warren  wrote:
> > 
> > > Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
> > > as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
> > > Per this specification, bit 15 is implementation specific
> > > so it may be 1, but can probably ne safely ignored.
> 
> Another typo from me !
> 
> s/ne safely/be safely/
> 
> > > 
> > > Power ISA 2.07B (Power 7/Power 8) indicates the bit is
> > > reserved but some none Linux operating systems do set
> > s/none Linux/non-Linux
> Thanks ! Sorry for the typo !
> > 
> > > this bit to 1 when entering the debugger.
> > > So it is likely it is implemented on those systems
> > > but wasn't yet documented.
> > > 
> > ISA describes things that are common to several processor types,
> > but each implementation may do some extra stuff... like giving
> > a special meaning to an invalid instruction form for example (see
> > commit fa200c95f7f99ce14b8af25ea0be478c722d3cec). This is supposed
> > to be documented in the user manual.
> > 
> > Maybe something similar was done with the reserved bit 15, even if I
> > could fine no trace of that in the Power8 UM... of course. I'll try
> > to find clues within IBM.
> > 
> > https://openpowerfoundation.org/?resource_lib=power8-processor-users-manual
> > 
> > but it is indeed mentioned in the Power9 UM:
> > 
> > https://openpowerfoundation.org/?resource_lib=power-processor-users-manual
> > 
> > 4.10.7.2 SLB Management Instructions
> > 
> > The POWER9 core implements the SLB management instructions as defined in the
> > Power ISA (Version 3.0B). Specifically, the following instruction details 
> > are
> > noteworthy:
> > • The slbmfee and slbmfev instructions can read any SLB entry when UPRT = 
> > ‘1’,
> >if the L-bit in the instruction image is set to a ‘1’. This is an
> >implementation-specific feature that will only be used in the future if 
> > and
> >when the POWER9 processor core supports UPRT = ‘1’ for HPT translation.
> > 
> > Not sure if we support that in TCG, but it doesn't hurt to relax the check
> > if that's enough to make AIX's debugger happy.
> Yep !
> > 
> > Reviewed-by: Greg Kurz 
> > 
> > > Signed-off-by: Ivan Warren 
> > > ---
> > > 
> > > The original creator of the patch is "Zhuowei Zhang"
> > > (https://twitter.com/zhuowei) but I couldn't find any e-mail address.
> > > 
> > This is the original patch, correct ?
> > 
> > https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e
> Indeed !
> > 
> > After speaking with some QEMU folks on irc, it is okay to ignore the lack
> > of S-o-b because the patch is trivial. But the general rule is to always
> > require an S-o-b when posting someone else's patch.
> 
> Is it good practice to add a S-o-b without the original author's consent
> and/or without an e-mail address ?

Absolutely not.

> Although I would very much doubt he would
> have complained.
> 
> Anyway, thanks for reviewing and for the tips ! (and sorry for all the
> noise).
> 
> > 
> > >    target/ppc/translate.c | 4 ++--
> > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > > index 4a5de28036..85f8b147ba 100644
> > > --- a/target/ppc/translate.c
> > > +++ b/target/ppc/translate.c
> > > @@ -7064,8 +7064,8 @@ GEN_HANDLER2(mtsr_64b, "mtsr", 0x1F, 0x12, 0x06,
> > > 0x0010F801, PPC_SEGMENT_64B),
> > >    GEN_HANDLER2(mtsrin_64b, "mtsrin", 0x1F, 0x12, 0x07, 0x001F0001,
> > >     PPC_SEGMENT_64B),
> > >    GEN_HANDLER2(slbmte, "slbmte", 0x1F, 0x12, 0x0C, 0x001F0001,
> > > PPC_SEGMENT_64B),
> > > -GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001F0001,
> > > PPC_SEGMENT_64B),
> > > -GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001F0001,
> > > PPC_SEGMENT_64B),
> > > +GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001E0001,
> > > PPC_SEGMENT_64B),
> > > +GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001E0001,
> > > PPC_SEGMENT_64B),
> > >    GEN_HANDLER2(slbfee_, "slbfee.", 0x1F, 0x13, 0x1E, 0x001F,
> > > PPC_SEGMENT_64B),
> > >    #endif
> > >    GEN_HANDLER(tlbia, 0x1F, 0x12, 0x0B, 0x03FFFC01, PPC_MEM_TLBIA),
> 



-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH V3] net/colo-compare.c: Fix memory leak and code style issue.

[Zhang, Chen]

> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: Thursday, July 18, 2019 6:54 PM
> To: Peter Maydell 
> Cc: Zhang, Chen ; Li Zhijian ;
> Jason Wang ; qemu-dev ;
> Zhang Chen 
> Subject: Re: [Qemu-devel] [PATCH V3] net/colo-compare.c: Fix memory leak
> and code style issue.
> 
> On 7/18/19 12:37 PM, Peter Maydell wrote:
> > On Thu, 18 Jul 2019 at 11:28, Philippe Mathieu-Daudé 
> wrote:
> >>
> >> On 7/18/19 11:22 AM, Zhang Chen wrote:
> >>> From: Zhang Chen 
> >>>
> >>> This patch to fix the origin "char *data" menory leak, code style
> >>> issue
> >>
> >> "memory"

Oh, I will fix this typo in next version.

> >>
> >>> and add necessary check here.
> >>> Reported-by: Coverity (CID 1402785)
> >>>
> >>> Signed-off-by: Zhang Chen 
> >>> ---
> >>>  net/colo-compare.c | 28 +---
> >>>  1 file changed, 21 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/net/colo-compare.c b/net/colo-compare.c index
> >>> 909dd6c6eb..fcccb4c6f6 100644
> >>> --- a/net/colo-compare.c
> >>> +++ b/net/colo-compare.c
> >>> @@ -127,6 +127,17 @@ static int compare_chr_send(CompareState *s,
> >>>  uint32_t vnet_hdr_len,
> >>>  bool notify_remote_frame);
> >>>
> >>> +static bool packet_matches_str(const char *str,
> >>> +   uint8_t *buf,
> >>
> >> You can use 'uint8_t *buf'.
> >
> > ?? that seems to be the same as what is written...
> 
> Oops sorry, I copy/pasted and  did not noticed I removed the 'const'
> word. So I meant: You can use 'const uint8_t *buf'

OK.

Thanks
Zhang Chen

> 
> >>
> >>> +   uint32_t packet_len) {
> >>> +if (packet_len != strlen(str)) {
> >>> +return false;
> >>> +}
> >>> +
> >>> +return !memcmp(str, buf, strlen(str));
> >>
> >> If you don't want to use a local variable to hold strlen(str), you
> >> can reuse packet_len since it is the same value:
> >>
> >>return !memcmp(str, buf, packet_len);
> >>
> >> However it makes the review harder, so I'd prefer using a str_len local 
> >> var.
> >
> > I'm pretty sure the compiler is going to optimise the
> > strlen() away into a compile time constant anyway, so this is somewhat
> > unnecessary micro-optimisation I think.
> 
> I was not sure, I'm glad to learn that :)
> 
> Thanks,
> 
> Phil.

Re: [Qemu-devel] [PATCH V3] net/colo-compare.c: Fix memory leak and code style issue.

[Zhang, Chen]

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Thursday, July 18, 2019 9:42 PM
> To: Zhang, Chen 
> Cc: Li Zhijian ; Jason Wang ;
> qemu-dev ; Zhang Chen 
> Subject: Re: [PATCH V3] net/colo-compare.c: Fix memory leak and code style
> issue.
> 
> On Thu, 18 Jul 2019 at 10:27, Zhang Chen  wrote:
> >
> > From: Zhang Chen 
> >
> > This patch to fix the origin "char *data" menory leak, code style
> > issue and add necessary check here.
> > Reported-by: Coverity (CID 1402785)
> >
> > Signed-off-by: Zhang Chen 
> > ---
> >  net/colo-compare.c | 28 +---
> >  1 file changed, 21 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/colo-compare.c b/net/colo-compare.c index
> > 909dd6c6eb..fcccb4c6f6 100644
> > --- a/net/colo-compare.c
> > +++ b/net/colo-compare.c
> > @@ -127,6 +127,17 @@ static int compare_chr_send(CompareState *s,
> >  uint32_t vnet_hdr_len,
> >  bool notify_remote_frame);
> >
> > +static bool packet_matches_str(const char *str,
> > +   uint8_t *buf,
> > +   uint32_t packet_len) {
> > +if (packet_len != strlen(str)) {
> 
> Is '!=' definitely correct? (ie the incoming packet must
> *not* contain a trailing '\0' or any other trailing data) ?

Yes, the packet not contain a trail.
As Jason comments before, you can see the net/net.c  "net_fill_rstate()".
We just got the length and data.

Thanks
Zhang Chen

> 
> Is there a specification of the protocol somewhere? If so, that presumably
> should say one way or the other.
> 
> > +return false;
> > +}
> > +
> > +return !memcmp(str, buf, strlen(str)); }
> 
> thanks
> -- PMM

[Qemu-devel] [GIT PULL for qemu-pseries] pseries: Update SLOF firmware image

[Alexey Kardashevskiy]

The following changes since commit 5a30afd844be309a820658d956720356ec1d9769:

  ppc/pnv: update skiboot to v6.4 (2019-07-19 11:46:31 +1000)

are available in the Git repository at:

  g...@github.com:aik/qemu.git tags/qemu-slof-20190719

for you to fetch changes up to 2ef7bff0a1aa90bb449c2edac553fe9e61a24461:

  pseries: Update SLOF firmware image (2019-07-19 11:50:47 +1000)


Alexey Kardashevskiy (1):
  pseries: Update SLOF firmware image

 pc-bios/README   |   2 +-
 pc-bios/slof.bin | Bin 926432 -> 926784 bytes
 roms/SLOF|   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)


*** Note: this is not for master, this is for pseries

Re: [Qemu-devel] [RFC] Add virtual SDEI support in qemu

[Guoheyi]

Thanks for all your comments. I'm going to write a simple demo to go 
through the whole workflow first, and then adjust the policies following 
the conclusions of our discussion.


Heyi


On 2019/7/16 16:47, Dave Martin wrote:

On Mon, Jul 15, 2019 at 03:44:46PM +0100, Mark Rutland wrote:

On Mon, Jul 15, 2019 at 03:26:39PM +0100, James Morse wrote:

On 15/07/2019 14:48, Mark Rutland wrote:

On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote:

One option (suggested to me by James Morse) would be to allow userspace
to disable in the in-kernel PSCI implementation and provide its own
PSCI to the guest via SMC -- in which case userspace that wants to
implement SDEI would have to implement PSCI as well.

I think this would be the best approach, since it puts userspace in
charge of everything.

However, this interacts poorly with FW-based mitigations that we
implement in hyp. I suspect we'd probably need a mechanism to delegate
that responsibility back to the kernel, and figure out if that has any
interaction with thigns that got punted to userspace...

This has come up before:
https://lore.kernel.org/r/59c139d0.3040...@arm.com

I agree Qemu should opt-in to this, it needs to be a feature that is enabled.

I had an early version of something like this for testing SDEI before
there was firmware available. The review feedback from Christoffer was
that it should include HVC and SMC, their immediates, and shouldn't be
tied to SMC-CC ranges.

I think this should be a catch-all as Heyi describes to deliver
'unhandled SMC/HVC' to user-space as hypercall exits. We should
include the immediate in the struct.

We can allow Qemu to disable the in-kernel PSCI implementation, which
would let it be done in user-space via this catch-all mechanism. (PSCI
in user-space has come up on another thread recently). The in-kernel
PSCI needs to be default-on for backwards compatibility.

As Mark points out, the piece that's left is the 'arch workaround'
stuff. We always need to handle these in the kernel. I don't think
these should be routed-back, they should be un-obtainable by
user-space.

Sure; I meant that those should be handled in the kernel rather than
going to host userspace and back.

I was suggesting was that userspace would opt into taking ownership of
all HVC calls, then explicitly opt-in to the kernel handling specific
(sets of) calls.

The most logical thing to do would be to have userspace handle all
calls, but add an ioctl to forward a call to KVM.  This puts userspace
in charge of the SMCCC interface, with KVM handling only those things
that userspace can't do for itself, on request.

If the performance overhead is unacceptable for certain calls, we could
have a way to delegate specific function IDs to KVM.  I suspect that
will be the exception rather than the rule.


There are probably issues with that, but I suspect defining "all
undandled calls" will be problematic otherwise.

Agreed: the set of calls not handled by KVM will mutate over time.

Cheers
---Dave

.

Re: [Qemu-devel] [PATCH v7 11/13] vfio: Add function to get dirty page list

[Yan Zhao]

On Fri, Jul 19, 2019 at 02:39:10AM +0800, Kirti Wankhede wrote:
> 
> 
> On 7/12/2019 6:03 AM, Yan Zhao wrote:
> > On Tue, Jul 09, 2019 at 05:49:18PM +0800, Kirti Wankhede wrote:
> >> Dirty page tracking (.log_sync) is part of RAM copying state, where
> >> vendor driver provides the bitmap of pages which are dirtied by vendor
> >> driver through migration region and as part of RAM copy, those pages
> >> gets copied to file stream.
> >>
> >> To get dirty page bitmap:
> >> - write start address, page_size and pfn count.
> >> - read count of pfns copied.
> >> - Vendor driver should return 0 if driver doesn't have any page to
> >>   report dirty in given range.
> >> - Vendor driver should return -1 to mark all pages dirty for given 
> >> range.
> >> - read data_offset, where vendor driver has written bitmap.
> >> - read bitmap from the region or mmaped part of the region.
> >> - Iterate above steps till page bitmap for all requested pfns are copied.
> >>
> >> Signed-off-by: Kirti Wankhede 
> >> Reviewed-by: Neo Jia 
> >> ---
> >>  hw/vfio/migration.c   | 123 
> >> ++
> >>  hw/vfio/trace-events  |   1 +
> >>  include/hw/vfio/vfio-common.h |   2 +
> >>  3 files changed, 126 insertions(+)
> >>
> >> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> >> index 5fb4c5329ede..ca1a8c0f5f1f 100644
> >> --- a/hw/vfio/migration.c
> >> +++ b/hw/vfio/migration.c
> >> @@ -269,6 +269,129 @@ static int vfio_load_device_config_state(QEMUFile 
> >> *f, void *opaque)
> >>  return qemu_file_get_error(f);
> >>  }
> >>  
> >> +void vfio_get_dirty_page_list(VFIODevice *vbasedev,
> >> +  uint64_t start_pfn,
> >> +  uint64_t pfn_count,
> >> +  uint64_t page_size)
> >> +{
> >> +VFIOMigration *migration = vbasedev->migration;
> >> +VFIORegion *region = >region.buffer;
> >> +uint64_t count = 0;
> >> +int64_t copied_pfns = 0;
> >> +int64_t total_pfns = pfn_count;
> >> +int ret;
> >> +
> >> +qemu_mutex_lock(>lock);
> >> +
> >> +while (total_pfns > 0) {
> >> +uint64_t bitmap_size, data_offset = 0;
> >> +uint64_t start = start_pfn + count;
> >> +void *buf = NULL;
> >> +bool buffer_mmaped = false;
> >> +
> >> +ret = pwrite(vbasedev->fd, , sizeof(start),
> >> + region->fd_offset + offsetof(struct 
> >> vfio_device_migration_info,
> >> +  start_pfn));
> >> +if (ret < 0) {
> >> +error_report("%s: Failed to set dirty pages start address %d 
> >> %s",
> >> + vbasedev->name, ret, strerror(errno));
> >> +goto dpl_unlock;
> >> +}
> >> +
> >> +ret = pwrite(vbasedev->fd, _size, sizeof(page_size),
> >> + region->fd_offset + offsetof(struct 
> >> vfio_device_migration_info,
> >> +  page_size));
> >> +if (ret < 0) {
> >> +error_report("%s: Failed to set dirty page size %d %s",
> >> + vbasedev->name, ret, strerror(errno));
> >> +goto dpl_unlock;
> >> +}
> >> +
> >> +ret = pwrite(vbasedev->fd, _pfns, sizeof(total_pfns),
> >> + region->fd_offset + offsetof(struct 
> >> vfio_device_migration_info,
> >> +  total_pfns));
> >> +if (ret < 0) {
> >> +error_report("%s: Failed to set dirty page total pfns %d %s",
> >> + vbasedev->name, ret, strerror(errno));
> >> +goto dpl_unlock;
> >> +}
> >> +
> >> +/* Read copied dirty pfns */
> >> +ret = pread(vbasedev->fd, _pfns, sizeof(copied_pfns),
> >> +region->fd_offset + offsetof(struct 
> >> vfio_device_migration_info,
> >> + copied_pfns));
> >> +if (ret < 0) {
> >> +error_report("%s: Failed to get dirty pages bitmap count %d 
> >> %s",
> >> + vbasedev->name, ret, strerror(errno));
> >> +goto dpl_unlock;
> >> +}
> >> +
> >> +if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_NONE) {
> >> +/*
> >> + * copied_pfns could be 0 if driver doesn't have any page to
> >> + * report dirty in given range
> >> + */
> >> +break;
> >> +} else if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_ALL) {
> >> +/* Mark all pages dirty for this range */
> >> +cpu_physical_memory_set_dirty_range(start_pfn * page_size,
> >> +pfn_count * page_size,
> >> +DIRTY_MEMORY_MIGRATION);
> > seesm pfn_count here is not right
> 
> Changing it to total_pfns in next version
>
if it's total_pfns, then it cannot be in the loop, right?

Re: [Qemu-devel] [PATCH v7 00/13] Add migration support for VFIO device

[Yan Zhao]

On Fri, Jul 19, 2019 at 02:32:33AM +0800, Kirti Wankhede wrote:
> 
> On 7/12/2019 6:02 AM, Yan Zhao wrote:
> > On Fri, Jul 12, 2019 at 03:08:31AM +0800, Kirti Wankhede wrote:
> >>
> >>
> >> On 7/11/2019 9:53 PM, Dr. David Alan Gilbert wrote:
> >>> * Yan Zhao (yan.y.z...@intel.com) wrote:
>  On Thu, Jul 11, 2019 at 06:50:12PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> >> Hi Kirti,
> >> There are still unaddressed comments to your patches v4.
> >> Would you mind addressing them?
> >>
> >> 1. should we register two migration interfaces simultaneously
> >> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04750.html)
> >
> > Please don't do this.
> > As far as I'm aware we currently only have one device that does that
> > (vmxnet3) and a patch has just been posted that fixes/removes that.
> >
> > Dave
> >
>  hi Dave,
>  Thanks for notifying this. but if we want to support postcopy in future,
>  after device stops, what interface could we use to transfer data of
>  device state only?
>  for postcopy, when source device stops, we need to transfer only
>  necessary device state to target vm before target vm starts, and we
>  don't want to transfer device memory as we'll do that after target vm
>  resuming.
> >>>
> >>> Hmm ok, lets see; that's got to happen in the call to:
> >>> qemu_savevm_state_complete_precopy(fb, false, false);
> >>> that's made from postcopy_start.
> >>>  (the false's are iterable_only and inactivate_disks)
> >>>
> >>> and at that time I believe the state is POSTCOPY_ACTIVE, so in_postcopy
> >>> is true.
> >>>
> >>> If you're doing postcopy, then you'll probably define a has_postcopy()
> >>> function, so qemu_savevm_state_complete_precopy will skip the
> >>> save_live_complete_precopy call from it's loop for at least two of the
> >>> reasons in it's big if.
> >>>
> >>> So you're right; you need the VMSD for this to happen in the second
> >>> loop in qemu_savevm_state_complete_precopy.  Hmm.
> >>>
> >>> Now, what worries me, and I don't know the answer, is how the section
> >>> header for the vmstate and the section header for an iteration look
> >>> on the stream; how are they different?
> >>>
> >>
> >> I don't have way to test postcopy migration - is one of the major reason
> >> I had not included postcopy support in this patchset and clearly called
> >> out in cover letter.
> >> This patchset is thoroughly tested for precopy migration.
> >> If anyone have hardware that supports fault, then I would prefer to add
> >> postcopy support as incremental change later which can be tested before
> >> submitting.
> >>
> >> Just a suggestion, instead of using VMSD, is it possible to have some
> >> additional check to call save_live_complete_precopy from
> >> qemu_savevm_state_complete_precopy?
> >>
> >>
> 
> >> 2. in each save iteration, how much data is to be saved
> >> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04683.html)
> >>
> >>> how big is the data_size ?
> >>> if this size is too big, it may take too much time and block others.
> >>
> >> I do had mentioned this in the comment about the structure in vfio.h
> >> header. data_size will be provided by vendor driver and obviously will
> >> not be greater that migration region size. Vendor driver should be
> >> responsible to keep its solution optimized.
> >>
> > if the data_size is no big than migration region size, and each
> > iteration only saves data of data_size, i'm afraid it will cause
> > prolonged down time. after all, the migration region size cannot be very
> > big.
> 
> As I mentioned above, its vendor driver responsibility to keep its
> solution optimized.
> A good behaving vendor driver should not cause unnecessary prolonged
> down time.
>
I think vendor data can determine the data_size, but qemu has to decide
how much data to transmit according to the actual transmitting time (or
transmitting speed). when transmitting speed is high, transmit more data
a iteration, and low speed small data a iteration. This transmitting
time knowledge is not available to vendor driver, and even it has this
knowledge, can it dynamically change data region size?
maybe you can say vendor driver can register a big enough region and
dynamically use part of it, but what is big enough and it really costs
memory.

> > Also, if vendor driver determines how much data to save in each
> > iteration alone, and no checks in qemu, it may cause other devices'
> > migration time be squeezed.
> > 
> 
> Sorry, how will that squeeze other device's migration time?
> 
if a vendor driver has extremely big data to transmit, other devices
have to wait until it finishes to transmit their own data. In a given
time period, it can be considered as their time slot being squeezed.
not sure whether it's a good practice.

> >>
> >> 3. do we need extra interface to get data for device state only
> >> 

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr: Stop providing RTAS blob

[Alexey Kardashevskiy]

On 18/07/2019 20:49, Thomas Huth wrote:

On 18/07/2019 12.40, Greg Kurz wrote:

On Thu, 18 Jul 2019 17:55:12 +1000
Alexey Kardashevskiy  wrote:




On 18/07/2019 17:20, Thomas Huth wrote:

On 16/07/2019 07.35, Alexey Kardashevskiy wrote:

SLOF implements one itself so let's remove it from QEMU. It is one less
image and simpler setup as the RTAS blob never stays in its initial place
anyway as the guest OS always decides where to put it.

This totally depends on https://patchwork.ozlabs.org/patch/1132440/ ,
hence RFC.


Patch looks basically fine for me, but I wonder whether we should wait
for one or two releases until we really remove it from QEMU, so that it
is still possible to test the latest QEMU with older SLOF releases for a
while (which is sometimes useful when hunting bugs). Or should this
maybe even go through the official deprecation process (i.e. with an
entry in qemu-deprecated.texi)?


I worry more about slof being distributed as a separate package in RHEL,
easy enough to get qemu/slof out of sync.



Then it seems to call for keeping the code around in QEMU in case RHEL's
slof doesn't implement the RTAS blob. Following the official deprecation
process looks like a good option IMHO.


We can of course make the qemu rpm depend on the new SLOF rpm, so that
you can not install an older SLOF with a newer QEMU.


Cool, let's do that.


But anyway, to avoid confusion and ease debugging,


There is a little confusion ("why did the guest stop after Device tree 
struct  0x0aff -> 0x0b00") and what will make 
the debugging harder if we drop rtas from qemu now? I think I should 
have known the answer by now but I do not :)



I'd also rather vote
for the official deprecation process here, and remove the RTAS blob from
QEMU after the official deprecation period.


We won't be able to enjoy one less binary for another year and we 
already have bugs fixes for which would benefit from not having rtas blob.




--
Alexey

Re: [Qemu-devel] [PATCH-for-4.1] hw/ide/piix: Mark the PIIX IDE interfaces as not user_creatable

[John Snow]

On 7/18/19 5:26 AM, Paolo Bonzini wrote:
> On 18/07/19 11:17, Philippe Mathieu-Daudé wrote:
>> The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
>> PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
>> TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be created
>> in part, it has to be created and used as a whole.
>>
>> Similarly with the 'piix4-ide' device and the PIIX4 chipset
>> modelled as TYPE_PIIX4_PCI_DEVICE.
>>
>> Disable the 'user_creatable' flag.
>>
>> part of TYPE_PIIX3_PCI_DEVICE (TYPE_PIIX3_XEN_DEVICE)
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
> 
> This works though:
> 
>   qemu-system-x86_64 \
> -M q35,sata=off -device piix3-ide,addr=1f.2 \
> -drive if=none,file=freedos.raw,id=hd -device ide-hd,drive=hd
> 
> And it is a nice hack to mimic Q35's legacy IDE mode...
> 
> Paolo
> 

Right. I never modeled the "right" way to do legacy IDE because I think
it would involve some deeper surgery to the IDE code, and it was hard to
justify the time spent.

Why do we want to disable these devices, exactly?

--js

Re: [Qemu-devel] [PATCH-for-4.1] crypto: Fix data type for len parameter in two typedefs

[Carlo Arenas]

this series seems to provide a more complete fix

https://patchwork.ozlabs.org/cover/1131259/

Re: [Qemu-devel] [PATCH] iotests: Set read-zeroes on in null block driver for Valgrind

[John Snow]

On 7/15/19 12:06 PM, Andrey Shinkevich wrote:
> The Valgrind tool reports about the uninitialised buffer 'buf'
> instantiated on the stack of the function guess_disk_lchs().
> Pass 'read-zeroes=on' to the null block driver to make it deterministic.
> The output of the tests 051, 186 and 227 now includes the parameter
> 'read-zeroes'. So, the benchmark output files are being changed too.
> 
> Suggested-by: Kevin Wolf 
> Signed-off-by: Andrey Shinkevich 

CC qemu-block;

Do you have a list of which tests pass cleanly via valgrind and which do
not? At the moment when I try I get a lot of errors from loaded
libraries, so it's hard to sift through.

--js

> ---
> Note:
> The change in the tests 093 and 136 reveals the race condition in chardev.
> The patch "chardev: race condition with tcp_chr_disconnect" has been emailed
> to qemu-devel@nongnu.org on July, 12 of 2019 with the Message ID
> <1562959033-223586-1-git-send-email-andrey.shinkev...@virtuozzo.com>
> 
>  tests/qemu-iotests/051|  10 +--
>  tests/qemu-iotests/051.pc.out |  10 +--
>  tests/qemu-iotests/093|   9 +--
>  tests/qemu-iotests/136|   1 +
>  tests/qemu-iotests/186|  20 +++---
>  tests/qemu-iotests/186.out| 152 
> +-
>  tests/qemu-iotests/227|   4 +-
>  tests/qemu-iotests/227.out|   4 +-
>  tests/qemu-iotests/238|   2 +-
>  tests/qemu-iotests/240|   8 +--
>  10 files changed, 111 insertions(+), 109 deletions(-)
> 
> diff --git a/tests/qemu-iotests/051 b/tests/qemu-iotests/051
> index 200660f..ce942a5 100755
> --- a/tests/qemu-iotests/051
> +++ b/tests/qemu-iotests/051
> @@ -251,11 +251,11 @@ echo
>  # Cannot use the test image because cache=none might not work on the host FS
>  # Use cdrom so that we won't get errors about missing media
>  
> -run_qemu -drive driver=null-co,cache=none
> -run_qemu -drive driver=null-co,cache=directsync
> -run_qemu -drive driver=null-co,cache=writeback
> -run_qemu -drive driver=null-co,cache=writethrough
> -run_qemu -drive driver=null-co,cache=unsafe
> +run_qemu -drive driver=null-co,read-zeroes=on,cache=none
> +run_qemu -drive driver=null-co,read-zeroes=on,cache=directsync
> +run_qemu -drive driver=null-co,read-zeroes=on,cache=writeback
> +run_qemu -drive driver=null-co,read-zeroes=on,cache=writethrough
> +run_qemu -drive driver=null-co,read-zeroes=on,cache=unsafe
>  run_qemu -drive driver=null-co,cache=invalid_value
>  
>  # Can't test direct=on here because O_DIRECT might not be supported on this 
> FS
> diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
> index 2d811c1..000557c 100644
> --- a/tests/qemu-iotests/051.pc.out
> +++ b/tests/qemu-iotests/051.pc.out
> @@ -245,23 +245,23 @@ QEMU X.Y.Z monitor - type 'help' for more information
>  
>  === Cache modes ===
>  
> -Testing: -drive driver=null-co,cache=none
> +Testing: -drive driver=null-co,read-zeroes=on,cache=none
>  QEMU X.Y.Z monitor - type 'help' for more information
>  (qemu) quit
>  
> -Testing: -drive driver=null-co,cache=directsync
> +Testing: -drive driver=null-co,read-zeroes=on,cache=directsync
>  QEMU X.Y.Z monitor - type 'help' for more information
>  (qemu) quit
>  
> -Testing: -drive driver=null-co,cache=writeback
> +Testing: -drive driver=null-co,read-zeroes=on,cache=writeback
>  QEMU X.Y.Z monitor - type 'help' for more information
>  (qemu) quit
>  
> -Testing: -drive driver=null-co,cache=writethrough
> +Testing: -drive driver=null-co,read-zeroes=on,cache=writethrough
>  QEMU X.Y.Z monitor - type 'help' for more information
>  (qemu) quit
>  
> -Testing: -drive driver=null-co,cache=unsafe
> +Testing: -drive driver=null-co,read-zeroes=on,cache=unsafe
>  QEMU X.Y.Z monitor - type 'help' for more information
>  (qemu) quit
>  
> diff --git a/tests/qemu-iotests/093 b/tests/qemu-iotests/093
> index d88fbc1..4b2cac1 100755
> --- a/tests/qemu-iotests/093
> +++ b/tests/qemu-iotests/093
> @@ -38,7 +38,7 @@ class ThrottleTestCase(iotests.QMPTestCase):
>  def setUp(self):
>  self.vm = iotests.VM()
>  for i in range(0, self.max_drives):
> -self.vm.add_drive(self.test_img)
> +self.vm.add_drive(self.test_img, "file.read-zeroes=on")
>  self.vm.launch()
>  
>  def tearDown(self):
> @@ -273,7 +273,8 @@ class ThrottleTestGroupNames(iotests.QMPTestCase):
>  def setUp(self):
>  self.vm = iotests.VM()
>  for i in range(0, self.max_drives):
> -self.vm.add_drive(self.test_img, "throttling.iops-total=100")
> +self.vm.add_drive(self.test_img,
> +  
> "throttling.iops-total=100,file.read-zeroes=on")
>  self.vm.launch()
>  
>  def tearDown(self):
> @@ -378,10 +379,10 @@ class ThrottleTestRemovableMedia(iotests.QMPTestCase):
>  def test_removable_media(self):
>  # Add a couple of dummy nodes named cd0 and cd1
>  result = self.vm.qmp("blockdev-add", driver="null-aio",
> - 

Re: [Qemu-devel] [PATCH v7 05/13] vfio: Add migration region initialization and finalize function

[Kirti Wankhede]

On 7/17/2019 3:07 AM, Alex Williamson wrote:
> On Tue, 9 Jul 2019 15:19:12 +0530
> Kirti Wankhede  wrote:
> 
>> - Migration functions are implemented for VFIO_DEVICE_TYPE_PCI device in this
>>   patch series.
>> - VFIO device supports migration or not is decided based of migration region
>>   query. If migration region query is successful and migration region
>>   initialization is successful then migration is supported else migration is
>>   blocked.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/Makefile.objs |   2 +-
>>  hw/vfio/migration.c   | 145 
>> ++
>>  hw/vfio/trace-events  |   3 +
>>  include/hw/vfio/vfio-common.h |  14 
>>  4 files changed, 163 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/vfio/migration.c
>>
>> diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
>> index abad8b818c9b..36033d1437c5 100644
>> --- a/hw/vfio/Makefile.objs
>> +++ b/hw/vfio/Makefile.objs
>> @@ -1,4 +1,4 @@
>> -obj-y += common.o spapr.o
>> +obj-y += common.o spapr.o migration.o
>>  obj-$(CONFIG_VFIO_PCI) += pci.o pci-quirks.o display.o
>>  obj-$(CONFIG_VFIO_CCW) += ccw.o
>>  obj-$(CONFIG_VFIO_PLATFORM) += platform.o
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> new file mode 100644
>> index ..a2cfbd5af2e1
>> --- /dev/null
>> +++ b/hw/vfio/migration.c
>> @@ -0,0 +1,145 @@
>> +/*
>> + * Migration support for VFIO devices
>> + *
>> + * Copyright NVIDIA, Inc. 2019
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include 
>> +
>> +#include "hw/vfio/vfio-common.h"
>> +#include "cpu.h"
>> +#include "migration/migration.h"
>> +#include "migration/qemu-file.h"
>> +#include "migration/register.h"
>> +#include "migration/blocker.h"
>> +#include "migration/misc.h"
>> +#include "qapi/error.h"
>> +#include "exec/ramlist.h"
>> +#include "exec/ram_addr.h"
>> +#include "pci.h"
>> +#include "trace.h"
>> +
>> +static void vfio_migration_region_exit(VFIODevice *vbasedev)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +
>> +if (!migration) {
>> +return;
>> +}
>> +
>> +if (migration->region.buffer.size) {
> 
> Having a VFIORegion named buffer within a struct named region is
> unnecessarily confusing.  Please fix.
> 

Adding this fix in next version.

>> +vfio_region_exit(>region.buffer);
>> +vfio_region_finalize(>region.buffer);
>> +}
>> +}
>> +
>> +static int vfio_migration_region_init(VFIODevice *vbasedev)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +Object *obj = NULL;
>> +int ret = -EINVAL;
>> +
>> +if (!migration) {
>> +return ret;
>> +}
>> +
>> +if (!vbasedev->ops || !vbasedev->ops->vfio_get_object) {
>> +return ret;
>> +}
>> +
>> +obj = vbasedev->ops->vfio_get_object(vbasedev);
>> +if (!obj) {
>> +return ret;
>> +}
>> +
>> +ret = vfio_region_setup(obj, vbasedev, >region.buffer,
>> +migration->region.index, "migration");
>> +if (ret) {
>> +error_report("%s: Failed to setup VFIO migration region %d: %s",
>> + vbasedev->name, migration->region.index, 
>> strerror(-ret));
>> +goto err;
>> +}
>> +
>> +if (!migration->region.buffer.size) {
>> +ret = -EINVAL;
>> +error_report("%s: Invalid region size of VFIO migration region %d: 
>> %s",
>> + vbasedev->name, migration->region.index, 
>> strerror(-ret));
>> +goto err;
>> +}
>> +
>> +return 0;
>> +
>> +err:
>> +vfio_migration_region_exit(vbasedev);
>> +return ret;
>> +}
>> +
>> +static int vfio_migration_init(VFIODevice *vbasedev,
>> +   struct vfio_region_info *info)
>> +{
>> +int ret;
>> +
>> +vbasedev->migration = g_new0(VFIOMigration, 1);
>> +vbasedev->migration->region.index = info->index;
> 
> VFIORegion already caches the region index, VFIORegion.nr.
> 
>> +
>> +ret = vfio_migration_region_init(vbasedev);
>> +if (ret) {
>> +error_report("%s: Failed to initialise migration region",
>> + vbasedev->name);
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/* -- */
>> +
>> +int vfio_migration_probe(VFIODevice *vbasedev, Error **errp)
>> +{
>> +struct vfio_region_info *info;
>> +Error *local_err = NULL;
>> +int ret;
>> +
>> +ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_MIGRATION,
>> +   VFIO_REGION_SUBTYPE_MIGRATION, );
>> +if (ret) {
>> +goto add_blocker;
>> +}
>> +
>> +ret = vfio_migration_init(vbasedev, info);
>> +if (ret) {
>> +goto add_blocker;
>> +}
>> +
>> +

Re: [Qemu-devel] [PATCH 0/3] Series to implement suspend for ppc/spapr

[Nicholas Piggin]

Paolo Bonzini's on July 18, 2019 9:08 pm:
> On 18/07/19 12:39, Nicholas Piggin wrote:
>> Any comments on this series would be welcome. Hopefully someone who
>> knows i386 can give some feedback on the possible bug fix, and
>> whether the new wakeup method will suit i386.
> 
> Looks good, though only i386 supports wakeup so perhaps it's better to
> DTRT and move the reset to the PC machine's wakeup method.  Then pseries
> need not implement mc->wakeup at all.

Yeah that probably makes more sense because the i386 patch should be 
quite trivial. I will try that and re-send.

Thanks,
Nick

Re: [Qemu-devel] [PATCH 1/3] qmp: don't emit the RESET event on wakeup

[Nicholas Piggin]

Christian Borntraeger's on July 18, 2019 9:27 pm:
> 
> 
> On 18.07.19 13:06, Paolo Bonzini wrote:
>> On 18/07/19 12:39, Nicholas Piggin wrote:
>>> Commit 1405819637f53 ("qmp: don't emit the RESET event on wakeup from
>>> S3") changed system wakeup to avoid calling qapi_event_send_reset.
>>> Commit 76ed4b18debfe ("s390/ipl: fix ipl with -no-reboot") appears to
>>> have inadvertently broken that logic.
>>>
>>> Signed-off-by: Nicholas Piggin 
>>> ---
>>> I'm not quite sure if this patch is correct and haven't tested it, I
>>> found it by inspection. If this patch is incorrect, I will have to
>>> adjust patch 2.
>>>
>>>  vl.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/vl.c b/vl.c
>>> index 5089fce6c5..ef3c7ab8b8 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -1550,7 +1550,7 @@ void qemu_system_reset(ShutdownCause reason)
>>>  } else {
>>>  qemu_devices_reset();
>>>  }
>>> -if (reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>>> +if (reason && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>>>  qapi_event_send_reset(shutdown_caused_by_guest(reason), reason);
>>>  }
>>>  cpu_synchronize_all_post_reset();
>>>
>> 
>> Yes, it seems correct and I've queued it for 4.1.
> 
> Yes makes sense. 
> Would it be better to write out if(reason) e.g. replace "reason" with "reason 
> != SHUTDOWN_CAUSE_NONE" ?

I guess it's a matter of preference so I won't weigh in :) My patch
did try to revert back to the previous form but I'm happy to change
it.

> Going even further, I am asking myself if something like
> 
> diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> index 60bd081d3ef3..406743566869 100644
> --- a/hw/s390x/ipl.c
> +++ b/hw/s390x/ipl.c
> @@ -577,7 +577,7 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset 
> reset_type)
>  if (reset_type == S390_RESET_MODIFIED_CLEAR ||
>  reset_type == S390_RESET_LOAD_NORMAL) {
>  /* ignore -no-reboot, send no event  */
> -qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET);
> +qemu_system_reset_request(SHUTDOWN_CAUSE_NONE);
>  } else {
>  qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
>  }
> 
> would also work.

If that works for you, then you could take out the test in the reset
code. You would have to modify qemu_system_reset_request too of course.

But it seems a bit unsatisfactory to change the reason for the request
so as to influence behaviour. Either the requests should ask for 
particular behaviour, or the logic for determining how to handle
the type of request should remain in the reset logic, I would say.

Thanks,
Nick

Re: [Qemu-devel] [PATCH v6 1/4] spapr: Implement dispatch tracking for tcg

[Nicholas Piggin]

Greg Kurz's on July 18, 2019 8:13 pm:
> On Thu, 18 Jul 2019 13:42:11 +1000
> Nicholas Piggin  wrote:
> 
>> Implement cpu_exec_enter/exit on ppc which calls into new methods of
>> the same name in PPCVirtualHypervisorClass. These are used by spapr
>> to implement the splpar VPA dispatch counter initially.
>> 
>> Signed-off-by: Nicholas Piggin 
>> ---
>> Changes since v5:
>> - Move 'prod' into next patch.
>> - Use uint32_t type for dispatch counter.
>> - Add guest error message for incorrect dispatch counter.
>> - Conditionally compile away if CONFIG_USER_ONLY
>> - Small cleanups
>> 
>> Changes since v4:
>> - Store to VPA on the way out as well.
>> - Increment the dispatch counter directly in the VPA, which means it will
>>   migrate with guest memory the same as KVM.
>> - Prod need not be migrated, add a comment.
>> 
>>  hw/ppc/spapr.c  | 52 +
>>  hw/ppc/spapr_hcall.c|  5 
>>  include/hw/ppc/spapr.h  |  7 +
>>  target/ppc/cpu.h|  4 +++
>>  target/ppc/translate_init.inc.c | 27 +
>>  5 files changed, 90 insertions(+), 5 deletions(-)
>> 
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index 821f0d4a49..3e5678d467 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -4302,6 +4302,54 @@ PowerPCCPU *spapr_find_cpu(int vcpu_id)
>>  return NULL;
>>  }
>>  
>> +#ifndef CONFIG_USER_ONLY
> 
> This file is for system emulation only, no need to guard here.
> 
> This is minor and rest looks good.
> 
> Reviewed-by: Greg Kurz 

Thanks for all the reviews Greg (and others), they made significant 
improvements. David I'm not sure how you like to work with merging
patches, but if you can add the Reviewed-by tags and this issue, then
I won't have to resend.

Or if you prefer I can fix it up and send to you privately to reduce
list spam.

Thanks,
Nick

Re: [Qemu-devel] [PATCH for-4.1] target/arm: Limit ID register assertions to TCG

[Laszlo Ersek]

On 07/18/19 14:59, Peter Maydell wrote:
> In arm_cpu_realizefn() we make several assertions about the values of
> guest ID registers:
>  * if the CPU provides AArch32 v7VE or better it must advertise the
>ARM_DIV feature
>  * if the CPU provides AArch32 A-profile v6 or better it must
>advertise the Jazelle feature
> 
> These are essentially consistency checks that our ID register
> specifications in cpu.c didn't accidentally miss out a feature,
> because increasingly the TCG emulation gates features on the values
> in ID registers rather than using old-style checks of ARM_FEATURE_FOO
> bits.
> 
> Unfortunately, these asserts can cause problems if we're running KVM,
> because in that case we don't control the values of the ID registers
> -- we read them from the host kernel.  In particular, if the host
> kernel is older than 4.15 then it doesn't expose the ID registers via
> the KVM_GET_ONE_REG ioctl, and we set up dummy values for some
> registers and leave the rest at zero.  (See the comment in
> target/arm/kvm64.c kvm_arm_get_host_cpu_features().) This set of
> dummy values is not sufficient to pass our assertions, and so on
> those kernels running an AArch32 guest on AArch64 will assert.
> 
> We could provide a more sophisticated set of dummy ID registers in
> this case, but that still leaves the possibility of a host CPU which
> reports bogus ID register values that would cause us to assert.  It's
> more robust to only do these ID register checks if we're using TCG,
> as that is the only case where this is truly a QEMU code bug.
> 
> Reported-by: Laszlo Ersek 
> Fixes: https://bugs.launchpad.net/qemu/+bug/1830864
> Signed-off-by: Peter Maydell 
> ---
> Laszlo, would you mind testing this on your setup? I don't have
> a system with an old enough kernel to trigger the assert. (The
> change is pretty much a "has to work" one though :-))

32-bit guest runs fine, with this patch applied to v4.1.0-rc1 :)

Tested-by: Laszlo Ersek 

Thank you!
Laszlo

> 
>  target/arm/cpu.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 1959467fdc8..9eb40ff755f 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1369,6 +1369,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>   * There exist AArch64 cpus without AArch32 support.  When KVM
>   * queries ID_ISAR0_EL1 on such a host, the value is UNKNOWN.
>   * Similarly, we cannot check ID_AA64PFR0 without AArch64 support.
> + * As a general principle, we also do not make ID register
> + * consistency checks anywhere unless using TCG, because only
> + * for TCG would a consistency-check failure be a QEMU bug.
>   */
>  if (arm_feature(>env, ARM_FEATURE_AARCH64)) {
>  no_aa32 = !cpu_isar_feature(aa64_aa32, cpu);
> @@ -1383,7 +1386,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>   * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
>   * Security Extensions is ARM_FEATURE_EL3.
>   */
> -assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
> +assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(arm_div, cpu));
>  set_feature(env, ARM_FEATURE_LPAE);
>  set_feature(env, ARM_FEATURE_V7);
>  }
> @@ -1409,7 +1412,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  if (arm_feature(env, ARM_FEATURE_V6)) {
>  set_feature(env, ARM_FEATURE_V5);
>  if (!arm_feature(env, ARM_FEATURE_M)) {
> -assert(no_aa32 || cpu_isar_feature(jazelle, cpu));
> +assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(jazelle, 
> cpu));
>  set_feature(env, ARM_FEATURE_AUXCR);
>  }
>  }
> 

[Qemu-devel] [Bug 1828723] Re: [RFE] option to suppress gemu_log() output

[Thomas Moschny]

Indeed I think gemu_log() is the problem here.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1828723

Title:
  [RFE] option to suppress gemu_log() output

Status in QEMU:
  New

Bug description:
  With user mode emulation, messages from genu_log() are emitted
  unconditionally to stderr. I didn't find a way to suppress them. It
  would be nice to have options similar to the -D/-d options to be able
  to filter and/or redirect the output.

  My use case is chroot/container execution for different architectures
  via binfmt. In this case it will appear as if the binary in question
  had emitted messages like "Unsupported setsockopt ..." to stderr while
  in fact the message came from qemu-*-static.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1828723/+subscriptions

[Qemu-devel] [PATCH-for-4.1] crypto: Fix data type for len parameter in two typedefs

[Stefan Weil]

Signed-off-by: Stefan Weil 
---
 crypto/hash-nettle.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/hash-nettle.c b/crypto/hash-nettle.c
index 96f186f442..074cece468 100644
--- a/crypto/hash-nettle.c
+++ b/crypto/hash-nettle.c
@@ -28,10 +28,10 @@
 
 typedef void (*qcrypto_nettle_init)(void *ctx);
 typedef void (*qcrypto_nettle_write)(void *ctx,
- unsigned int len,
+ size_t len,
  const uint8_t *buf);
 typedef void (*qcrypto_nettle_result)(void *ctx,
-  unsigned int len,
+  size_t len,
   uint8_t *buf);
 
 union qcrypto_hash_ctx {
-- 
2.20.1

[Qemu-devel] [PATCH] audio: Add missing fall through comments

[Stefan Weil]

Signed-off-by: Stefan Weil 
---
 audio/audio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/audio/audio.c b/audio/audio.c
index 5fd9a58a80..a7a13e900a 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -304,6 +304,7 @@ void audio_pcm_init_info (struct audio_pcm_info *info, 
struct audsettings *as)
 
 case AUDIO_FORMAT_S16:
 sign = 1;
+/* fall through */
 case AUDIO_FORMAT_U16:
 bits = 16;
 shift = 1;
@@ -311,6 +312,7 @@ void audio_pcm_init_info (struct audio_pcm_info *info, 
struct audsettings *as)
 
 case AUDIO_FORMAT_S32:
 sign = 1;
+/* fall through */
 case AUDIO_FORMAT_U32:
 bits = 32;
 shift = 2;
-- 
2.20.1

Re: [Qemu-devel] [PATCH v2 00/17] ppc/pnv: add XIVE support for KVM guests

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190718115420.19919-1-...@kaod.org/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

PASS 51 test-qobject-input-visitor /visitor/input/fail/alternate
PASS 52 test-qobject-input-visitor /visitor/input/fail/union-list
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-qmp-cmds -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-qmp-cmds" 
==7847==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-coroutine" 
==7885==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-coroutine /basic/no-dangling-access
PASS 2 test-coroutine /basic/lifecycle
PASS 3 test-coroutine /basic/yield
==7885==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 
0x7fff340c5000; bottom 0x7f9fdfaf8000; size: 0x005f545cd000 (409437261824)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 4 test-coroutine /basic/nesting
---
PASS 11 test-aio /aio/event/wait
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
==7904==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-aio-multithread -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="test-aio-multithread" 
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
PASS 1 test-aio-multithread /aio/multi/lifecycle
==7910==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img 
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="ide-test" 
PASS 2 test-aio-multithread /aio/multi/schedule
==7928==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 1 ide-test /x86_64/ide/identify
==7944==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 2 ide-test /x86_64/ide/flush
==7950==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
==7957==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 ide-test /x86_64/ide/bmdma/trim
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
==7968==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
==7979==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-throttle" 
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
---
PASS 6 test-throttle /throttle/detach_attach
PASS 7 test-throttle /throttle/config_functions
PASS 8 test-throttle /throttle/accounting
==7986==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 9 test-throttle /throttle/groups
PASS 10 test-throttle /throttle/config/enabled
PASS 11 test-throttle /throttle/config/conflicting
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-thread-pool" 
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
PASS 1 test-thread-pool /thread-pool/submit

Re: [Qemu-devel] [PATCH-for-4.1 v7 1/1] hw/block/pflash_cfi01: Add missing DeviceReset() handler

[Philippe Mathieu-Daudé]

On 7/18/19 8:38 PM, Laszlo Ersek wrote:
> On 07/18/19 17:03, Laszlo Ersek wrote:
>> On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
>>> To avoid incoherent states when the machine resets (see but report
>>
>> (1) For the PULL request, please fix the typo: s/but/bug/
>>
>>> below), add the device reset callback.
>>>
>>> A "system reset" sets the device state machine in READ_ARRAY mode
>>> and, after some delay, set the SR.7 READY bit.
>>>
>>> Since we do not model timings, we set the SR.7 bit directly.
>>>
>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1678713
>>> Reported-by: Laszlo Ersek 
>>> Reviewed-by: John Snow 
>>> Reviewed-by: Alistair Francis 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>  hw/block/pflash_cfi01.c | 19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
>>> index 435be1e35c..a1ec1faae5 100644
>>> --- a/hw/block/pflash_cfi01.c
>>> +++ b/hw/block/pflash_cfi01.c
>>> @@ -865,6 +865,24 @@ static void pflash_cfi01_realize(DeviceState *dev, 
>>> Error **errp)
>>>  pfl->cfi_table[0x3f] = 0x01; /* Number of protection fields */
>>>  }
>>>  
>>> +static void pflash_cfi01_system_reset(DeviceState *dev)
>>> +{
>>> +PFlashCFI01 *pfl = PFLASH_CFI01(dev);
>>> +
>>> +/*
>>> + * The command 0x00 is not assigned by the CFI open standard,
>>> + * but QEMU historically uses it for the READ_ARRAY command (0xff).
>>> + */
>>> +pfl->cmd = 0x00;
>>> +pfl->wcycle = 0;
>>> +memory_region_rom_device_set_romd(>mem, true);
>>> +/*
>>> + * The WSM ready timer occurs at most 150ns after system reset.
>>> + * This model deliberately ignores this delay.
>>> + */
>>> +pfl->status = 0x80;
>>> +}
>>> +
>>>  static Property pflash_cfi01_properties[] = {
>>>  DEFINE_PROP_DRIVE("drive", PFlashCFI01, blk),
>>>  /* num-blocks is the number of blocks actually visible to the guest,
>>> @@ -909,6 +927,7 @@ static void pflash_cfi01_class_init(ObjectClass *klass, 
>>> void *data)
>>>  {
>>>  DeviceClass *dc = DEVICE_CLASS(klass);
>>>  
>>> +dc->reset = pflash_cfi01_system_reset;
>>>  dc->realize = pflash_cfi01_realize;
>>>  dc->props = pflash_cfi01_properties;
>>>  dc->vmsd = _pflash;
>>>
>>

s/but/bug/ typo fixed.

>> (2) Reviewed-by: Laszlo Ersek 

Thanks!

>>
>> A *future* improvement (meant just for this surgical reset handler --
>> not meaning any large cfi01 overhaul!) could be the addition of a trace
>> point, at the top of pflash_cfi01_system_reset().
>>
>> But that is strictly "nice to have", and not necessary to include in the
>> present bugfix.
>>
>>
>> (3) Using OVMF IA32X64 (including the edk2 SMM stack), I've
>> regression-tested this patch, on top of v4.1.0-rc1, with KVM. As follows:
>>
>> (3a) Normal reboot from the UEFI shell ("reset -c" command)
>>
>> (3b) Normal reboot from the Linux guest prompt ("reboot" command)
>>
>> (3c1) Reset as part of ACPI S3 suspend/resume
>> (3c2) then use "efibootmgr -n / -N" to write to pflash (by virtue of
>> setting / deleting the standardized BootNext UEFI variable)
>>
>> (3d1) Boot to setup TUI with SB enabled
>> (3d2) erase Platform Key in setup TUI (disables SB)
>> (3d3) reboot from within setup TUI
>> (3d4) proceed to UEFI shell
>> (3d5) enable SB with EnrollDefaultKeys.efi
>> (3d6) reboot from UEFI shell
>> (3d7) proceeed to Linux guest
>> (3d8) verify SB enablement (dmesg, "mokutil --sb-state")
>>
>> (As an added exercise, step (3d4) triggered an "FTW" (fault tolerant
>> write) "reclaim" (basically a defragmentation of the journaled
>> "filesystem" that the firmware keeps in the flash, as a logical "middle
>> layer"), and that worked fine too.)
>>
>> Regression-tested-by: Laszlo Ersek 
>>
>>
>> (4) I plan to provide R-t-b in the evening from aarch64 KVM too, using
>> the edk2 ArmVirtQemu firmware. Only the first two steps from (3) will be
>> covered (no ACPI S3, no SB).
> 
> Regression-tested-by: Laszlo Ersek 

Thank you a lot again for all your testing, I also noted your steps and
will try to automate them.

Best regards,

Phil.

Re: [Qemu-devel] [Qemu-ppc] [PATCH] Allow bit 15 to be set to 1 on slbmfee and slbmfev

[Ivan Warren via Qemu-devel]

Le 7/18/2019 à 7:19 PM, Greg Kurz a écrit :

We usually mention the subsystem name in the subject, ie.

target/ppc: Allow bit 15 to be set to 1 on slbmfee and slbmfev
Gotcha ! Still learning the process as I go. Next time I submit 
something, I'll follow the guidelines more accurately.


On Thu, 18 Jul 2019 14:44:49 +0200
Ivan Warren  wrote:


Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
Per this specification, bit 15 is implementation specific
so it may be 1, but can probably ne safely ignored.


Another typo from me !

s/ne safely/be safely/



Power ISA 2.07B (Power 7/Power 8) indicates the bit is
reserved but some none Linux operating systems do set

s/none Linux/non-Linux

Thanks ! Sorry for the typo !



this bit to 1 when entering the debugger.
So it is likely it is implemented on those systems
but wasn't yet documented.


ISA describes things that are common to several processor types,
but each implementation may do some extra stuff... like giving
a special meaning to an invalid instruction form for example (see
commit fa200c95f7f99ce14b8af25ea0be478c722d3cec). This is supposed
to be documented in the user manual.

Maybe something similar was done with the reserved bit 15, even if I
could fine no trace of that in the Power8 UM... of course. I'll try
to find clues within IBM.

https://openpowerfoundation.org/?resource_lib=power8-processor-users-manual

but it is indeed mentioned in the Power9 UM:

https://openpowerfoundation.org/?resource_lib=power-processor-users-manual

4.10.7.2 SLB Management Instructions

The POWER9 core implements the SLB management instructions as defined in the
Power ISA (Version 3.0B). Specifically, the following instruction details are
noteworthy:
• The slbmfee and slbmfev instructions can read any SLB entry when UPRT = ‘1’,
   if the L-bit in the instruction image is set to a ‘1’. This is an
   implementation-specific feature that will only be used in the future if and
   when the POWER9 processor core supports UPRT = ‘1’ for HPT translation.

Not sure if we support that in TCG, but it doesn't hurt to relax the check
if that's enough to make AIX's debugger happy.

Yep !


Reviewed-by: Greg Kurz 


Signed-off-by: Ivan Warren 
---

The original creator of the patch is "Zhuowei Zhang"
(https://twitter.com/zhuowei) but I couldn't find any e-mail address.


This is the original patch, correct ?

https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e

Indeed !


After speaking with some QEMU folks on irc, it is okay to ignore the lack
of S-o-b because the patch is trivial. But the general rule is to always
require an S-o-b when posting someone else's patch.


Is it good practice to add a S-o-b without the original author's consent 
and/or without an e-mail address ? Although I would very much doubt he 
would have complained.


Anyway, thanks for reviewing and for the tips ! (and sorry for all the 
noise).





   target/ppc/translate.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 4a5de28036..85f8b147ba 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -7064,8 +7064,8 @@ GEN_HANDLER2(mtsr_64b, "mtsr", 0x1F, 0x12, 0x06,
0x0010F801, PPC_SEGMENT_64B),
   GEN_HANDLER2(mtsrin_64b, "mtsrin", 0x1F, 0x12, 0x07, 0x001F0001,
    PPC_SEGMENT_64B),
   GEN_HANDLER2(slbmte, "slbmte", 0x1F, 0x12, 0x0C, 0x001F0001,
PPC_SEGMENT_64B),
-GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001F0001,
PPC_SEGMENT_64B),
-GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001F0001,
PPC_SEGMENT_64B),
+GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001E0001,
PPC_SEGMENT_64B),
+GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001E0001,
PPC_SEGMENT_64B),
   GEN_HANDLER2(slbfee_, "slbfee.", 0x1F, 0x13, 0x1E, 0x001F,
PPC_SEGMENT_64B),
   #endif
   GEN_HANDLER(tlbia, 0x1F, 0x12, 0x0B, 0x03FFFC01, PPC_MEM_TLBIA),
--
2.20.1






smime.p7s
Description: Signature cryptographique S/MIME

Re: [Qemu-devel] [PATCH v2] i386/acpi: fix gint overflow in crs_range_compare

[Michael S. Tsirkin]

On Thu, Jul 18, 2019 at 07:14:23PM +0300, Evgeny Yakovlev wrote:
> When very large regions (32GB sized in our case, PCI pass-through of GPUs)
> are compared substraction result does not fit into gint.
> 
> As a result crs_replace_with_free_ranges does not get sorted ranges and
> incorrectly computes PCI64 free space regions. Which then makes linux
> guest complain about device and PCI64 hole intersection and device
> becomes unusable.
> 
> Fix that by returning exactly fitting ranges.
> 
> Also fix indentation of an entire crs_replace_with_free_ranges to make
> checkpatch happy.
> 
> Signed-off-by: Evgeny Yakovlev 

queued, thanks a lot!

> ---
> v2:
> entire crs_replace_with_free_ranges was indented with 5 spaces, including my 
> change.
> fix that as well
> 
>  hw/i386/acpi-build.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index d281ffa..e7b756b 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -755,10 +755,16 @@ static void crs_range_set_free(CrsRangeSet *range_set)
>  
>  static gint crs_range_compare(gconstpointer a, gconstpointer b)
>  {
> - CrsRangeEntry *entry_a = *(CrsRangeEntry **)a;
> - CrsRangeEntry *entry_b = *(CrsRangeEntry **)b;
> +CrsRangeEntry *entry_a = *(CrsRangeEntry **)a;
> +CrsRangeEntry *entry_b = *(CrsRangeEntry **)b;
>  
> - return (int64_t)entry_a->base - (int64_t)entry_b->base;
> +if (entry_a->base < entry_b->base) {
> +return -1;
> +} else if (entry_a->base > entry_b->base) {
> +return 1;
> +} else {
> +return 0;
> +}
>  }
>  
>  /*
> -- 
> 2.7.4

Re: [Qemu-devel] [PULL 08/10] target/arm: Conditionalize some asserts on aarch32 support

[Laszlo Ersek]

On 07/18/19 14:30, Peter Maydell wrote:
> On Wed, 17 Jul 2019 at 16:08, Laszlo Ersek  wrote:
>>
>> On 07/17/19 15:46, Peter Maydell wrote:
>>> On Wed, 17 Jul 2019 at 14:36, Philippe Mathieu-Daudé  
>>> wrote:
 I still wonder why this didn't assert on Peter's setup.
>>>
>>> My setup does not assert because my host kernel correctly
>>> provides the ID register values to QEMU. Laszlo's appears
>>> to be providing all-zeroes, which then obviously breaks
>>> assertions being made about the sanity of those ID register
>>> values...
>>
>> OK. Can you suggest a location that I should check in the host kernel?
> 
> I was about to write out the process of how we get these values
> from the kernel, but as the first step of that I read through
> QEMU's target/arm/kvm64.c:kvm_arm_get_host_cpu_features(),
> which is the function which reads these values using the
> KVM_GET_ONE_REG ioctl. It starts with an attempt to read
> ID_AA64PFR0, and has a comment for the error-handling case:
> 
> /*
>  * Before v4.15, the kernel only exposed a limited number of system
>  * registers, not including any of the interesting AArch64 ID regs.
>  * For the most part we could leave these fields as zero with minimal
>  * effect, since this does not affect the values seen by the guest.
>  *
>  * However, it could cause problems down the line for QEMU,
>  * so provide a minimal v8.0 default.
>  *
>  * ??? Could read MIDR and use knowledge from cpu64.c.
>  * ??? Could map a page of memory into our temp guest and
>  * run the tiniest of hand-crafted kernels to extract
>  * the values seen by the guest.
>  * ??? Either of these sounds like too much effort just
>  * to work around running a modern host kernel.
>  */
> 
> I have 4.15, and don't hit this assert; you have 4.14 and do,
> so I think you're going to be going through this codepath which
> currently sets only ahcf->isar.id_aa64pfr0 and none of the other
> ID register fields in the isar struct.
> 
> I'm not sure exactly which kernel commits added the ID register
> reading support. (The relevant kernel code is in
> arch/arm64/kvm/sys_regs.c I think.)

I compared that file between the downstream kernel source and upstream v4.15, 
and it looks like the following series (indeed released as part of v4.15) is 
what's missing down-stream, for this particular use case:

 1  27e64b4be4b8 regset: Add support for dynamically sized regsets
 2  94ef7ecbdf6f arm64: fpsimd: Correctly annotate exception helpers called 
from asm
 3  abf73988a7c2 arm64: signal: Verify extra data is user-readable in 
sys_rt_sigreturn
 4  93390c0a1b20 arm64: KVM: Hide unsupported AArch64 CPU features from 
guests
 5  b472db6cf8c6 arm64: efi: Add missing Kconfig dependency on 
KERNEL_MODE_NEON
 6  38b9aeb32fa7 arm64: Port deprecated instruction emulation to new sysctl 
interface
 7  9cf5b54fafed arm64: fpsimd: Simplify uses of 
{set,clear}_ti_thread_flag()
 8  672365649cca arm64/sve: System register and exception syndrome 
definitions
 9  1fc5dce78ad1 arm64/sve: Low-level SVE architectural state manipulation 
functions
10  ddd25ad1fde8 arm64/sve: Kconfig update and conditional compilation 
support
11  d0b8cd318788 arm64/sve: Signal frame and context structure definition
12  22043a3c082a arm64/sve: Low-level CPU setup
13  bc0ee4760364 arm64/sve: Core task context handling
14  79ab047c75d6 arm64/sve: Support vector length resetting for new 
processes
15  8cd969d28fd2 arm64/sve: Signal handling support
16  7582e22038a2 arm64/sve: Backend logic for setting the vector length
17  8f1eec57cdcc arm64: cpufeature: Move sys_caps_initialised declarations
18  2e0f2478ea37 arm64/sve: Probe SVE capabilities and usable vector lengths
19  1bd3f93641ec arm64/sve: Preserve SVE registers around kernel-mode NEON 
use
20  fdfa976cae5c arm64/sve: Preserve SVE registers around EFI runtime 
service calls
21  43d4da2c45b2 arm64/sve: ptrace and ELF coredump support
22  2d2123bc7c7f arm64/sve: Add prctl controls for userspace vector length 
management
23  4ffa09a939ab arm64/sve: Add sysctl to set the default vector length for 
new processes
24  17eed27b02da arm64/sve: KVM: Prevent guests from using SVE
25  aac45ffd1f8e arm64/sve: KVM: Treat guest SVE use as undefined 
instruction execution
26  07d79fe7c223 arm64/sve: KVM: Hide SVE from CPU features exposed to 
guests
27  43994d824e84 arm64/sve: Detect SVE and activate runtime support
28  ce6990813f15 arm64/sve: Add documentation

The differences found by the simple "diff" that I mention above are mainly due 
to commit #4 (93390c0a1b20, "arm64: KVM: Hide unsupported AArch64 CPU features 
from guests", 2017-11-03).

I found a (likely non-final) version of the cover letter too, here: 
https://www.spinics.net/lists/arm-kernel/msg599528.html

I guess I 

Re: [Qemu-devel] [PATCH v7 10/13] vfio: Add load state functions to SaveVMHandlers

[Kirti Wankhede]

On 7/12/2019 8:22 AM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:17PM +0800, Kirti Wankhede wrote:
>> Flow during _RESUMING device state:
>> - If Vendor driver defines mappable region, mmap migration region.
>> - Load config state.
>> - For data packet, till VFIO_MIG_FLAG_END_OF_STATE is not reached
>> - read data_size from packet, read buffer of data_size
>> - read data_offset from where QEMU should write data.
>> if region is mmaped, write data of data_size to mmaped region.
>> - write data_size.
>> In case of mmapped region, write to data_size indicates kernel
>> driver that data is written in staging buffer.
>> - if region is trapped, pwrite() data of data_size from data_offset.
>> - Repeat above until VFIO_MIG_FLAG_END_OF_STATE.
>> - Unmap migration region.
>>
>> For user, data is opaque. User should write data in the same order as
>> received.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c  | 162 
>> +++
>>  hw/vfio/trace-events |   3 +
>>  2 files changed, 165 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 4e9b4cce230b..5fb4c5329ede 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -249,6 +249,26 @@ static int vfio_save_device_config_state(QEMUFile *f, 
>> void *opaque)
>>  return qemu_file_get_error(f);
>>  }
>>  
>> +static int vfio_load_device_config_state(QEMUFile *f, void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +uint64_t data;
>> +
>> +if (vbasedev->ops && vbasedev->ops->vfio_load_config) {
>> +vbasedev->ops->vfio_load_config(vbasedev, f);
>> +}
>> +
>> +data = qemu_get_be64(f);
>> +if (data != VFIO_MIG_FLAG_END_OF_STATE) {
>> +error_report("%s: Failed loading device config space, "
>> + "end flag incorrect 0x%"PRIx64, vbasedev->name, data);
>> +return -EINVAL;
>> +}
>> +
>> +trace_vfio_load_device_config_state(vbasedev->name);
>> +return qemu_file_get_error(f);
>> +}
>> +
>>  /* -- */
>>  
>>  static int vfio_save_setup(QEMUFile *f, void *opaque)
>> @@ -421,12 +441,154 @@ static int vfio_save_complete_precopy(QEMUFile *f, 
>> void *opaque)
>>  return ret;
>>  }
>>  
>> +static int vfio_load_setup(QEMUFile *f, void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +int ret = 0;
>> +
>> +if (migration->region.buffer.mmaps) {
>> +ret = vfio_region_mmap(>region.buffer);
>> +if (ret) {
>> +error_report("%s: Failed to mmap VFIO migration region %d: %s",
>> + vbasedev->name, migration->region.index,
>> + strerror(-ret));
>> +return ret;
>> +}
>> +}
>> +
>> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_RESUMING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RESUMING", vbasedev->name);
>> +}
>> +return ret;
>> +}
>> +
>> +static int vfio_load_cleanup(void *opaque)
>> +{
>> +vfio_save_cleanup(opaque);
>> +return 0;
>> +}
>> +
>> +static int vfio_load_state(QEMUFile *f, void *opaque, int version_id)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +int ret = 0;
>> +uint64_t data, data_size;
>> +
> I think checking of version_id is still needed.
> 

Checking version_id with what value?

Thanks,
Kirti

Re: [Qemu-devel] [PATCH v7 02/13] vfio: Add function to unmap VFIO region

[Kirti Wankhede]

On 7/16/2019 9:59 PM, Cornelia Huck wrote:
> On Tue, 9 Jul 2019 15:19:09 +0530
> Kirti Wankhede  wrote:
> 
>> This function is used in follwing patch in this series.
> 
> "This function will be used for the migration region." ?
> 
> ("This series" will be a bit confusing when this has been merged :)
> 

Sure. Changing it in next version.

Thanks,
Kirti

>> Migration region is mmaped when migration starts and will be unmapped when
>> migration is complete.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/common.c  | 20 
>>  hw/vfio/trace-events  |  1 +
>>  include/hw/vfio/vfio-common.h |  1 +
>>  3 files changed, 22 insertions(+)
> 
> Reviewed-by: Cornelia Huck 
> 

Re: [Qemu-devel] [PATCH v7 09/13] vfio: Add save state functions to SaveVMHandlers

[Kirti Wankhede]

On 7/12/2019 8:14 AM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:16PM +0800, Kirti Wankhede wrote:
>> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
>> functions. These functions handles pre-copy and stop-and-copy phase.
>>
>> In _SAVING|_RUNNING device state or pre-copy phase:
>> - read pending_bytes
>> - read data_offset - indicates kernel driver to write data to staging
>>   buffer which is mmapped.
>> - read data_size - amount of data in bytes written by vendor driver in 
>> migration
>>   region.
>> - if data section is trapped, pread() from data_offset of data_size.
>> - if data section is mmaped, read mmaped buffer of data_size.
>> - Write data packet to file stream as below:
>> {VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data,
>> VFIO_MIG_FLAG_END_OF_STATE }
>>
>> In _SAVING device state or stop-and-copy phase
>> a. read config space of device and save to migration file stream. This
>>doesn't need to be from vendor driver. Any other special config state
>>from driver can be saved as data in following iteration.
>> b. read pending_bytes
>> c. read data_offset - indicates kernel driver to write data to staging
>>buffer which is mmapped.
>> d. read data_size - amount of data in bytes written by vendor driver in
>>migration region.
>> e. if data section is trapped, pread() from data_offset of data_size.
>> f. if data section is mmaped, read mmaped buffer of data_size.
>> g. Write data packet as below:
>>{VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data}
>> h. iterate through steps b to g while (pending_bytes > 0)
>> i. Write {VFIO_MIG_FLAG_END_OF_STATE}
>>
>> When data region is mapped, its user's responsibility to read data from
>> data_offset of data_size before moving to next steps.
>>
>> .save_live_iterate runs outside the iothread lock in the migration case, 
>> which
>> could race with asynchronous call to get dirty page list causing data 
>> corruption
>> in mapped migration region. Mutex added here to serial migration buffer read
>> operation.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c  | 246 
>> +++
>>  hw/vfio/trace-events |   6 ++
>>  2 files changed, 252 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 0597a45fda2d..4e9b4cce230b 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -117,6 +117,138 @@ static int vfio_migration_set_state(VFIODevice 
>> *vbasedev, uint32_t state)
>>  return 0;
>>  }
>>  
>> +static void *find_data_region(VFIORegion *region,
>> +  uint64_t data_offset,
>> +  uint64_t data_size)
>> +{
>> +void *ptr = NULL;
>> +int i;
>> +
>> +for (i = 0; i < region->nr_mmaps; i++) {
>> +if ((data_offset >= region->mmaps[i].offset) &&
>> +(data_offset < region->mmaps[i].offset + region->mmaps[i].size) 
>> &&
>> +(data_size <= region->mmaps[i].size)) {
>> +ptr = region->mmaps[i].mmap + (data_offset -
>> +   region->mmaps[i].offset);
>> +break;
>> +}
>> +}
>> +return ptr;
>> +}
>> +
>> +static int vfio_save_buffer(QEMUFile *f, VFIODevice *vbasedev)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +VFIORegion *region = >region.buffer;
>> +uint64_t data_offset = 0, data_size = 0;
>> +int ret;
>> +
>> +ret = pread(vbasedev->fd, _offset, sizeof(data_offset),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + data_offset));
>> +if (ret != sizeof(data_offset)) {
>> +error_report("%s: Failed to get migration buffer data offset %d",
>> + vbasedev->name, ret);
>> +return -EINVAL;
>> +}
>> +
>> +ret = pread(vbasedev->fd, _size, sizeof(data_size),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + data_size));
>> +if (ret != sizeof(data_size)) {
>> +error_report("%s: Failed to get migration buffer data size %d",
>> + vbasedev->name, ret);
>> +return -EINVAL;
>> +}
>> +
>> +if (data_size > 0) {
>> +void *buf = NULL;
>> +bool buffer_mmaped;
>> +
>> +if (region->mmaps) {
>> +buf = find_data_region(region, data_offset, data_size);
>> +}
>> +
>> +buffer_mmaped = (buf != NULL) ? true : false;
>> +
>> +if (!buffer_mmaped) {
>> +buf = g_try_malloc0(data_size);
>> +if (!buf) {
>> +error_report("%s: Error allocating buffer ", __func__);
>> +return -ENOMEM;
>> +}
>> +
>> +ret = pread(vbasedev->fd, buf, data_size,
>> +region->fd_offset + data_offset);
>> 

Re: [Qemu-devel] [PATCH v7 11/13] vfio: Add function to get dirty page list

[Kirti Wankhede]

On 7/12/2019 6:03 AM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:18PM +0800, Kirti Wankhede wrote:
>> Dirty page tracking (.log_sync) is part of RAM copying state, where
>> vendor driver provides the bitmap of pages which are dirtied by vendor
>> driver through migration region and as part of RAM copy, those pages
>> gets copied to file stream.
>>
>> To get dirty page bitmap:
>> - write start address, page_size and pfn count.
>> - read count of pfns copied.
>> - Vendor driver should return 0 if driver doesn't have any page to
>>   report dirty in given range.
>> - Vendor driver should return -1 to mark all pages dirty for given range.
>> - read data_offset, where vendor driver has written bitmap.
>> - read bitmap from the region or mmaped part of the region.
>> - Iterate above steps till page bitmap for all requested pfns are copied.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c   | 123 
>> ++
>>  hw/vfio/trace-events  |   1 +
>>  include/hw/vfio/vfio-common.h |   2 +
>>  3 files changed, 126 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 5fb4c5329ede..ca1a8c0f5f1f 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -269,6 +269,129 @@ static int vfio_load_device_config_state(QEMUFile *f, 
>> void *opaque)
>>  return qemu_file_get_error(f);
>>  }
>>  
>> +void vfio_get_dirty_page_list(VFIODevice *vbasedev,
>> +  uint64_t start_pfn,
>> +  uint64_t pfn_count,
>> +  uint64_t page_size)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +VFIORegion *region = >region.buffer;
>> +uint64_t count = 0;
>> +int64_t copied_pfns = 0;
>> +int64_t total_pfns = pfn_count;
>> +int ret;
>> +
>> +qemu_mutex_lock(>lock);
>> +
>> +while (total_pfns > 0) {
>> +uint64_t bitmap_size, data_offset = 0;
>> +uint64_t start = start_pfn + count;
>> +void *buf = NULL;
>> +bool buffer_mmaped = false;
>> +
>> +ret = pwrite(vbasedev->fd, , sizeof(start),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  start_pfn));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty pages start address %d 
>> %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +ret = pwrite(vbasedev->fd, _size, sizeof(page_size),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  page_size));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty page size %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +ret = pwrite(vbasedev->fd, _pfns, sizeof(total_pfns),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  total_pfns));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty page total pfns %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +/* Read copied dirty pfns */
>> +ret = pread(vbasedev->fd, _pfns, sizeof(copied_pfns),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + copied_pfns));
>> +if (ret < 0) {
>> +error_report("%s: Failed to get dirty pages bitmap count %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_NONE) {
>> +/*
>> + * copied_pfns could be 0 if driver doesn't have any page to
>> + * report dirty in given range
>> + */
>> +break;
>> +} else if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_ALL) {
>> +/* Mark all pages dirty for this range */
>> +cpu_physical_memory_set_dirty_range(start_pfn * page_size,
>> +pfn_count * page_size,
>> +DIRTY_MEMORY_MIGRATION);
> seesm pfn_count here is not right

Changing it to total_pfns in next version

Thanks,
Kirti

>> +break;
>> +}
>> +
>> +bitmap_size = (BITS_TO_LONGS(copied_pfns) + 1) * sizeof(unsigned 
>> long);
>> +
>> +ret = pread(vbasedev->fd, _offset, sizeof(data_offset),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + 

Re: [Qemu-devel] [PATCH-for-4.1 v7 1/1] hw/block/pflash_cfi01: Add missing DeviceReset() handler

[Laszlo Ersek]

On 07/18/19 17:03, Laszlo Ersek wrote:
> On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
>> To avoid incoherent states when the machine resets (see but report
> 
> (1) For the PULL request, please fix the typo: s/but/bug/
> 
>> below), add the device reset callback.
>>
>> A "system reset" sets the device state machine in READ_ARRAY mode
>> and, after some delay, set the SR.7 READY bit.
>>
>> Since we do not model timings, we set the SR.7 bit directly.
>>
>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1678713
>> Reported-by: Laszlo Ersek 
>> Reviewed-by: John Snow 
>> Reviewed-by: Alistair Francis 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/block/pflash_cfi01.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
>> index 435be1e35c..a1ec1faae5 100644
>> --- a/hw/block/pflash_cfi01.c
>> +++ b/hw/block/pflash_cfi01.c
>> @@ -865,6 +865,24 @@ static void pflash_cfi01_realize(DeviceState *dev, 
>> Error **errp)
>>  pfl->cfi_table[0x3f] = 0x01; /* Number of protection fields */
>>  }
>>  
>> +static void pflash_cfi01_system_reset(DeviceState *dev)
>> +{
>> +PFlashCFI01 *pfl = PFLASH_CFI01(dev);
>> +
>> +/*
>> + * The command 0x00 is not assigned by the CFI open standard,
>> + * but QEMU historically uses it for the READ_ARRAY command (0xff).
>> + */
>> +pfl->cmd = 0x00;
>> +pfl->wcycle = 0;
>> +memory_region_rom_device_set_romd(>mem, true);
>> +/*
>> + * The WSM ready timer occurs at most 150ns after system reset.
>> + * This model deliberately ignores this delay.
>> + */
>> +pfl->status = 0x80;
>> +}
>> +
>>  static Property pflash_cfi01_properties[] = {
>>  DEFINE_PROP_DRIVE("drive", PFlashCFI01, blk),
>>  /* num-blocks is the number of blocks actually visible to the guest,
>> @@ -909,6 +927,7 @@ static void pflash_cfi01_class_init(ObjectClass *klass, 
>> void *data)
>>  {
>>  DeviceClass *dc = DEVICE_CLASS(klass);
>>  
>> +dc->reset = pflash_cfi01_system_reset;
>>  dc->realize = pflash_cfi01_realize;
>>  dc->props = pflash_cfi01_properties;
>>  dc->vmsd = _pflash;
>>
> 
> (2) Reviewed-by: Laszlo Ersek 
> 
> A *future* improvement (meant just for this surgical reset handler --
> not meaning any large cfi01 overhaul!) could be the addition of a trace
> point, at the top of pflash_cfi01_system_reset().
> 
> But that is strictly "nice to have", and not necessary to include in the
> present bugfix.
> 
> 
> (3) Using OVMF IA32X64 (including the edk2 SMM stack), I've
> regression-tested this patch, on top of v4.1.0-rc1, with KVM. As follows:
> 
> (3a) Normal reboot from the UEFI shell ("reset -c" command)
> 
> (3b) Normal reboot from the Linux guest prompt ("reboot" command)
> 
> (3c1) Reset as part of ACPI S3 suspend/resume
> (3c2) then use "efibootmgr -n / -N" to write to pflash (by virtue of
> setting / deleting the standardized BootNext UEFI variable)
> 
> (3d1) Boot to setup TUI with SB enabled
> (3d2) erase Platform Key in setup TUI (disables SB)
> (3d3) reboot from within setup TUI
> (3d4) proceed to UEFI shell
> (3d5) enable SB with EnrollDefaultKeys.efi
> (3d6) reboot from UEFI shell
> (3d7) proceeed to Linux guest
> (3d8) verify SB enablement (dmesg, "mokutil --sb-state")
> 
> (As an added exercise, step (3d4) triggered an "FTW" (fault tolerant
> write) "reclaim" (basically a defragmentation of the journaled
> "filesystem" that the firmware keeps in the flash, as a logical "middle
> layer"), and that worked fine too.)
> 
> Regression-tested-by: Laszlo Ersek 
> 
> 
> (4) I plan to provide R-t-b in the evening from aarch64 KVM too, using
> the edk2 ArmVirtQemu firmware. Only the first two steps from (3) will be
> covered (no ACPI S3, no SB).

Regression-tested-by: Laszlo Ersek 

Re: [Qemu-devel] [PATCH v7 00/13] Add migration support for VFIO device

[Kirti Wankhede]

On 7/12/2019 6:02 AM, Yan Zhao wrote:
> On Fri, Jul 12, 2019 at 03:08:31AM +0800, Kirti Wankhede wrote:
>>
>>
>> On 7/11/2019 9:53 PM, Dr. David Alan Gilbert wrote:
>>> * Yan Zhao (yan.y.z...@intel.com) wrote:
 On Thu, Jul 11, 2019 at 06:50:12PM +0800, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
>> Hi Kirti,
>> There are still unaddressed comments to your patches v4.
>> Would you mind addressing them?
>>
>> 1. should we register two migration interfaces simultaneously
>> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04750.html)
>
> Please don't do this.
> As far as I'm aware we currently only have one device that does that
> (vmxnet3) and a patch has just been posted that fixes/removes that.
>
> Dave
>
 hi Dave,
 Thanks for notifying this. but if we want to support postcopy in future,
 after device stops, what interface could we use to transfer data of
 device state only?
 for postcopy, when source device stops, we need to transfer only
 necessary device state to target vm before target vm starts, and we
 don't want to transfer device memory as we'll do that after target vm
 resuming.
>>>
>>> Hmm ok, lets see; that's got to happen in the call to:
>>> qemu_savevm_state_complete_precopy(fb, false, false);
>>> that's made from postcopy_start.
>>>  (the false's are iterable_only and inactivate_disks)
>>>
>>> and at that time I believe the state is POSTCOPY_ACTIVE, so in_postcopy
>>> is true.
>>>
>>> If you're doing postcopy, then you'll probably define a has_postcopy()
>>> function, so qemu_savevm_state_complete_precopy will skip the
>>> save_live_complete_precopy call from it's loop for at least two of the
>>> reasons in it's big if.
>>>
>>> So you're right; you need the VMSD for this to happen in the second
>>> loop in qemu_savevm_state_complete_precopy.  Hmm.
>>>
>>> Now, what worries me, and I don't know the answer, is how the section
>>> header for the vmstate and the section header for an iteration look
>>> on the stream; how are they different?
>>>
>>
>> I don't have way to test postcopy migration - is one of the major reason
>> I had not included postcopy support in this patchset and clearly called
>> out in cover letter.
>> This patchset is thoroughly tested for precopy migration.
>> If anyone have hardware that supports fault, then I would prefer to add
>> postcopy support as incremental change later which can be tested before
>> submitting.
>>
>> Just a suggestion, instead of using VMSD, is it possible to have some
>> additional check to call save_live_complete_precopy from
>> qemu_savevm_state_complete_precopy?
>>
>>

>> 2. in each save iteration, how much data is to be saved
>> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04683.html)
>>
>>> how big is the data_size ?
>>> if this size is too big, it may take too much time and block others.
>>
>> I do had mentioned this in the comment about the structure in vfio.h
>> header. data_size will be provided by vendor driver and obviously will
>> not be greater that migration region size. Vendor driver should be
>> responsible to keep its solution optimized.
>>
> if the data_size is no big than migration region size, and each
> iteration only saves data of data_size, i'm afraid it will cause
> prolonged down time. after all, the migration region size cannot be very
> big.

As I mentioned above, its vendor driver responsibility to keep its
solution optimized.
A good behaving vendor driver should not cause unnecessary prolonged
down time.

> Also, if vendor driver determines how much data to save in each
> iteration alone, and no checks in qemu, it may cause other devices'
> migration time be squeezed.
> 

Sorry, how will that squeeze other device's migration time?

>>
>> 3. do we need extra interface to get data for device state only
>> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04812.html)
>>
>> I don't think so. Opaque Device data from vendor driver can include
>> device state and device memory. Vendor driver who is managing his device
>> can decide how to place data over the stream.
>>
> I know current design is opaque device data. then to support postcopy,
> we may have to add extra device state like in-postcopy. but postcopy is
> more like a qemu state and is not a device state.

One bit from device_state can be used to inform vendor driver about
postcopy, when postcopy support will be added.

> to address it elegantly, may we add an extra interface besides
> vfio_save_buffer() to get data for device state only?
> 

When in postcopy state, based on device_state flag, vendor driver can
copy device state first in migration region, I still think there is no
need to separate device state and device memory.

>> 4. definition of dirty page copied_pfn
>> (https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05592.html)
>>
>>
>> This was inline to discussion 

[Qemu-devel] [Bug 1837094] Re: UndefinedBehaviorSanitizer crash around slirp::ip_reass()

[Philippe Mathieu-Daudé]

** Description changed:

  tag: v4.1.0-rc1
  
  ./configure --enable-sanitizers --extra-cflags=-O1
  
- ==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 
0x0008 (pc 0x0046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130)
+ ==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 
0x0008 (pc 0x561ad346d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 
T26130)
  ==26130==The signal is caused by a WRITE memory access.
  ==26130==Hint: address points to the zero page.
- #0 0x561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
- #1 0x561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
- #2 0x561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18
+ #0 0x561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
+ #1 0x561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
+ #2 0x561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18
  
  I only had access to the last packet which isn't the culprit, I'm now
  seeing how to log the network traffic of the guest to provide more
  useful information.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837094

Title:
  UndefinedBehaviorSanitizer crash around slirp::ip_reass()

Status in QEMU:
  New

Bug description:
  tag: v4.1.0-rc1

  ./configure --enable-sanitizers --extra-cflags=-O1

  ==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 
0x0008 (pc 0x561ad346d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 
T26130)
  ==26130==The signal is caused by a WRITE memory access.
  ==26130==Hint: address points to the zero page.
  #0 0x561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
  #1 0x561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
  #2 0x561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18

  I only had access to the last packet which isn't the culprit, I'm now
  seeing how to log the network traffic of the guest to provide more
  useful information.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837094/+subscriptions

[Qemu-devel] [Bug 1837094] [NEW] UndefinedBehaviorSanitizer crash around slirp::ip_reass()

[Philippe Mathieu-Daudé]

Public bug reported:

tag: v4.1.0-rc1

./configure --enable-sanitizers --extra-cflags=-O1

==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 
0x0008 (pc 0x0046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130)
==26130==The signal is caused by a WRITE memory access.
==26130==Hint: address points to the zero page.
#0 0x561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
#1 0x561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
#2 0x561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18

I only had access to the last packet which isn't the culprit, I'm now
seeing how to log the network traffic of the guest to provide more
useful information.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: slirp

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837094

Title:
  UndefinedBehaviorSanitizer crash around slirp::ip_reass()

Status in QEMU:
  New

Bug description:
  tag: v4.1.0-rc1

  ./configure --enable-sanitizers --extra-cflags=-O1

  ==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 
0x0008 (pc 0x0046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130)
  ==26130==The signal is caused by a WRITE memory access.
  ==26130==Hint: address points to the zero page.
  #0 0x561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
  #1 0x561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
  #2 0x561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18

  I only had access to the last packet which isn't the culprit, I'm now
  seeing how to log the network traffic of the guest to provide more
  useful information.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837094/+subscriptions

Re: [Qemu-devel] [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result

[John Snow]

On 7/18/19 6:20 AM, no-re...@patchew.org wrote:
> PASS 17 test-bdrv-drain /bdrv-drain/graph-change/drain_all
> =
> ==10263==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6122c1f0 at pc 0x555fd5bd7cb6 bp 0x7f3e853b8680 sp 0x7f3e853b8678
> WRITE of size 1 at 0x6122c1f0 thread T5
> ==10262==WARNING: ASan doesn't fully support makecontext/swapcontext 
> functions and may produce false positives in some cases!
> #0 0x555fd5bd7cb5 in aio_notify /tmp/qemu-test/src/util/async.c:351:9
> #1 0x555fd5bd98eb in qemu_bh_schedule 
> /tmp/qemu-test/src/util/async.c:167:9
> #2 0x555fd5bdcaf0 in aio_co_schedule /tmp/qemu-test/src/util/async.c:464:5

I'm fairly certain that this isn't related to this patch.

Re: [Qemu-devel] [PATCH] Allow bit 15 to be set to 1 on slbmfee and slbmfev

[Greg Kurz]

We usually mention the subsystem name in the subject, ie.

target/ppc: Allow bit 15 to be set to 1 on slbmfee and slbmfev

On Thu, 18 Jul 2019 14:44:49 +0200
Ivan Warren  wrote:

> Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
> as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
> Per this specification, bit 15 is implementation specific
> so it may be 1, but can probably ne safely ignored.
> 
> Power ISA 2.07B (Power 7/Power 8) indicates the bit is
> reserved but some none Linux operating systems do set

s/none Linux/non-Linux

> this bit to 1 when entering the debugger.
> So it is likely it is implemented on those systems
> but wasn't yet documented.
> 

ISA describes things that are common to several processor types,
but each implementation may do some extra stuff... like giving
a special meaning to an invalid instruction form for example (see
commit fa200c95f7f99ce14b8af25ea0be478c722d3cec). This is supposed
to be documented in the user manual.

Maybe something similar was done with the reserved bit 15, even if I
could fine no trace of that in the Power8 UM... of course. I'll try
to find clues within IBM.

https://openpowerfoundation.org/?resource_lib=power8-processor-users-manual

but it is indeed mentioned in the Power9 UM:

https://openpowerfoundation.org/?resource_lib=power-processor-users-manual

4.10.7.2 SLB Management Instructions

The POWER9 core implements the SLB management instructions as defined in the
Power ISA (Version 3.0B). Specifically, the following instruction details are
noteworthy:
• The slbmfee and slbmfev instructions can read any SLB entry when UPRT = ‘1’,
  if the L-bit in the instruction image is set to a ‘1’. This is an
  implementation-specific feature that will only be used in the future if and
  when the POWER9 processor core supports UPRT = ‘1’ for HPT translation.

Not sure if we support that in TCG, but it doesn't hurt to relax the check
if that's enough to make AIX's debugger happy.

Reviewed-by: Greg Kurz 

> Signed-off-by: Ivan Warren 
> ---
> 
> The original creator of the patch is "Zhuowei Zhang" 
> (https://twitter.com/zhuowei) but I couldn't find any e-mail address.
> 

This is the original patch, correct ?

https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e

After speaking with some QEMU folks on irc, it is okay to ignore the lack
of S-o-b because the patch is trivial. But the general rule is to always
require an S-o-b when posting someone else's patch.

>   target/ppc/translate.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 4a5de28036..85f8b147ba 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -7064,8 +7064,8 @@ GEN_HANDLER2(mtsr_64b, "mtsr", 0x1F, 0x12, 0x06, 
> 0x0010F801, PPC_SEGMENT_64B),
>   GEN_HANDLER2(mtsrin_64b, "mtsrin", 0x1F, 0x12, 0x07, 0x001F0001,
>    PPC_SEGMENT_64B),
>   GEN_HANDLER2(slbmte, "slbmte", 0x1F, 0x12, 0x0C, 0x001F0001, 
> PPC_SEGMENT_64B),
> -GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001F0001, 
> PPC_SEGMENT_64B),
> -GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001F0001, 
> PPC_SEGMENT_64B),
> +GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001E0001, 
> PPC_SEGMENT_64B),
> +GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001E0001, 
> PPC_SEGMENT_64B),
>   GEN_HANDLER2(slbfee_, "slbfee.", 0x1F, 0x13, 0x1E, 0x001F, 
> PPC_SEGMENT_64B),
>   #endif
>   GEN_HANDLER(tlbia, 0x1F, 0x12, 0x0B, 0x03FFFC01, PPC_MEM_TLBIA),
> --
> 2.20.1
> 
> 

Re: [Qemu-devel] [PATCH v2] tests/boot_linux_console: add a test for riscv64 + virt

[Chih-Min Chao]

On Thu, Jul 18, 2019 at 11:34 PM Alistair Francis 
wrote:

> On Thu, Jul 18, 2019 at 8:00 AM Chih-Min Chao 
> wrote:
> >
> >
> >
> > On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis 
> wrote:
> >>
> >> On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao 
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis <
> alistai...@gmail.com> wrote:
> >> >>
> >> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé
> >> >>  wrote:
> >> >> >
> >> >> > On 7/16/19 10:43 PM, Alistair Francis wrote:
> >> >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <
> chihmin.c...@sifive.com> wrote:
> >> >> > >>
> >> >> > >>
> >> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <
> alistai...@gmail.com> wrote:
> >> >> > >>>
> >> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé
> >> >> > >>>  wrote:
> >> >> > 
> >> >> >  On 7/15/19 1:09 PM, Chih-Min Chao wrote:
> >> >> > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé
> >> >> > > mailto:phi...@redhat.com>> wrote:
> >> >> > >
> >> >> > > On 7/15/19 11:08 AM, Chih-Min Chao wrote:
> >> >> > > > Similar to the mips + malta test, it boots a Linux
> kernel on a virt
> >> >> > > > board and verify the serial is working.  Also, it
> relies on the serial
> >> >> > > > device set by the machine itself.
> >> >> > > >
> >> >> > > > If riscv64 is a target being built, "make
> check-acceptance" will
> >> >> > > > automatically include this test by the use of the
> "arch:riscv64" tags.
> >> >> > > >
> >> >> > > > Alternatively, this test can be run using:
> >> >> > > >
> >> >> > > >   $ avocado run -t arch:riscv64 tests/acceptance
> >> >> > > >
> >> >> > > > packages
> >> >> > > >   debian official
> >> >> > > > binutils-riscv64-linux-gnu_2.32-8
> >> >> > > > opensbi_0.4-1_all
> >> >> > > > linux-image-4.19.0-5-riscv64 4.19.37-4
> >> >> > > >   third-party
> >> >> > > >
> >> >> > >
> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz
> >> >> > > > (the repo is also used in mips target acceptance)
> >> >> > > >
> >> >> > > > Signed-off-by: Chih-Min Chao  >> >> > > >
> >> >> > > > ---
> >> >> > > >  .travis.yml|  2 +-
> >> >> > > >  tests/acceptance/boot_linux_console.py | 66
> >> >> > > ++
> >> >> > > >  2 files changed, 67 insertions(+), 1 deletion(-)
> >> >> > > >
> >> >> > > > diff --git a/.travis.yml b/.travis.yml
> >> >> > > > index 5d3d6ee..21fcead 100644
> >> >> > > > --- a/.travis.yml
> >> >> > > > +++ b/.travis.yml
> >> >> > > > @@ -232,7 +232,7 @@ matrix:
> >> >> > > >
> >> >> > > >  # Acceptance (Functional) tests
> >> >> > > >  - env:
> >> >> > > > -- CONFIG="--python=/usr/bin/python3
> >> >> > >
>  
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu"
> >> >> > > > +- CONFIG="--python=/usr/bin/python3
> >> >> > >
>  
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu"
> >> >> > > >  - TEST_CMD="make check-acceptance"
> >> >> > > >after_failure:
> >> >> > > >  - cat tests/results/latest/job.log
> >> >> > > > diff --git a/tests/acceptance/boot_linux_console.py
> >> >> > > b/tests/acceptance/boot_linux_console.py
> >> >> > > > index 3215950..0f638bc 100644
> >> >> > > > --- a/tests/acceptance/boot_linux_console.py
> >> >> > > > +++ b/tests/acceptance/boot_linux_console.py
> >> >> > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test):
> >> >> > > >  self.vm.launch()
> >> >> > > >  console_pattern = 'Kernel command line: %s' %
> >> >> > > kernel_command_line
> >> >> > > >  self.wait_for_console_pattern(console_pattern)
> >> >> > > > +
> >> >> > > > +def test_riscv64_virt(self):
> >> >> > > > +"""
> >> >> > > > +:avocado: tags=arch:riscv64
> >> >> > > > +:avocado: tags=machine:virt
> >> >> > > > +"""
> >> >> > > > +deb_url = ('
> https://snapshot.debian.org/archive/debian/'
> >> >> > > > +
>  '20190424T171759Z/pool/main/b/binutils/'
> >> >> > > > +
> >> >> > >  'binutils-riscv64-linux-gnu_2.32-8_amd64.deb')
> >> >> > > > +deb_hash =
> ('7fe376fd4452696c03acd508d6d613ca553ea15e')
> >> >> > > > +deb_path = self.fetch_asset(deb_url,
> asset_hash=deb_hash)
> >> >> > > > +

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3] ppc: make idle_timer a per-cpu variable

[Greg Kurz]

On Thu, 18 Jul 2019 10:21:28 -0500
Shivaprasad G Bhat  wrote:

> The current code is broken for more than vcpu as
> each thread would overwrite and there were memory leaks.
> 
> Make it part of PowerPCCPU so that every thread has a
> separate one. Avoid using the timer_new_ns which is
> not the preferred way to create timers.
> 
> Signed-off-by: Shivaprasad G Bhat 
> ---
>  v2: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg04023.html
>  Changes from v2:
>v2 just looked at avoiding the memory leak.
>This patch incorporates all of Greg's suggestions.
> 
>  target/ppc/cpu.h |1 +
>  target/ppc/kvm.c |   31 ---
>  2 files changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index c9beba2a5c..521086d91a 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1190,6 +1190,7 @@ struct PowerPCCPU {
>  void *machine_data;
>  int32_t node_id; /* NUMA node this CPU belongs to */
>  PPCHash64Options *hash64_opts;
> +QEMUTimer idle_timer;
>  
>  /* Fields related to migration compatibility hacks */
>  bool pre_2_8_migration;
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 8a06d3171e..6e1b96bb0a 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -87,18 +87,6 @@ static int cap_large_decr;
>  
>  static uint32_t debug_inst_opcode;
>  
> -/*
> - * XXX We have a race condition where we actually have a level triggered
> - * interrupt, but the infrastructure can't expose that yet, so the guest
> - * takes but ignores it, goes to sleep and never gets notified that 
> there's
> - * still an interrupt pending.
> - *
> - * As a quick workaround, let's just wake up again 20 ms after we 
> injected
> - * an interrupt. That way we can assure that we're always reinjecting
> - * interrupts in case the guest swallowed them.
> - */
> -static QEMUTimer *idle_timer;
> -
>  static void kvm_kick_cpu(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -491,7 +479,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  return ret;
>  }
>  
> -idle_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, kvm_kick_cpu, cpu);
> +timer_init_ns(>idle_timer, QEMU_CLOCK_VIRTUAL, kvm_kick_cpu, cpu);
>  
>  switch (cenv->mmu_model) {
>  case POWERPC_MMU_BOOKE206:
> @@ -523,6 +511,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  
>  int kvm_arch_destroy_vcpu(CPUState *cs)
>  {
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
> +
> +timer_deinit(>idle_timer);

As stated in the timer.h header file, timer_del() should always be called
before timer_deinit().

With that fixed:

Reviewed-by: Greg Kurz 

> +
>  return 0;
>  }
>  
> @@ -1379,8 +1371,17 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run 
> *run)
>  printf("cpu %d fail inject %x\n", cs->cpu_index, irq);
>  }
>  
> -/* Always wake up soon in case the interrupt was level based */
> -timer_mod(idle_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> +/*
> + * XXX We have a race condition where we actually have a level
> + * triggered interrupt, but the infrastructure can't expose that
> + * yet, so the guest takes but ignores it, goes to sleep and
> + * never gets notified that there's still an interrupt pending.
> + *
> + * As a quick workaround, let's just wake up again 20 ms after
> + * we injected an interrupt. That way we can assure that we're
> + * always reinjecting interrupts in case the guest swallowed 
> them.
> + */
> +timer_mod(>idle_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> (NANOSECONDS_PER_SECOND / 50));
>  }
>  
> 
> 

[Qemu-devel] [PATCH v2] i386/acpi: fix gint overflow in crs_range_compare

[Evgeny Yakovlev]

When very large regions (32GB sized in our case, PCI pass-through of GPUs)
are compared substraction result does not fit into gint.

As a result crs_replace_with_free_ranges does not get sorted ranges and
incorrectly computes PCI64 free space regions. Which then makes linux
guest complain about device and PCI64 hole intersection and device
becomes unusable.

Fix that by returning exactly fitting ranges.

Also fix indentation of an entire crs_replace_with_free_ranges to make
checkpatch happy.

Signed-off-by: Evgeny Yakovlev 
---
v2:
entire crs_replace_with_free_ranges was indented with 5 spaces, including my 
change.
fix that as well

 hw/i386/acpi-build.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index d281ffa..e7b756b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -755,10 +755,16 @@ static void crs_range_set_free(CrsRangeSet *range_set)
 
 static gint crs_range_compare(gconstpointer a, gconstpointer b)
 {
- CrsRangeEntry *entry_a = *(CrsRangeEntry **)a;
- CrsRangeEntry *entry_b = *(CrsRangeEntry **)b;
+CrsRangeEntry *entry_a = *(CrsRangeEntry **)a;
+CrsRangeEntry *entry_b = *(CrsRangeEntry **)b;
 
- return (int64_t)entry_a->base - (int64_t)entry_b->base;
+if (entry_a->base < entry_b->base) {
+return -1;
+} else if (entry_a->base > entry_b->base) {
+return 1;
+} else {
+return 0;
+}
 }
 
 /*
-- 
2.7.4

Re: [Qemu-devel] [PATCH] i386/acpi: fix gint overflow in crs_range_compare

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1563464932-24284-1-git-send-email-wr...@yandex-team.ru/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Subject: [Qemu-devel] [PATCH] i386/acpi: fix gint overflow in crs_range_compare
Message-id: 1563464932-24284-1-git-send-email-wr...@yandex-team.ru

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1563464932-24284-1-git-send-email-wr...@yandex-team.ru -> 
patchew/1563464932-24284-1-git-send-email-wr...@yandex-team.ru
Submodule 'capstone' (https://git.qemu.org/git/capstone.git) registered for 
path 'capstone'
Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
Submodule 'roms/QemuMacDrivers' (https://git.qemu.org/git/QemuMacDrivers.git) 
registered for path 'roms/QemuMacDrivers'
Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
Submodule 'roms/edk2' (https://git.qemu.org/git/edk2.git) registered for path 
'roms/edk2'
Submodule 'roms/ipxe' (https://git.qemu.org/git/ipxe.git) registered for path 
'roms/ipxe'
Submodule 'roms/openbios' (https://git.qemu.org/git/openbios.git) registered 
for path 'roms/openbios'
Submodule 'roms/openhackware' (https://git.qemu.org/git/openhackware.git) 
registered for path 'roms/openhackware'
Submodule 'roms/qemu-palcode' (https://git.qemu.org/git/qemu-palcode.git) 
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (https://git.qemu.org/git/seabios.git/) registered for 
path 'roms/seabios'
Submodule 'roms/seabios-hppa' (https://git.qemu.org/git/seabios-hppa.git) 
registered for path 'roms/seabios-hppa'
Submodule 'roms/sgabios' (https://git.qemu.org/git/sgabios.git) registered for 
path 'roms/sgabios'
Submodule 'roms/skiboot' (https://git.qemu.org/git/skiboot.git) registered for 
path 'roms/skiboot'
Submodule 'roms/u-boot' (https://git.qemu.org/git/u-boot.git) registered for 
path 'roms/u-boot'
Submodule 'roms/u-boot-sam460ex' (https://git.qemu.org/git/u-boot-sam460ex.git) 
registered for path 'roms/u-boot-sam460ex'
Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 
'slirp'
Submodule 'tests/fp/berkeley-softfloat-3' 
(https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 
'tests/fp/berkeley-softfloat-3'
Submodule 'tests/fp/berkeley-testfloat-3' 
(https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 
'tests/fp/berkeley-testfloat-3'
Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) 
registered for path 'ui/keycodemapdb'
Cloning into 'capstone'...
Submodule path 'capstone': checked out 
'22ead3e0bfdb87516656453336160e0a37b066bf'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Cloning into 'roms/QemuMacDrivers'...
Submodule path 'roms/QemuMacDrivers': checked out 
'90c488d5f4a407342247b9ea869df1c2d9c8e266'
Cloning into 'roms/SLOF'...
Submodule path 'roms/SLOF': checked out 
'ba1ab360eebe6338bb8d7d83a9220ccf7e213af3'
Cloning into 'roms/edk2'...
Submodule path 'roms/edk2': checked out 
'20d2e5a125e34fc8501026613a71549b2a1a3e54'
Submodule 'SoftFloat' (https://github.com/ucb-bar/berkeley-softfloat-3.git) 
registered for path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'
Submodule 'CryptoPkg/Library/OpensslLib/openssl' 
(https://github.com/openssl/openssl) registered for path 
'CryptoPkg/Library/OpensslLib/openssl'
Cloning into 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'...
Submodule path 'roms/edk2/ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3': 
checked out 'b64af41c3276f97f0e181920400ee056b9c88037'
Cloning into 'CryptoPkg/Library/OpensslLib/openssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl': checked out 
'50eaac9f3337667259de725451f201e784599687'
Submodule 'boringssl' (https://boringssl.googlesource.com/boringssl) registered 
for path 'boringssl'
Submodule 'krb5' (https://github.com/krb5/krb5) registered for path 'krb5'
Submodule 'pyca.cryptography' (https://github.com/pyca/cryptography.git) 
registered for path 'pyca-cryptography'
Cloning into 'boringssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/boringssl': 
checked out '2070f8ad9151dc8f3a73bffaa146b5e6937a583f'
Cloning into 'krb5'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5': checked 
out 'b9ad6c49505c96a088326b62a52568e3484f2168'
Cloning into 'pyca-cryptography'...
Submodule path 
'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/pyca-cryptography': checked out 
'09403100de2f6f1cdd0d484dcb8e620f1c335c8f'
Cloning into 'roms/ipxe'...
Submodule path 'roms/ipxe': checked out 

[Qemu-devel] [PATCH] i386/acpi: fix gint overflow in crs_range_compare

[Evgeny Yakovlev]

When very large regions (32GB sized in our case, PCI pass-through of GPUs)
are compared substraction result does not fit into gint.

As a result crs_replace_with_free_ranges does not get sorted ranges and
incorrectly computes PCI64 free space regions. Which then makes linux
guest complain about device and PCI64 hole intersection and device
becomes unusable.

Fix that by returning exactly fitting ranges.

Signed-off-by: Evgeny Yakovlev 
---
 hw/i386/acpi-build.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index d281ffa..5cf88a6 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -758,7 +758,13 @@ static gint crs_range_compare(gconstpointer a, 
gconstpointer b)
  CrsRangeEntry *entry_a = *(CrsRangeEntry **)a;
  CrsRangeEntry *entry_b = *(CrsRangeEntry **)b;
 
- return (int64_t)entry_a->base - (int64_t)entry_b->base;
+ if (entry_a->base < entry_b->base) {
+ return -1;
+ } else if (entry_a->base > entry_b->base) {
+ return 1;
+ } else {
+ return 0;
+ }
 }
 
 /*
-- 
2.7.4

Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type

[Paolo Bonzini]

On 18/07/19 16:34, Sergio Lopez wrote:
> I've just added support for starting the machine from SeaBIOS (Stefan
> Hajnoczi pointed in another thread that it can be as fast as qboot, and
> given that the latter doesn't support mptables, I just tested this
> one). I tried to keep it as minimalistic as possible, but it still
> required an RTC (mc146818), which dragged in an ISA BUS, and this one a
> KVM PIT.
> 
> I ran some numbers using Stefano Garzarella's qemu-boot-time scripts
> [1] on a server with 2xIntel Xeon Silver 4114 2.20GHz, using the
> upstream QEMU (474f3938d79ab36b9231c9ad3b5a9314c2aeacde) built with
> minimal features [2]. The VM boots a minimal kernel [3] without initrd,
> using a kata container image as root via virtio-blk (though this isn't
> really relevant, as we're just taking measurements until the kernel is
> about to exec init).
> 
>  -
>  | QEMU with SeaBIOS |
>  -
> 
>  qemu_init_end: 65.958714
>  linux_start_kernel: 77.735803 (+11.777089)
>  linux_start_user: 127.360739 (+49.624936)
> 
>  ---
>  | QEMU direct PVH |
>  ---
> 
>  qemu_init_end: 64.043264
>  linux_start_kernel: 65.481782 (+1.438518)
>  linux_start_user: 114.938353 (+49.456571)
> 
>  --
>  | Comparison |
>  --
> 
> Average boot time:
> 
>  * Relying on SeaBIOS, when compared with direct PVH boot, as a total
>average overhead of ~12ms. The cost of initializing QEMU increases in
>~2ms (probably due to need to instantiate more devices), while the
>other ~10ms is the SeaBIOS overhead.
> 
>  ---
>  | Conclusions |
>  ---
> 
> Objectively, the version that boots directly the kernel using PVH is 10%
> faster and has a slightly larger exposed surface. Whether this is enough
> to justify its existence is quite subjective.
> 
> In my opinion, not only I think it makes sense to have it, but I also
> think there's little reason to have the firmware reliant version, given
> the nature and purpose of microvm.

The advantage of firmware is support for vmlinuz and multiboot in
addition to PVH, and removing code from QEMU.  So I think it's still
worth doing a comparison with qboot, and trying to understand where
SeaBIOS is spending its time (qboot should not need additional devices
other than fw_cfg, and since SeaBIOS has never been optimized for
microvm I expect it's possible to shave quite a few of those 12 ms).

On the other hand I agree that microvm is showing great promise compared
to PCI-based machine types.

Paolo



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v3 0/3] High downtime with 95+ throttle pct

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190718091726.9874-1-yury-ko...@yandex-team.ru/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==11780==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
PASS 7 fdc-test /x86_64/fdc/read_id
PASS 8 fdc-test /x86_64/fdc/verify
PASS 9 fdc-test /x86_64/fdc/media_insert
==11788==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==11788==WARNING: ASan is ignoring requested __asan_handle_no_return: stack 
top: 0x7ffd9c17a000; bottom 0x7f402d2f8000; size: 0x00bd6ee82000 (813609525248)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-coroutine /basic/no-dangling-access
---
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
PASS 11 fdc-test /x86_64/fdc/read_no_dma_18
==11808==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 27 test-aio /aio-gsource/event/wait/no-flush-cb
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-aio-multithread -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="test-aio-multithread" 
==11814==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-aio-multithread /aio/multi/lifecycle
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
PASS 3 test-aio-multithread /aio/multi/mutex/contended
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img 
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="ide-test" 
==11842==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 ide-test /x86_64/ide/identify
==11848==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 2 ide-test /x86_64/ide/flush
==11859==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
==11870==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
PASS 4 ide-test /x86_64/ide/bmdma/trim
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-throttle" 
==11877==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==11879==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-thread-pool" 
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
PASS 1 test-thread-pool /thread-pool/submit
==11889==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 2 test-thread-pool /thread-pool/submit-aio
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
==11891==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
==11962==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 test-thread-pool /thread-pool/cancel
PASS 7 ide-test /x86_64/ide/bmdma/long_prdt
==11969==WARNING: ASan doesn't fully support 

Re: [Qemu-devel] [PATCH v2] tests/boot_linux_console: add a test for riscv64 + virt

[Alistair Francis]

On Thu, Jul 18, 2019 at 8:00 AM Chih-Min Chao  wrote:
>
>
>
> On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis  wrote:
>>
>> On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao  
>> wrote:
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis  
>> > wrote:
>> >>
>> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé
>> >>  wrote:
>> >> >
>> >> > On 7/16/19 10:43 PM, Alistair Francis wrote:
>> >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao 
>> >> > >  wrote:
>> >> > >>
>> >> > >>
>> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis 
>> >> > >>  wrote:
>> >> > >>>
>> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé
>> >> > >>>  wrote:
>> >> > 
>> >> >  On 7/15/19 1:09 PM, Chih-Min Chao wrote:
>> >> > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé
>> >> > > mailto:phi...@redhat.com>> wrote:
>> >> > >
>> >> > > On 7/15/19 11:08 AM, Chih-Min Chao wrote:
>> >> > > > Similar to the mips + malta test, it boots a Linux kernel 
>> >> > > on a virt
>> >> > > > board and verify the serial is working.  Also, it relies on 
>> >> > > the serial
>> >> > > > device set by the machine itself.
>> >> > > >
>> >> > > > If riscv64 is a target being built, "make check-acceptance" 
>> >> > > will
>> >> > > > automatically include this test by the use of the 
>> >> > > "arch:riscv64" tags.
>> >> > > >
>> >> > > > Alternatively, this test can be run using:
>> >> > > >
>> >> > > >   $ avocado run -t arch:riscv64 tests/acceptance
>> >> > > >
>> >> > > > packages
>> >> > > >   debian official
>> >> > > > binutils-riscv64-linux-gnu_2.32-8
>> >> > > > opensbi_0.4-1_all
>> >> > > > linux-image-4.19.0-5-riscv64 4.19.37-4
>> >> > > >   third-party
>> >> > > >
>> >> > >  
>> >> > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz
>> >> > > > (the repo is also used in mips target acceptance)
>> >> > > >
>> >> > > > Signed-off-by: Chih-Min Chao > >> > > >
>> >> > > > ---
>> >> > > >  .travis.yml|  2 +-
>> >> > > >  tests/acceptance/boot_linux_console.py | 66
>> >> > > ++
>> >> > > >  2 files changed, 67 insertions(+), 1 deletion(-)
>> >> > > >
>> >> > > > diff --git a/.travis.yml b/.travis.yml
>> >> > > > index 5d3d6ee..21fcead 100644
>> >> > > > --- a/.travis.yml
>> >> > > > +++ b/.travis.yml
>> >> > > > @@ -232,7 +232,7 @@ matrix:
>> >> > > >
>> >> > > >  # Acceptance (Functional) tests
>> >> > > >  - env:
>> >> > > > -- CONFIG="--python=/usr/bin/python3
>> >> > > 
>> >> > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu"
>> >> > > > +- CONFIG="--python=/usr/bin/python3
>> >> > > 
>> >> > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu"
>> >> > > >  - TEST_CMD="make check-acceptance"
>> >> > > >after_failure:
>> >> > > >  - cat tests/results/latest/job.log
>> >> > > > diff --git a/tests/acceptance/boot_linux_console.py
>> >> > > b/tests/acceptance/boot_linux_console.py
>> >> > > > index 3215950..0f638bc 100644
>> >> > > > --- a/tests/acceptance/boot_linux_console.py
>> >> > > > +++ b/tests/acceptance/boot_linux_console.py
>> >> > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test):
>> >> > > >  self.vm.launch()
>> >> > > >  console_pattern = 'Kernel command line: %s' %
>> >> > > kernel_command_line
>> >> > > >  self.wait_for_console_pattern(console_pattern)
>> >> > > > +
>> >> > > > +def test_riscv64_virt(self):
>> >> > > > +"""
>> >> > > > +:avocado: tags=arch:riscv64
>> >> > > > +:avocado: tags=machine:virt
>> >> > > > +"""
>> >> > > > +deb_url = 
>> >> > > ('https://snapshot.debian.org/archive/debian/'
>> >> > > > + 
>> >> > > '20190424T171759Z/pool/main/b/binutils/'
>> >> > > > +
>> >> > >  'binutils-riscv64-linux-gnu_2.32-8_amd64.deb')
>> >> > > > +deb_hash = 
>> >> > > ('7fe376fd4452696c03acd508d6d613ca553ea15e')
>> >> > > > +deb_path = self.fetch_asset(deb_url, 
>> >> > > asset_hash=deb_hash)
>> >> > > > +objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy'
>> >> > > > +objcopy_path = self.extract_from_deb(deb_path, 
>> >> > 

Re: [Qemu-devel] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES

[Cornelia Huck]

On Wed, 17 Jul 2019 17:04:54 +0200
Paolo Bonzini  wrote:

> On 17/07/19 16:54, Collin Walling wrote:
> > PCI host plugging will check for the MSI-X capability on the
> > PCI device. If the MSI-X cap is missing, we fail device plugging.
> > We do not check for MSI. Only MSI-X.
> > 
> > Specifically, the capability is represented by PCI_CAP_ID_MSIX
> > in pci_regs.h  
> 
> The code in Linux says that single MSIs are supported too:
> 
>if (type == PCI_CAP_ID_MSI && nvec > 1)
>return 1;

Interestingly, the check for MSI-X in QEMU seems to have been
introduced in 857cc71985dc ("s390x/pci: merge msix init functions"),
but that commit does not give a rationale (maybe it just referred to the
existing code structure?)

A quick look through the code suggests that single MSIs should be
supportable; can someone with access to the details verify?

Re: [Qemu-devel] BDRV request fragmentation and virtio-blk write submission guarantees (2nd try)

[Евгений Яковлев]

Evgeny Yakovlev
Lead Software Engineer, Yandex.Cloud Hypervisor Team

On 18.07.2019 17:59, Kevin Wolf wrote:

Am 18.07.2019 um 15:52 hat Евгений Яковлев geschrieben:

Hi everyone,

My previous message was misformatted, so here's another one. Sorry about
that.

We're currently working on implementing a qemu BDRV format driver which we
are using with virtio-blk devices.

I have a question concerning BDRV request fragmentation and virtio-blk write
request submission which is not entirely clear to me by only reading virtio
spec. Could you please consider the following case and give some additional
guidance?

1. Our BDRV format driver has a notion of max supported transfer size. So we
implement BlockDriver::bdrv_refresh_limits where we fill out
BlockLimits::max_transfer and opt_transfer fields.

2. virtio-blk exposes max_transfer as a virtio_blk_config::opt_io_size
field, which (according to spec 1.1) is a **suggested** maximum. We read
"suggested" as "guest driver may still send requests that don't fit into
opt_io_size and we should handle those"...

3. ... and judging by code in block/io.c qemu block layer handles such
requests by fragmenting them into several BDRV requests if request size is >
max_transfer

4. Guest will see request completion only after all fragments are handled.
However each fragment submission path can call qemu_coroutine_yield and move
on to submitting next request available in virtq before completely
submitting the rest of the fragments. Which means the following situation is
possible where BDRV sees 2 write requests in virtq, both of which are larger
than max_transfer:

Blocks: -

Write1: --

Write2: --

Write1Chunk1: 

Write2Chunk1: 

Write2Chunk2: 

Write1Chunk1: 

Blocks: ---


In above scenario guest virtio-blk driver decided to submit 2 intersecting
write requests, both of which are larger than ||max_transfer, and then call
hypervisor.

I understand that virtio-blk may handle requests out of order, so guest must
not make any assumptions on relative order in which those requests will be
handled.

However, can guest driver expect that whatever the submission order will be,
the actual intersecting writes will be atomic?

In other words, will it be correct for conforming virtio-blk driver to
expect only "" or "" but not anything else in between, after
both requests are reported as completed?

Because i think that is something that may happen in qemu right now, if i
understood correctly.

I don't think atomicity is promised anywhere in the virtio
specification, and I agree with you that this case can happen (it
probably happens much more frequently when you use image formats instead
of raw files).

On the other hand, there is no good reason for a guest OS to submit two
write request to the same blocks in parallel. Even if it could expect
that one of the requests wins, the end result would still be undefined,
so I don't think this could ever be a useful thing to do. (Well, I guess
it could replace flipping a coin...)
Kevin



Thanks Kevin. I agree that described guest behavior does not a have a 
sensible reason behind it. However, just based on purely theoretical 
basis, according to virtio-blk contract, is it valid for guest to even 
_assume_ that above situation with 2 requests _must_ be resolved in one 
of two specific cases i described and not anything in between? In other 
words that writes will be atomic even if their relative order is 
undefined. We could not get a clear answer from virtio spec ourselves.


For instance, IIRC, nvme spec declares atomicity guarantees as well as 
ordering for specific commands ("6.4 Atomic Operations").


Evgeny

Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type

[Sergio Lopez]

Stefan Hajnoczi  writes:

> On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
>> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> constructed after the machine model implemented by the latter.
>> 
>> It's main purpose is providing users a KVM-only machine type with fast
>> boot times, minimal attack surface (measured as the number of IO ports
>> and MMIO regions exposed to the Guest) and small footprint (specially
>> when combined with the ongoing QEMU modularization effort).
>> 
>> Normally, other than the device support provided by KVM itself,
>> microvm only supports virtio-mmio devices. Microvm also includes a
>> legacy mode, which adds an ISA bus with a 16550A serial port, useful
>> for being able to see the early boot kernel messages.
>> 
>> Microvm only supports booting PVH-enabled Linux ELF images. Booting
>> other PVH-enabled kernels may be possible, but due to the lack of ACPI
>> and firmware, we're relying on the command line for specifying the
>> location of the virtio-mmio transports. If there's an interest on
>> using this machine type with other kernels, we'll try to find some
>> kind of middle ground solution.
>> 
>> This is the list of the exposed IO ports and MMIO regions when running
>> in non-legacy mode:
>> 
>> address-space: memory
>> d000-d1ff (prio 0, i/o): virtio-mmio
>> d200-d3ff (prio 0, i/o): virtio-mmio
>> d400-d5ff (prio 0, i/o): virtio-mmio
>> d600-d7ff (prio 0, i/o): virtio-mmio
>> d800-d9ff (prio 0, i/o): virtio-mmio
>> da00-dbff (prio 0, i/o): virtio-mmio
>> dc00-ddff (prio 0, i/o): virtio-mmio
>> de00-dfff (prio 0, i/o): virtio-mmio
>> fee0-feef (prio 4096, i/o): kvm-apic-msi
>> 
>> address-space: I/O
>>   - (prio 0, i/o): io
>> 0020-0021 (prio 0, i/o): kvm-pic
>> 0040-0043 (prio 0, i/o): kvm-pit
>> 007e-007f (prio 0, i/o): kvmvapic
>> 00a0-00a1 (prio 0, i/o): kvm-pic
>> 04d0-04d0 (prio 0, i/o): kvm-elcr
>> 04d1-04d1 (prio 0, i/o): kvm-elcr
>> 
>> A QEMU instance with the microvm machine type can be invoked this way:
>> 
>>  - Normal mode:
>> 
>> qemu-system-x86_64 -M microvm -m 512m -smp 2 \
>>  -kernel vmlinux -append "console=hvc0 root=/dev/vda" \
>>  -nodefaults -no-user-config \
>>  -chardev pty,id=virtiocon0,server \
>>  -device virtio-serial-device \
>>  -device virtconsole,chardev=virtiocon0 \
>>  -drive id=test,file=test.img,format=raw,if=none \
>>  -device virtio-blk-device,drive=test \
>>  -netdev tap,id=tap0,script=no,downscript=no \
>>  -device virtio-net-device,netdev=tap0
>> 
>>  - Legacy mode:
>> 
>> qemu-system-x86_64 -M microvm,legacy -m 512m -smp 2 \
>>  -kernel vmlinux -append "console=ttyS0 root=/dev/vda" \
>>  -nodefaults -no-user-config \
>>  -drive id=test,file=test.img,format=raw,if=none \
>>  -device virtio-blk-device,drive=test \
>>  -netdev tap,id=tap0,script=no,downscript=no \
>>  -device virtio-net-device,netdev=tap0 \
>>  -serial stdio
>
> Please post metrics that compare this against a minimal Q35.
>
> With qboot it was later found that SeaBIOS can achieve comparable boot
> times, so it wasn't worth maintaining qboot.
>
> Data is needed to show that microvm is really a significant improvement
> over a minimal Q35.

I've just ran some numbers using Stefano Garzarella's qemu-boot-time
scripts [1] on a server with 2xIntel Xeon Silver 4114 2.20GHz, using the
upstream QEMU (474f3938d79ab36b9231c9ad3b5a9314c2aeacde) built with
minimal features [2]. The VM boots a minimal kernel [3] without initrd,
using a kata container image as root via virtio-blk (though this isn't
really relevant, as we're just taking measurements until the kernel is
about to exec init).

To try to make the comparison as fair as possible, I've used a minimal
q35 machine with as few devices as possible. Disabling HPET and PIT at
the same time caused the kernel to get stuck on boot, so I ran two
iterations, one without HPET and the other without PIT:


-
 | Q35 with HPET |
 -

Command line:

./x86_64-softmmu/qemu-system-x86_64 -m 512m -enable-kvm -M 
q35,smbus=off,nvdimm=off,pit=off,vmport=off,sata=off,usb=off,graphics=off 
-kernel /root/src/images/vmlinux-5.2 -append "console=hvc0 reboot=k panic=1 
root=/dev/vda quiet" -smp 1 -nodefaults -no-user-config -chardev 
pty,id=virtiocon0,server -device virtio-serial -device 
virtconsole,chardev=virtiocon0 -drive 
id=test,file=/root/src/images/hello-rootfs.ext4,format=raw,if=none -device 
virtio-blk,drive=test

Average boot times after 10 consecutive runs:

 qemu_init_end: 77.637936
 linux_start_kernel: 117.082526 

[Qemu-devel] [PATCH v3] ppc: make idle_timer a per-cpu variable

[Shivaprasad G Bhat]

The current code is broken for more than vcpu as
each thread would overwrite and there were memory leaks.

Make it part of PowerPCCPU so that every thread has a
separate one. Avoid using the timer_new_ns which is
not the preferred way to create timers.

Signed-off-by: Shivaprasad G Bhat 
---
 v2: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg04023.html
 Changes from v2:
   v2 just looked at avoiding the memory leak.
   This patch incorporates all of Greg's suggestions.

 target/ppc/cpu.h |1 +
 target/ppc/kvm.c |   31 ---
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index c9beba2a5c..521086d91a 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1190,6 +1190,7 @@ struct PowerPCCPU {
 void *machine_data;
 int32_t node_id; /* NUMA node this CPU belongs to */
 PPCHash64Options *hash64_opts;
+QEMUTimer idle_timer;
 
 /* Fields related to migration compatibility hacks */
 bool pre_2_8_migration;
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 8a06d3171e..6e1b96bb0a 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -87,18 +87,6 @@ static int cap_large_decr;
 
 static uint32_t debug_inst_opcode;
 
-/*
- * XXX We have a race condition where we actually have a level triggered
- * interrupt, but the infrastructure can't expose that yet, so the guest
- * takes but ignores it, goes to sleep and never gets notified that there's
- * still an interrupt pending.
- *
- * As a quick workaround, let's just wake up again 20 ms after we injected
- * an interrupt. That way we can assure that we're always reinjecting
- * interrupts in case the guest swallowed them.
- */
-static QEMUTimer *idle_timer;
-
 static void kvm_kick_cpu(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
@@ -491,7 +479,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
 return ret;
 }
 
-idle_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, kvm_kick_cpu, cpu);
+timer_init_ns(>idle_timer, QEMU_CLOCK_VIRTUAL, kvm_kick_cpu, cpu);
 
 switch (cenv->mmu_model) {
 case POWERPC_MMU_BOOKE206:
@@ -523,6 +511,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 
 int kvm_arch_destroy_vcpu(CPUState *cs)
 {
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+
+timer_deinit(>idle_timer);
+
 return 0;
 }
 
@@ -1379,8 +1371,17 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
 printf("cpu %d fail inject %x\n", cs->cpu_index, irq);
 }
 
-/* Always wake up soon in case the interrupt was level based */
-timer_mod(idle_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
+/*
+ * XXX We have a race condition where we actually have a level
+ * triggered interrupt, but the infrastructure can't expose that
+ * yet, so the guest takes but ignores it, goes to sleep and
+ * never gets notified that there's still an interrupt pending.
+ *
+ * As a quick workaround, let's just wake up again 20 ms after
+ * we injected an interrupt. That way we can assure that we're
+ * always reinjecting interrupts in case the guest swallowed them.
+ */
+timer_mod(>idle_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
(NANOSECONDS_PER_SECOND / 50));
 }
 

[Qemu-devel] [Bug 1815423] Re: x86_64 TCG: Incorrect floating point cast to int.

[Peter Maydell]

** Changed in: qemu
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815423

Title:
  x86_64 TCG: Incorrect floating point cast to int.

Status in QEMU:
  Confirmed

Bug description:
  I used exaample from:
  
https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c

  #include 
  #include 

  int main(int argc, char** argv) {
float a = INFINITY;
float b = -INFINITY;
float c = NAN;

printf("float %f %f %f\n", a, b, c); 
printf("int %d %d %d\n", (int) a, (int) b, (int) c); 
printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned 
int) c); 
printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); 
printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, 
(unsigned long int) c); 

return 0;
  }

  And got different results on real computer and on qemu.

  output from real HW is the same as on stackoverflow:

  $ gcc test.c && ./a.out 
  float inf -inf nan
  int -2147483648 -2147483648 -2147483648
  uint 0 0 0
  lint -9223372036854775808 -9223372036854775808 -9223372036854775808
  luint 0 9223372036854775808 9223372036854775808

  
  But on qemu I got another results:

  float inf -inf nan
  int 2147483647 -2147483648 2147483647
  uint 4294967295 0 4294967295
  lint 9223372036854775807 -9223372036854775808 -9223372036854775808
  luint 18446744073709551615 9223372036854775808 9223372036854775807

  qemu launch string:
  /qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev 
user,id=network0 -device e1000,netdev=network0 -kernel my_kernel

  
  qemu version:
  x86_64-softmmu/qemu-system-x86_64 --version
  QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty)
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

  
  This bug affect some javascript (surprise) calculations:

  var conversion = "01234567890";
  var x;
  var result = conversion[x & 42];
  console.log(result)

  
  In example, var x is "undefined"
  and when do calculation "x & 42" on js we should get 0 (it is documented 
feature), but actually got "42"

  and "result" sould be "0" but actually we got "undefined"

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815423/+subscriptions

Re: [Qemu-devel] [PATCH-for-4.1 v7 1/1] hw/block/pflash_cfi01: Add missing DeviceReset() handler

[Laszlo Ersek]

On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
> To avoid incoherent states when the machine resets (see but report

(1) For the PULL request, please fix the typo: s/but/bug/

> below), add the device reset callback.
> 
> A "system reset" sets the device state machine in READ_ARRAY mode
> and, after some delay, set the SR.7 READY bit.
> 
> Since we do not model timings, we set the SR.7 bit directly.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1678713
> Reported-by: Laszlo Ersek 
> Reviewed-by: John Snow 
> Reviewed-by: Alistair Francis 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/block/pflash_cfi01.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index 435be1e35c..a1ec1faae5 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -865,6 +865,24 @@ static void pflash_cfi01_realize(DeviceState *dev, Error 
> **errp)
>  pfl->cfi_table[0x3f] = 0x01; /* Number of protection fields */
>  }
>  
> +static void pflash_cfi01_system_reset(DeviceState *dev)
> +{
> +PFlashCFI01 *pfl = PFLASH_CFI01(dev);
> +
> +/*
> + * The command 0x00 is not assigned by the CFI open standard,
> + * but QEMU historically uses it for the READ_ARRAY command (0xff).
> + */
> +pfl->cmd = 0x00;
> +pfl->wcycle = 0;
> +memory_region_rom_device_set_romd(>mem, true);
> +/*
> + * The WSM ready timer occurs at most 150ns after system reset.
> + * This model deliberately ignores this delay.
> + */
> +pfl->status = 0x80;
> +}
> +
>  static Property pflash_cfi01_properties[] = {
>  DEFINE_PROP_DRIVE("drive", PFlashCFI01, blk),
>  /* num-blocks is the number of blocks actually visible to the guest,
> @@ -909,6 +927,7 @@ static void pflash_cfi01_class_init(ObjectClass *klass, 
> void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  
> +dc->reset = pflash_cfi01_system_reset;
>  dc->realize = pflash_cfi01_realize;
>  dc->props = pflash_cfi01_properties;
>  dc->vmsd = _pflash;
> 

(2) Reviewed-by: Laszlo Ersek 

A *future* improvement (meant just for this surgical reset handler --
not meaning any large cfi01 overhaul!) could be the addition of a trace
point, at the top of pflash_cfi01_system_reset().

But that is strictly "nice to have", and not necessary to include in the
present bugfix.


(3) Using OVMF IA32X64 (including the edk2 SMM stack), I've
regression-tested this patch, on top of v4.1.0-rc1, with KVM. As follows:

(3a) Normal reboot from the UEFI shell ("reset -c" command)

(3b) Normal reboot from the Linux guest prompt ("reboot" command)

(3c1) Reset as part of ACPI S3 suspend/resume
(3c2) then use "efibootmgr -n / -N" to write to pflash (by virtue of
setting / deleting the standardized BootNext UEFI variable)

(3d1) Boot to setup TUI with SB enabled
(3d2) erase Platform Key in setup TUI (disables SB)
(3d3) reboot from within setup TUI
(3d4) proceed to UEFI shell
(3d5) enable SB with EnrollDefaultKeys.efi
(3d6) reboot from UEFI shell
(3d7) proceeed to Linux guest
(3d8) verify SB enablement (dmesg, "mokutil --sb-state")

(As an added exercise, step (3d4) triggered an "FTW" (fault tolerant
write) "reclaim" (basically a defragmentation of the journaled
"filesystem" that the firmware keeps in the flash, as a logical "middle
layer"), and that worked fine too.)

Regression-tested-by: Laszlo Ersek 


(4) I plan to provide R-t-b in the evening from aarch64 KVM too, using
the edk2 ArmVirtQemu firmware. Only the first two steps from (3) will be
covered (no ACPI S3, no SB).

Thanks!
Laszlo

[Qemu-devel] [Bug 1825002] Re: "qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f

[Peter Maydell]

A fix for this was committed as abcac736c1505254ec3 and will be in the
upcoming 4.1 release.

** Changed in: qemu
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825002

Title:
  "qemu: Unexpected FPU mode" since
  0c1bbedc10e86ea9366b6af8c5520fafa3266b2f

Status in QEMU:
  Fix Committed

Bug description:
  This happens every time I attempt to chroot into a gentoo-mips image
  unless I load the executable via ld.so

  /home (root)# chroot gentoo-mips32r2el /bin/sh
  qemu: Unexpected FPU mode
  /home (root)# chroot gentoo-mips32r2el /lib/ld-2.19.so /bin/sh
  sh-4.2# exit
  /home (root)# 

  I don't know the underlying cause, but keep in mind that we may lie
  and claim to have an FPU when our CPU doesn't because of kernel
  emulation that may not be present in the host kernel.  Don't know if
  that's related.

  I get this with various gentoo-mips stage3 tarballs, but not with
  OpenWRT.  (e.g.,
  https://gentoo.osuosl.org/experimental/mips/stages/mips32r2el/2014)


  # emerge --info app-emulation/qemu
  Portage 2.3.51 (python 3.6.5-final-0, 
default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.27-r6, 
4.14.96-gentoo x86_64)
  =
   System Settings
  =
  System uname: 
Linux-4.14.96-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6
  KiB Mem:32890732 total,   3480024 free
  KiB Swap:   16777212 total,  10575592 free
  Timestamp of repository gentoo: Thu, 11 Apr 2019 06:00:01 +
  Head commit of repository gentoo: 66eaaa28926103e690db0699466a274a17ab1979
  sh bash 4.4_p23-r1
  ld GNU ld (Gentoo 2.30 p5) 2.30.0
  distcc 3.3.2 x86_64-pc-linux-gnu [disabled]
  ccache version 3.3.4 [disabled]
  app-shells/bash:  4.4_p23-r1::gentoo
  dev-java/java-config: 2.2.0-r4::gentoo
  dev-lang/perl:5.26.2::gentoo
  dev-lang/python:  2.7.15::gentoo, 3.6.5::gentoo
  dev-util/ccache:  3.3.4-r1::gentoo
  dev-util/cmake:   3.9.6::gentoo
  dev-util/pkgconfig:   0.29.2::gentoo
  sys-apps/baselayout:  2.6-r1::gentoo
  sys-apps/openrc:  0.38.3-r1::gentoo
  sys-apps/sandbox: 2.13::gentoo
  sys-devel/autoconf:   2.13-r1::gentoo, 2.64-r1::gentoo, 2.69-r4::gentoo
  sys-devel/automake:   1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 
1.15.1-r2::gentoo, 1.16.1-r1::gentoo
  sys-devel/binutils:   2.30-r4::gentoo
  sys-devel/gcc:4.9.4::gentoo, 5.4.0-r6::gentoo, 6.4.0-r5::gentoo, 
7.3.0-r6::gentoo, 8.1.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo
  sys-devel/gcc-config: 2.0::gentoo
  sys-devel/libtool:2.4.6-r3::gentoo
  sys-devel/make:   4.2.1-r4::gentoo
  sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)
  sys-libs/glibc:   2.27-r6::gentoo
  Repositories:

  gentoo
  location: /usr/portage
  sync-type: rsync
  sync-uri: rsync://rsync.gentoo.org/gentoo-portage
  priority: -1000
  sync-rsync-verify-jobs: 1
  sync-rsync-extra-opts: 
  sync-rsync-verify-metamanifest: yes
  sync-rsync-verify-max-age: 24

  love-local
  location: /usr/local/portage
  masters: gentoo
  priority: 0

  chaoslab
  location: /var/lib/layman/chaoslab
  masters: gentoo
  priority: 50

  java
  location: /var/lib/layman/java
  masters: gentoo
  priority: 50

  steam-overlay
  location: /var/lib/layman/steam-overlay
  masters: gentoo
  priority: 50

  zugaina
  location: /var/lib/layman/zugaina
  masters: gentoo
  priority: 50

  ACCEPT_KEYWORDS="amd64"
  ACCEPT_LICENSE="* -@EULA"
  CBUILD="x86_64-pc-linux-gnu"
  CFLAGS="-march=native -O2 -ggdb3 -pipe"
  CHOST="x86_64-pc-linux-gnu"
  CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc 
/usr/share/config /usr/share/gnupg/qualified.txt"
  CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d 
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild 
/etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d 
/etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
  CXXFLAGS="-march=native -O2 -ggdb3 -pipe"
  DISTDIR="/mnt/large/distfiles"
  EMERGE_DEFAULT_OPTS="-j3 --load-average=17.5 --with-bdeps=y --autounmask=n"
  ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT 
PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME 
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
  FCFLAGS="-O2 -pipe"
  FEATURES="assume-digests binpkg-logs buildpkg candy cgroup 
compress-build-logs compressdebug config-protect-if-modified distlocks 
ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict 
network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms 
split-elog 

[Qemu-devel] [Bug 1832281] Re: tcg bug master / 4.0.0 v8 operation >>> and |=

[Peter Maydell]

This might be the same underlying problem as LP:1815423 which also
mentions some issues with Javascript calculations involving arithmetic
operations on a js "undefined" value. That bug has a C-only reproduce
case so is probably a good place to start for anybody interesting in
investigating and fixing it.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1832281

Title:
  tcg bug master / 4.0.0 v8 operation >>> and |=

Status in QEMU:
  New

Bug description:
  vm guest is linux, executed with tcg
  running this Node.js snippet leads to

  $ node
  > a = undefined
  undefined
  > a >>> 0
  4294967295

  host node
  $ node
  > a = undefined
  undefined
  > a >>> 0
  0

  same with |=

  node
  Welcome to Node.js v12.4.0.
  Type ".help" for more information.
  > let buffer
  undefined
  > buffer |= 0
  0

  vm with tcg:

  $ ./out/Release/node --version
  v12.4.0
  ./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);"
  -1

  vm guest is debian x86_64 latest release
  vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom 
debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic 
user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img

  git tag v4.0.0 and master, commit
  a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-
  x86_64 was used.

  Node.js is compiled on the vm guest (v12.4.0 / master)

  see also
  https://github.com/nodejs/node/issues/19348#issuecomment-500465502

  I need further assistance to track down the cause of the bug.

  Kind regards
  Manuel

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1832281/+subscriptions

Re: [Qemu-devel] [PATCH v2] tests/boot_linux_console: add a test for riscv64 + virt

[Chih-Min Chao]

On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis 
wrote:

> On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao 
> wrote:
> >
> >
> >
> > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis 
> wrote:
> >>
> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé
> >>  wrote:
> >> >
> >> > On 7/16/19 10:43 PM, Alistair Francis wrote:
> >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <
> chihmin.c...@sifive.com> wrote:
> >> > >>
> >> > >>
> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <
> alistai...@gmail.com> wrote:
> >> > >>>
> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé
> >> > >>>  wrote:
> >> > 
> >> >  On 7/15/19 1:09 PM, Chih-Min Chao wrote:
> >> > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé
> >> > > mailto:phi...@redhat.com>> wrote:
> >> > >
> >> > > On 7/15/19 11:08 AM, Chih-Min Chao wrote:
> >> > > > Similar to the mips + malta test, it boots a Linux kernel
> on a virt
> >> > > > board and verify the serial is working.  Also, it relies
> on the serial
> >> > > > device set by the machine itself.
> >> > > >
> >> > > > If riscv64 is a target being built, "make
> check-acceptance" will
> >> > > > automatically include this test by the use of the
> "arch:riscv64" tags.
> >> > > >
> >> > > > Alternatively, this test can be run using:
> >> > > >
> >> > > >   $ avocado run -t arch:riscv64 tests/acceptance
> >> > > >
> >> > > > packages
> >> > > >   debian official
> >> > > > binutils-riscv64-linux-gnu_2.32-8
> >> > > > opensbi_0.4-1_all
> >> > > > linux-image-4.19.0-5-riscv64 4.19.37-4
> >> > > >   third-party
> >> > > >
> >> > >
> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz
> >> > > > (the repo is also used in mips target acceptance)
> >> > > >
> >> > > > Signed-off-by: Chih-Min Chao  >> > > >
> >> > > > ---
> >> > > >  .travis.yml|  2 +-
> >> > > >  tests/acceptance/boot_linux_console.py | 66
> >> > > ++
> >> > > >  2 files changed, 67 insertions(+), 1 deletion(-)
> >> > > >
> >> > > > diff --git a/.travis.yml b/.travis.yml
> >> > > > index 5d3d6ee..21fcead 100644
> >> > > > --- a/.travis.yml
> >> > > > +++ b/.travis.yml
> >> > > > @@ -232,7 +232,7 @@ matrix:
> >> > > >
> >> > > >  # Acceptance (Functional) tests
> >> > > >  - env:
> >> > > > -- CONFIG="--python=/usr/bin/python3
> >> > >
>  
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu"
> >> > > > +- CONFIG="--python=/usr/bin/python3
> >> > >
>  
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu"
> >> > > >  - TEST_CMD="make check-acceptance"
> >> > > >after_failure:
> >> > > >  - cat tests/results/latest/job.log
> >> > > > diff --git a/tests/acceptance/boot_linux_console.py
> >> > > b/tests/acceptance/boot_linux_console.py
> >> > > > index 3215950..0f638bc 100644
> >> > > > --- a/tests/acceptance/boot_linux_console.py
> >> > > > +++ b/tests/acceptance/boot_linux_console.py
> >> > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test):
> >> > > >  self.vm.launch()
> >> > > >  console_pattern = 'Kernel command line: %s' %
> >> > > kernel_command_line
> >> > > >  self.wait_for_console_pattern(console_pattern)
> >> > > > +
> >> > > > +def test_riscv64_virt(self):
> >> > > > +"""
> >> > > > +:avocado: tags=arch:riscv64
> >> > > > +:avocado: tags=machine:virt
> >> > > > +"""
> >> > > > +deb_url = ('
> https://snapshot.debian.org/archive/debian/'
> >> > > > +
>  '20190424T171759Z/pool/main/b/binutils/'
> >> > > > +
> >> > >  'binutils-riscv64-linux-gnu_2.32-8_amd64.deb')
> >> > > > +deb_hash =
> ('7fe376fd4452696c03acd508d6d613ca553ea15e')
> >> > > > +deb_path = self.fetch_asset(deb_url,
> asset_hash=deb_hash)
> >> > > > +objcopy_path =
> '/usr/bin/riscv64-linux-gnu-objcopy'
> >> > > > +objcopy_path = self.extract_from_deb(deb_path,
> objcopy_path)
> >> > > > +libbfd_path =
> >> > > '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so
> >> > > '
> >> > > > +libbfd_path = self.extract_from_deb(deb_path,
> libbfd_path)
> >> > > > +process.run('ls 

Re: [Qemu-devel] BDRV request fragmentation and virtio-blk write submission guarantees (2nd try)

[Kevin Wolf]

Am 18.07.2019 um 15:52 hat Евгений Яковлев geschrieben:
> Hi everyone,
> 
> My previous message was misformatted, so here's another one. Sorry about
> that.
> 
> We're currently working on implementing a qemu BDRV format driver which we
> are using with virtio-blk devices.
> 
> I have a question concerning BDRV request fragmentation and virtio-blk write
> request submission which is not entirely clear to me by only reading virtio
> spec. Could you please consider the following case and give some additional
> guidance?
> 
> 1. Our BDRV format driver has a notion of max supported transfer size. So we
> implement BlockDriver::bdrv_refresh_limits where we fill out
> BlockLimits::max_transfer and opt_transfer fields.
> 
> 2. virtio-blk exposes max_transfer as a virtio_blk_config::opt_io_size
> field, which (according to spec 1.1) is a **suggested** maximum. We read
> "suggested" as "guest driver may still send requests that don't fit into
> opt_io_size and we should handle those"...
> 
> 3. ... and judging by code in block/io.c qemu block layer handles such
> requests by fragmenting them into several BDRV requests if request size is >
> max_transfer
> 
> 4. Guest will see request completion only after all fragments are handled.
> However each fragment submission path can call qemu_coroutine_yield and move
> on to submitting next request available in virtq before completely
> submitting the rest of the fragments. Which means the following situation is
> possible where BDRV sees 2 write requests in virtq, both of which are larger
> than max_transfer:
> 
> Blocks: -
> 
> Write1: --
> 
> Write2: --
> 
> Write1Chunk1: 
> 
> Write2Chunk1: 
> 
> Write2Chunk2: 
> 
> Write1Chunk1: 
> 
> Blocks: ---
> 
> 
> In above scenario guest virtio-blk driver decided to submit 2 intersecting
> write requests, both of which are larger than ||max_transfer, and then call
> hypervisor.
> 
> I understand that virtio-blk may handle requests out of order, so guest must
> not make any assumptions on relative order in which those requests will be
> handled.
> 
> However, can guest driver expect that whatever the submission order will be,
> the actual intersecting writes will be atomic?
> 
> In other words, will it be correct for conforming virtio-blk driver to
> expect only "" or "" but not anything else in between, after
> both requests are reported as completed?
> 
> Because i think that is something that may happen in qemu right now, if i
> understood correctly.

I don't think atomicity is promised anywhere in the virtio
specification, and I agree with you that this case can happen (it
probably happens much more frequently when you use image formats instead
of raw files).

On the other hand, there is no good reason for a guest OS to submit two
write request to the same blocks in parallel. Even if it could expect
that one of the requests wins, the end result would still be undefined,
so I don't think this could ever be a useful thing to do. (Well, I guess
it could replace flipping a coin...)

Kevin

Re: [Qemu-devel] [PATCH for-4.1] target/arm: Limit ID register assertions to TCG

[Richard Henderson]

On 7/18/19 5:59 AM, Peter Maydell wrote:
> In arm_cpu_realizefn() we make several assertions about the values of
> guest ID registers:
>  * if the CPU provides AArch32 v7VE or better it must advertise the
>ARM_DIV feature
>  * if the CPU provides AArch32 A-profile v6 or better it must
>advertise the Jazelle feature
> 
> These are essentially consistency checks that our ID register
> specifications in cpu.c didn't accidentally miss out a feature,
> because increasingly the TCG emulation gates features on the values
> in ID registers rather than using old-style checks of ARM_FEATURE_FOO
> bits.
> 
> Unfortunately, these asserts can cause problems if we're running KVM,
> because in that case we don't control the values of the ID registers
> -- we read them from the host kernel.  In particular, if the host
> kernel is older than 4.15 then it doesn't expose the ID registers via
> the KVM_GET_ONE_REG ioctl, and we set up dummy values for some
> registers and leave the rest at zero.  (See the comment in
> target/arm/kvm64.c kvm_arm_get_host_cpu_features().) This set of
> dummy values is not sufficient to pass our assertions, and so on
> those kernels running an AArch32 guest on AArch64 will assert.
> 
> We could provide a more sophisticated set of dummy ID registers in
> this case, but that still leaves the possibility of a host CPU which
> reports bogus ID register values that would cause us to assert.  It's
> more robust to only do these ID register checks if we're using TCG,
> as that is the only case where this is truly a QEMU code bug.
> 
> Reported-by: Laszlo Ersek 
> Fixes: https://bugs.launchpad.net/qemu/+bug/1830864
> Signed-off-by: Peter Maydell 
> ---
> Laszlo, would you mind testing this on your setup? I don't have
> a system with an old enough kernel to trigger the assert. (The
> change is pretty much a "has to work" one though :-))

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH for-4.1] configure: Clarify URL to source downloads

[Stefan Weil]

Am 18.07.2019 um 15:47 schrieb Philippe Mathieu-Daudé:
> On 7/18/19 3:16 PM, Peter Maydell wrote:
>> If configure detects that it's being run on a source tree which
>> is missing git modules, it prints an error messages suggesting
>> that the user downloads a correct source archive from the project
>> website. However https://www.qemu.org/download/ is a link to a
>> page with multiple tabs, with the default being the one telling
>> users how to get binaries from their distro. Clarify the URL
>> we print to include the #source anchor, so that the browser will
>> go directly to the source-tarball instructions.
>>
>> Reported-by: Philippe Mathieu-Daudé 
>> Suggested-by: Stefan Weil 
>> Signed-off-by: Peter Maydell 
>> ---
>>  configure | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index eb635c3b9a5..bf79bbd0e8d 100755
>> --- a/configure
>> +++ b/configure
>> @@ -322,7 +322,7 @@ else
>>  echo "to acquire QEMU source archives. Non-GIT builds are only"
>>  echo "supported with source archives linked from:"
>>  echo
>> -echo "  https://www.qemu.org/download/;
>> +echo "  https://www.qemu.org/download/#source;
> Thanks Peter and Stefan.
>
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Philippe Mathieu-Daudé 


Reviewed-by: Stefan Weil 

Thanks,
Stefan

[Qemu-devel] [Bug 1815423] Re: x86_64 TCG: Incorrect floating point cast to int.

[Peter Maydell]

** Summary changed:

- Incorrect floating point cast to int.
+ x86_64 TCG: Incorrect floating point cast to int.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815423

Title:
  x86_64 TCG: Incorrect floating point cast to int.

Status in QEMU:
  New

Bug description:
  I used exaample from:
  
https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c

  #include 
  #include 

  int main(int argc, char** argv) {
float a = INFINITY;
float b = -INFINITY;
float c = NAN;

printf("float %f %f %f\n", a, b, c); 
printf("int %d %d %d\n", (int) a, (int) b, (int) c); 
printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned 
int) c); 
printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); 
printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, 
(unsigned long int) c); 

return 0;
  }

  And got different results on real computer and on qemu.

  output from real HW is the same as on stackoverflow:

  $ gcc test.c && ./a.out 
  float inf -inf nan
  int -2147483648 -2147483648 -2147483648
  uint 0 0 0
  lint -9223372036854775808 -9223372036854775808 -9223372036854775808
  luint 0 9223372036854775808 9223372036854775808

  
  But on qemu I got another results:

  float inf -inf nan
  int 2147483647 -2147483648 2147483647
  uint 4294967295 0 4294967295
  lint 9223372036854775807 -9223372036854775808 -9223372036854775808
  luint 18446744073709551615 9223372036854775808 9223372036854775807

  qemu launch string:
  /qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev 
user,id=network0 -device e1000,netdev=network0 -kernel my_kernel

  
  qemu version:
  x86_64-softmmu/qemu-system-x86_64 --version
  QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty)
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

  
  This bug affect some javascript (surprise) calculations:

  var conversion = "01234567890";
  var x;
  var result = conversion[x & 42];
  console.log(result)

  
  In example, var x is "undefined"
  and when do calculation "x & 42" on js we should get 0 (it is documented 
feature), but actually got "42"

  and "result" sould be "0" but actually we got "undefined"

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815423/+subscriptions

[Qemu-devel] [Bug 1830864] Re: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(_->isar); })' failed

[Peter Maydell]

** Changed in: qemu
   Status: New => In Progress

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830864

Title:
  Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
  isar_feature_arm_div(_->isar); })' failed

Status in QEMU:
  In Progress

Bug description:
  The following assertion:

  assert(no_aa32 || cpu_isar_feature(arm_div, cpu));

  introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some
  asserts on aarch32 support", 2018-11-02), fails for me. I intended to
  launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host
  (APM Mustang A3).

  Libvirt generated the following QEMU command line:

  > LC_ALL=C \
  > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
  > QEMU_AUDIO_DRV=none \
  > /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \
  >   -name guest=f28.32bit,debug-threads=on \
  >   -S \
  >   -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes
 \
  >   -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \
  >   -cpu host,aarch64=off \
  >   -drive 
file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \
  >   -drive 
file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \
  >   -m 8192 \
  >   -realtime mlock=off \
  >   -smp 8,sockets=8,cores=1,threads=1 \
  >   -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \
  >   -no-user-config \
  >   -nodefaults \
  >   -chardev socket,id=charmonitor,fd=27,server,nowait \
  >   -mon chardev=charmonitor,id=monitor,mode=control \
  >   -rtc base=utc \
  >   -no-shutdown \
  >   -boot strict=on \
  >   -device 
pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 
\
  >   -device 
pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
  >   -device 
pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
  >   -device 
pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \
  >   -device 
pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \
  >   -device 
pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \
  >   -device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \
  >   -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \
  >   -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
  >   -drive 
file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap
 \
  >   -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
 \
  >   -drive 
file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap
 \
  >   -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on
 \
  >   -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \
  >   -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile=
 \
  >   -chardev pty,id=charserial0 \
  >   -serial chardev:charserial0 \
  >   -chardev socket,id=charchannel0,fd=31,server,nowait \
  >   -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 \
  >   -device usb-tablet,id=input0,bus=usb.0,port=1 \
  >   -device usb-kbd,id=input1,bus=usb.0,port=2 \
  >   -vnc 127.0.0.1:0 \
  >   -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \
  >   -object rng-random,id=objrng0,filename=/dev/urandom \
  >   -device 
virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0
 \
  >   -msg timestamp=on

  and then I got:

  > qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986:
  > arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
  > isar_feature_arm_div(_->isar); })' failed.

  QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch
  'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging",
  2019-05-23).

  (Originally reported on the mailing list in the following thread:
  
.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1830864/+subscriptions

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

[Richard Henderson]

On 7/17/19 11:01 PM, tony.ngu...@bt.com wrote:
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
> 
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is now
> accelerator independent MemOp"
> 
> Signed-off-by: Tony Nguyen 
> ---
>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)

Thanks for this.
Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [Bug 1836501] Re: cpu_address_space_init fails with assertion

[Peter Maydell]

I can boot a KVM guest (either with the debian stretch qemu-system-arm
2.8.1, or with a head-of-upstream-git QEMU), which wouldn't work with
EL3 enabled, so I'm not sure what is going wrong for you. To try to
debug this further you'd need to build QEMU from source and start
running it under the debugger to see what exactly is going on and why
it's hitting that assertion.

I would be tempted to try a newer kernel to see if that helped. (My
working setup is using the debian stretch stock "4.9.0-0.bpo.9-armmp-
lpae #1 SMP Debian 4.9.168-1+deb9u3~deb8u1 (2019-06-17)", but in general
4.9 is fairly elderly now.)

For forums to talk about this kind of thing you might also try the qemu-
arm mailing list (https://lists.nongnu.org/mailman/listinfo/qemu-arm) or
qemu-devel itself (generally best to cc qemu-devel on qemu-arm emails
anyway, lots of people don't subscribe to the per-architecture lists).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836501

Title:
  cpu_address_space_init fails with assertion

Status in QEMU:
  Confirmed

Bug description:
  qemu-system-arm does not start with version >= 2.6 and KVM enabled.

cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()'
  failed.

  Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian
  Stretch (9) or Buster (10).

  Without KVM it is running fine but slow. I'm operating Debian Jessie
  with qemu 2.1 for a long time with KVM virtualization working
  flawlessly. When I upgraded to Stretch I ran into the trouble
  described before. I tried Debian Stretch and Buster with all Kernels
  provided by the Board manufacturer (Hardkernel).

  It seems to be related to the feature introduced in Version 2.6:
  https://wiki.qemu.org/ChangeLog/2.6
  - Support for a separate EL3 address space

  KVM is enabled, so I assume the adress space index asidx to be causing
  the assert to fail.

  dmesg | grep -i KVM
  [0.741714] kvm [1]: 8-bit VMID
  [0.741721] kvm [1]: IDMAP page: 40201000
  [0.741729] kvm [1]: HYP VA range: c000:
  [0.742543] kvm [1]: Hyp mode initialized successfully
  [0.742600] kvm [1]: vgic-v2@10484000
  [0.742924] kvm [1]: vgic interrupt IRQ16
  [0.742943] kvm [1]: virtual timer IRQ60

  Full command line is:
  qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel 
vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device 
virtio-blk-device,drive=inst-blk -drive 
file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw 
console=ttyAMA0" -nographic

  Is there anything to do to understand, if this is a hardware related
  failure or probably just a missing parameter?

  Regards

  Lutz

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836501/+subscriptions

Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type

[Sergio Lopez]

Sergio Lopez  writes:

> Paolo Bonzini  writes:
>
>> On 02/07/19 12:52, Sergio Lopez wrote:
>>> As I said, I'm also in favor of microvm supporting booting from
>>> firmware in the future, as long we keep the simple mode too.
>>
>> The simple mode adds code to QEMU's x86 target that only exists to
>> support microvm.  It should be motivated by a clear win in boot times.
>
> OK. When I'm back from my PTO, I'll work on adding the firmware
> support to microvm. I'll run and share some numbers to see whether the
> simple mode makes sense or we can just rely on qboot for lower boot
> times plus SeaBIOS for compatibility.

I've just added support for starting the machine from SeaBIOS (Stefan
Hajnoczi pointed in another thread that it can be as fast as qboot, and
given that the latter doesn't support mptables, I just tested this
one). I tried to keep it as minimalistic as possible, but it still
required an RTC (mc146818), which dragged in an ISA BUS, and this one a
KVM PIT.

I ran some numbers using Stefano Garzarella's qemu-boot-time scripts
[1] on a server with 2xIntel Xeon Silver 4114 2.20GHz, using the
upstream QEMU (474f3938d79ab36b9231c9ad3b5a9314c2aeacde) built with
minimal features [2]. The VM boots a minimal kernel [3] without initrd,
using a kata container image as root via virtio-blk (though this isn't
really relevant, as we're just taking measurements until the kernel is
about to exec init).

 -
 | QEMU with SeaBIOS |
 -

Command line:

./x86_64-softmmu/qemu-system-x86_64 -m 512m -enable-kvm -M microvm,legacy 
-kernel /root/src/images/vmlinux-5.2 -append "console=hvc0 reboot=k panic=1 
root=/dev/vda quiet virtio_mmio.device=512@0xd600:15 
virtio_mmio.device=512@0xd400:14" -smp 1 -nodefaults -no-user-config 
-chardev pty,id=virtiocon0,server -device virtio-serial-device -device 
virtconsole,chardev=virtiocon0 -drive 
id=test,file=/usr/share/kata-containers/kata-containers.img,format=raw,if=none 
-device virtio-blk-device,drive=test -monitor stdio

Average boot times after 10 consecutive runs:

 qemu_init_end: 65.958714
 linux_start_kernel: 77.735803 (+11.777089)
 linux_start_user: 127.360739 (+49.624936)

Exposed I/O ports and MMIOs:

 address-space: memory
  - (prio 0, i/o): system
-1fff (prio 0, i/o): alias ram-below-4g 
@microvm.ram -1fff
000e-000f (prio 1, i/o): alias isa-bios @pc.bios 
-0001
d000-d1ff (prio 0, i/o): virtio-mmio
d200-d3ff (prio 0, i/o): virtio-mmio
d400-d5ff (prio 0, i/o): virtio-mmio
d600-d7ff (prio 0, i/o): virtio-mmio
fee0-feef (prio 4096, i/o): kvm-apic-msi
fffe- (prio 0, ram): pc.bios

 address-space: I/O
  - (prio 0, i/o): io
0020-0021 (prio 0, i/o): kvm-pic
0040-0043 (prio 0, i/o): kvm-pit
0070-0071 (prio 0, i/o): rtc
  0070-0070 (prio 0, i/o): rtc-index
007e-007f (prio 0, i/o): kvmvapic
00a0-00a1 (prio 0, i/o): kvm-pic
04d0-04d0 (prio 0, i/o): kvm-elcr
04d1-04d1 (prio 0, i/o): kvm-elcr
0510-0511 (prio 0, i/o): fwcfg
0514-051b (prio 0, i/o): fwcfg.dma


 ---
 | QEMU direct PVH |
 ---

Command line:

 ./x86_64-softmmu/qemu-system-x86_64 -m 512m -enable-kvm -M microvm -kernel 
/root/src/images/vmlinux-5.2 -append "console=hvc0 reboot=k panic=1 
root=/dev/vda quiet" -smp 1 -nodefaults -no-user-config -chardev 
pty,id=virtiocon0,server -device virtio-serial-device -device 
virtconsole,chardev=virtiocon0 -drive 
id=test,file=/usr/share/kata-containers/kata-containers.img,format=raw,if=none 
-device virtio-blk-device,drive=test -monitor stdio

Average boot times after 10 consecutive runs:

 qemu_init_end: 64.043264
 linux_start_kernel: 65.481782 (+1.438518)
 linux_start_user: 114.938353 (+49.456571)

Exposed I/O ports and MMIOs:

 address-space: memory
  - (prio 0, i/o): system
-1fff (prio 0, i/o): alias ram-below-4g 
@microvm.ram -1fff
d000-d1ff (prio 0, i/o): virtio-mmio
d200-d3ff (prio 0, i/o): virtio-mmio
d400-d5ff (prio 0, i/o): virtio-mmio
d600-d7ff (prio 0, i/o): virtio-mmio
fec0-fec00fff (prio 0, i/o): kvm-ioapic
fee0-feef (prio 4096, i/o): kvm-apic-msi

 address-space: I/O
  - (prio 0, 

[Qemu-devel] [Bug 1837049] [NEW] qemu-system-ppc segfaults with -display sdl

[Andrew Randrianasulu]

Public bug reported:

Hello.

I was trying to debug this segfault:
https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html

I recompiled latest qemu from git (commit 
0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line:
./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu 
--audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg

after this I tried original line under gdb, it was still segfaulting:

--copy-
gdb ./ppc-softmmu/qemu-system-ppc
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./ppc-softmmu/qemu-system-ppc...done.
warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your 
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /dev/shm/qemu/.gdbinit
line to your configuration file "/home/guest/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/guest/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L 
../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso 
-m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 
1024x768x24 -device ES1370
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xf560cb40 (LWP 8100)]
[New Thread 0xf4c1ab40 (LWP 8101)]
[New Thread 0xec1b7b40 (LWP 8102)]
[New Thread 0xc5821b40 (LWP 8104)]
[Thread 0xf4c1ab40 (LWP 8101) exited]
[New Thread 0xf4c1ab40 (LWP 8119)]

Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xec1b7b40 (LWP 8102)]
0xf26c2e44 in code_gen_buffer ()
(gdb) bt full
#0  0x in code_gen_buffer ()
#1  0x56710cf6 in cpu_exec (itb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:173
env = 
ret = 
last_tb = 
tb_exit = 
tb_ptr = 0xf26c2cc0  "‹]ш…Ы\017ЊБ\020"
ret = 0
insns_left = 
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#2  0x56710cf6 in cpu_exec (tb_exit=, last_tb=, tb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:621
ret = 0
insns_left = 
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#3  0x56710cf6 in cpu_exec (cpu=0x573db8f8) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:732
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#4  0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435
ret = 
#5  0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at 
/dev/shm/qemu/cpus.c:1537
r = 
cpu = 0x573db8f8
__PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn"
#6  0x56b56fe0 in qemu_thread_start (args=0x57400668) at 
util/qemu-thread-posix.c:502
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 
1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 
0}}, __pad = {0xec1b70d0, 0x0, 0x0, 0x0}}
__cancel_routine = 0x56b57040 
__not_first_call = 
qemu_thread_args = 0x57400668
start_routine = 0x566d1a30 
arg = 0x573db8f8
r = 
#7  0x in start_thread () at /lib/libpthread.so.0
#8  0x in clone () at /lib/libc.so.6
(gdb) quit
A debugging session is active.

Inferior 1 [process 8096] will be killed.

Quit anyway? (y or n) y
--copy end--

But when I take away -display sdl, or replace it with -display gtk -
same line was booting to desktop!

Changing cpu to G3 also allowed boot:

[Qemu-devel] BDRV request fragmentation and virtio-blk write submission guarantees (2nd try)

[Евгений Яковлев]

Hi everyone,

My previous message was misformatted, so here's another one. Sorry about 
that.


We're currently working on implementing a qemu BDRV format driver which 
we are using with virtio-blk devices.


I have a question concerning BDRV request fragmentation and virtio-blk 
write request submission which is not entirely clear to me by only 
reading virtio spec. Could you please consider the following case and 
give some additional guidance?


1. Our BDRV format driver has a notion of max supported transfer size. 
So we implement BlockDriver::bdrv_refresh_limits where we fill out 
BlockLimits::max_transfer and opt_transfer fields.


2. virtio-blk exposes max_transfer as a virtio_blk_config::opt_io_size 
field, which (according to spec 1.1) is a **suggested** maximum. We read 
"suggested" as "guest driver may still send requests that don't fit into 
opt_io_size and we should handle those"...


3. ... and judging by code in block/io.c qemu block layer handles such 
requests by fragmenting them into several BDRV requests if request size 
is > max_transfer


4. Guest will see request completion only after all fragments are 
handled. However each fragment submission path can call 
qemu_coroutine_yield and move on to submitting next request available in 
virtq before completely submitting the rest of the fragments. Which 
means the following situation is possible where BDRV sees 2 write 
requests in virtq, both of which are larger than max_transfer:


Blocks: -

Write1: --

Write2: --

Write1Chunk1: 

Write2Chunk1: 

Write2Chunk2: 

Write1Chunk1: 

Blocks: ---


In above scenario guest virtio-blk driver decided to submit 2 
intersecting write requests, both of which are larger than 
||max_transfer, and then call hypervisor.


I understand that virtio-blk may handle requests out of order, so guest 
must not make any assumptions on relative order in which those requests 
will be handled.


However, can guest driver expect that whatever the submission order will 
be, the actual intersecting writes will be atomic?


In other words, will it be correct for conforming virtio-blk driver to 
expect only "" or "" but not anything else in between, 
after both requests are reported as completed?


Because i think that is something that may happen in qemu right now, if 
i understood correctly.




Thanks!

Re: [Qemu-devel] [PATCH 1/1] x86: add CPU flags supported inside libvirt

[Paolo Bonzini]

On 18/07/19 15:45, Denis V. Lunev wrote:
> There are the following flags available in libvirt inside cpu_map.xm
> 
>   
> 
>  
>   
> 
> We have faced the problem that QEMU does not start once these flags are
> present in the domain.xml.
> 
> This patch just adds proper names into the map.
> 
> Signed-off-by: Denis V. Lunev 
> CC: Paolo Bonzini 
> CC: Richard Henderson 
> CC: Eduardo Habkost 
> CC: Nikolay Shirokovskiy 
> CC: Peter Krempa 
> CC: Daniel P. Berrangé 
> ---
>  target/i386/cpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 805ce95247..88ba4dad47 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -870,7 +870,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
> {
>  "lahf-lm", "cmp-legacy", "svm", "extapic",
>  "cr8legacy", "abm", "sse4a", "misalignsse",
>  "3dnowprefetch", "osvw", "ibs", "xop",
> -"skinit", "wdt", NULL, "lwp",
> +"skinit", "wdt", "cvt16", "lwp",
>  "fma4", "tce", NULL, "nodeid-msr",
>  NULL, "tbm", "topoext", "perfctr-core",
>  "perfctr-nb", NULL, NULL, NULL,
> @@ -1044,7 +1044,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
> = {
>  "fsgsbase", "tsc-adjust", NULL, "bmi1",
>  "hle", "avx2", NULL, "smep",
>  "bmi2", "erms", "invpcid", "rtm",
> -NULL, NULL, "mpx", NULL,
> +"cmt", NULL, "mpx", NULL,
>  "avx512f", "avx512dq", "rdseed", "adx",
>  "smap", "avx512ifma", "pcommit", "clflushopt",
>  "clwb", "intel-pt", "avx512pf", "avx512er",
> 

Oops, nice catch!  I've queued the patch for 4.1.

Paolo

Re: [Qemu-devel] [PATCH for-4.1] configure: Clarify URL to source downloads

[Philippe Mathieu-Daudé]

On 7/18/19 3:16 PM, Peter Maydell wrote:
> If configure detects that it's being run on a source tree which
> is missing git modules, it prints an error messages suggesting
> that the user downloads a correct source archive from the project
> website. However https://www.qemu.org/download/ is a link to a
> page with multiple tabs, with the default being the one telling
> users how to get binaries from their distro. Clarify the URL
> we print to include the #source anchor, so that the browser will
> go directly to the source-tarball instructions.
> 
> Reported-by: Philippe Mathieu-Daudé 
> Suggested-by: Stefan Weil 
> Signed-off-by: Peter Maydell 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index eb635c3b9a5..bf79bbd0e8d 100755
> --- a/configure
> +++ b/configure
> @@ -322,7 +322,7 @@ else
>  echo "to acquire QEMU source archives. Non-GIT builds are only"
>  echo "supported with source archives linked from:"
>  echo
> -echo "  https://www.qemu.org/download/;
> +echo "  https://www.qemu.org/download/#source;

Thanks Peter and Stefan.

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

>  echo
>  echo "Developers working with GIT can use scripts/archive-source.sh"
>  echo "if they need to create valid source archives."
> 

[Qemu-devel] [PATCH 1/1] x86: add CPU flags supported inside libvirt

[Denis V. Lunev]

There are the following flags available in libvirt inside cpu_map.xm

  

 
  

We have faced the problem that QEMU does not start once these flags are
present in the domain.xml.

This patch just adds proper names into the map.

Signed-off-by: Denis V. Lunev 
CC: Paolo Bonzini 
CC: Richard Henderson 
CC: Eduardo Habkost 
CC: Nikolay Shirokovskiy 
CC: Peter Krempa 
CC: Daniel P. Berrangé 
---
 target/i386/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 805ce95247..88ba4dad47 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -870,7 +870,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 "lahf-lm", "cmp-legacy", "svm", "extapic",
 "cr8legacy", "abm", "sse4a", "misalignsse",
 "3dnowprefetch", "osvw", "ibs", "xop",
-"skinit", "wdt", NULL, "lwp",
+"skinit", "wdt", "cvt16", "lwp",
 "fma4", "tce", NULL, "nodeid-msr",
 NULL, "tbm", "topoext", "perfctr-core",
 "perfctr-nb", NULL, NULL, NULL,
@@ -1044,7 +1044,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 "fsgsbase", "tsc-adjust", NULL, "bmi1",
 "hle", "avx2", NULL, "smep",
 "bmi2", "erms", "invpcid", "rtm",
-NULL, NULL, "mpx", NULL,
+"cmt", NULL, "mpx", NULL,
 "avx512f", "avx512dq", "rdseed", "adx",
 "smap", "avx512ifma", "pcommit", "clflushopt",
 "clwb", "intel-pt", "avx512pf", "avx512er",
-- 
2.17.1

[Qemu-devel] BDRV request fragmentation and vitio-blk write submission guarantees

[Евгений Яковлев]

Hi everyone,

We're currently working on implementing a qemu BDRV format driver which 
we are using with virtio-blk devices.


I have a question concerning BDRV request fragmentation and virtio-blk 
write request submission which is not entirely clear to me by only 
reading virtio spec. Could you please consider the following case and 
give some additional guidance?


1. Our BDRV format driver has a notion of max supported transfer size. 
So we implement BlockDriver::bdrv_refresh_limits where we fill out 
BlockLimits::max_transfer and opt_transfer fields.


2. virtio-blk exposes max_transfer as a virtio_blk_config::opt_io_size 
field, which (according to spec 1.1) is a **suggested** maximum. We read 
"suggested" as "guest driver may still send requests that don't fit into 
opt_io_size and we should handle those"...


3. ... and judging by code in block/io.c qemu block layer handles such 
requests by fragmenting them into several BDRV requests if request size 
is > max_transfer


4. Guest will see request completion only after all fragments are 
handled. However each fragment submission path can call 
qemu_coroutine_yield and move on to submitting next request available in 
virtq before completely submitting the rest of the fragments. Which 
means the following situation is possible where BDRV sees 2 write 
requests in virtq, both of which are larger than max_transfer:


||

|Blocks: |-> Write1:  
Write2:  Write1Chunk1:  Write2Chunk1:  Write2Chunk2: 
 Write1Chunk1:  Blocks: |->|


||

|In above scenario guest virtio-blk driver decided to submit 2 
intersecting write requests, both of which are larger than 
||max_transfer, and then call hypervisor.|


|I understand that virtio-blk may handle requests out of order, so guest 
must not make any assumptions on relative order in which those requests 
will be handled.|


|However, can guest driver expect that whatever the submission order 
will be, the actual intersecting writes will be atomic?|


|In other words, will it be correct for conforming virtio-blk driver to 
expect only "|||" or "" but not anything else in 
between, after both requests are reported as completed?||


||Because i think that is something that may happen in qemu right now, 
if i understood correctly. ||




||Thanks!| |

Re: [Qemu-devel] [PATCH V3] net/colo-compare.c: Fix memory leak and code style issue.

[Peter Maydell]

On Thu, 18 Jul 2019 at 10:27, Zhang Chen  wrote:
>
> From: Zhang Chen 
>
> This patch to fix the origin "char *data" menory leak, code style issue
> and add necessary check here.
> Reported-by: Coverity (CID 1402785)
>
> Signed-off-by: Zhang Chen 
> ---
>  net/colo-compare.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/net/colo-compare.c b/net/colo-compare.c
> index 909dd6c6eb..fcccb4c6f6 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -127,6 +127,17 @@ static int compare_chr_send(CompareState *s,
>  uint32_t vnet_hdr_len,
>  bool notify_remote_frame);
>
> +static bool packet_matches_str(const char *str,
> +   uint8_t *buf,
> +   uint32_t packet_len)
> +{
> +if (packet_len != strlen(str)) {

Is '!=' definitely correct? (ie the incoming packet must
*not* contain a trailing '\0' or any other trailing data) ?

Is there a specification of the protocol somewhere? If
so, that presumably should say one way or the other.

> +return false;
> +}
> +
> +return !memcmp(str, buf, strlen(str));
> +}

thanks
-- PMM

Re: [Qemu-devel] [PATCH for-4.1] configure: Clarify URL to source downloads

[Thomas Huth]

On 18/07/2019 15.16, Peter Maydell wrote:
> If configure detects that it's being run on a source tree which
> is missing git modules, it prints an error messages suggesting
> that the user downloads a correct source archive from the project
> website. However https://www.qemu.org/download/ is a link to a
> page with multiple tabs, with the default being the one telling
> users how to get binaries from their distro. Clarify the URL
> we print to include the #source anchor, so that the browser will
> go directly to the source-tarball instructions.
> 
> Reported-by: Philippe Mathieu-Daudé 
> Suggested-by: Stefan Weil 
> Signed-off-by: Peter Maydell 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index eb635c3b9a5..bf79bbd0e8d 100755
> --- a/configure
> +++ b/configure
> @@ -322,7 +322,7 @@ else
>  echo "to acquire QEMU source archives. Non-GIT builds are only"
>  echo "supported with source archives linked from:"
>  echo
> -echo "  https://www.qemu.org/download/;
> +echo "  https://www.qemu.org/download/#source;
>  echo
>  echo "Developers working with GIT can use scripts/archive-source.sh"
>  echo "if they need to create valid source archives."
> 

Reviewed-by: Thomas Huth 

[Qemu-devel] [PATCH for-4.1] configure: Clarify URL to source downloads

[Peter Maydell]

If configure detects that it's being run on a source tree which
is missing git modules, it prints an error messages suggesting
that the user downloads a correct source archive from the project
website. However https://www.qemu.org/download/ is a link to a
page with multiple tabs, with the default being the one telling
users how to get binaries from their distro. Clarify the URL
we print to include the #source anchor, so that the browser will
go directly to the source-tarball instructions.

Reported-by: Philippe Mathieu-Daudé 
Suggested-by: Stefan Weil 
Signed-off-by: Peter Maydell 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index eb635c3b9a5..bf79bbd0e8d 100755
--- a/configure
+++ b/configure
@@ -322,7 +322,7 @@ else
 echo "to acquire QEMU source archives. Non-GIT builds are only"
 echo "supported with source archives linked from:"
 echo
-echo "  https://www.qemu.org/download/;
+echo "  https://www.qemu.org/download/#source;
 echo
 echo "Developers working with GIT can use scripts/archive-source.sh"
 echo "if they need to create valid source archives."
-- 
2.20.1

Re: [Qemu-devel] No archives to download from www.qemu.org/download/

[Peter Maydell]

On Thu, 18 Jul 2019 at 12:50, Stefan Weil  wrote:
>
> Am 18.07.2019 um 13:29 schrieb Thomas Huth:
> > I guess we should simply re-arrange the order of the tabs ... the
> > OS-agnostic source code tab should come first (since this is about what
> > we provide for download on our site), and then the others with
> > references to the distros etc.
> >
> > Does someone care to send a patch?
>
>
> Wouldn't changing the link to https://www.qemu.org/download/#source be
> even simpler?

This gets my vote -- I'll send a configure patch...

thanks
-- PMM

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Paolo Bonzini]

On 18/07/19 14:49, Daniel P. Berrangé wrote:
> On Thu, Jul 18, 2019 at 04:04:13PM +0400, Marc-André Lureau wrote:
>> Our module system does not support Windows, because it relies on
>> resolving symbols from the main executable.
>>
>> If there is enough interest in supporting modules on Windows, we could
>> generate an import library for the executable and link with it:
>> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
>>
>> However, there is a small chicken egg problem, since the executable
>> link and exports extra symbols needed by the library...
> 
> The "solution" to that would presumably be to put everything into a
> library, and the executable merely becomes trivial main() that calls
> a "runme" function in the library. It is kind of ugly though as we
> would need a separate library for each system emulator executable.
> 
> Just ignoring modules on Windows looks like the prudent solution.

See https://github.com/mesonbuild/meson/pull/3683#issuecomment-467815241

The trick is to build the modules in two phases, first as a static
library and then as a shared module (with Meson you'd use link_whole).
Then the list of symbols can be gleaned from the static libraries, but
the executable can still be linked before the shared module:

modules_objs = {}
modules_objs += { 'b': static_library('b.mo', 'src.c', pic: true) }
# ...

undef = []
undefdeps = []
foreach name, lib : modules_objs
shared_module(name, link_whole: lib, link_with: e)
undefdeps += [custom_target('undefsym', output: [name+'.undef'],
input: lib,
command: [files('undefsym.sh'),
  '@OUTPUT0@', '@INPUT@'])]
undef += [ '@' + name + '.undef' ]
endforeach

libutil = static_library('util', 'util.c', pic: true)
e = executable('a', 'main.c', link_with: [libutil],
   link_args: undef, link_depends: undefdeps,
   implib: true)

This in fact is exactly what we're doing now, just with a .o file and
"ld -r" instead of a .a file that is wholly-linked into the shared module.

Paolo

Re: [Qemu-devel] [PATCH-for-4.2 v7 10/10] tests: Update DSDT ACPI table for arm/virt board with PCDIMM related changes

[Igor Mammedov]

On Tue, 16 Jul 2019 16:38:16 +0100
Shameer Kolothum  wrote:

> From: Eric Auger 
> 
> PCDIMM hotplug addition updated the DSDT. Update the reference table.

it's not correct process. series should be merged through Michael's pci branch
and see
commit ab50f22309a17c772c51931940596e707c200739 (mst/pci)
Author: Michael S. Tsirkin 
Date:   Tue May 21 17:38:47 2019 -0400

bios-tables-test: add diff allowed list

how to request table update.


Another thing:
bios-tables-test has test_acpi_tcg_dimm_pxm() test case,
pls make use of it to test arm/virt variant

> 
> Signed-off-by: Eric Auger 
> Signed-off-by: Shameer Kolothum 
> Reviewed-by: Igor Mammedov 
> ---
>  tests/data/acpi/virt/DSDT | Bin 18476 -> 18493 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT
> index 
> 20e85c7f89f645c69935c615c07084e221419960..1a5c3e5243c78eb25345fdf7ffa442afec3c5c28
>  100644
> GIT binary patch
> delta 172
> zcmZ28fpPByMlP3Nmk?VI1_q{Y6S<_BIvO{s=eSSi^^mWRZt~=a(Tfjuig$N)iRXy-
> z@O0sIbPn(|FfcS`;D`?ea)A;+mUB?BARiZZCmRDZqb36bLnT9WgKLnhI|B~`0|zG;
> zOLQYQi0kYc?CPT+ViNBf7Q$Ho;v_5(n_Qj1$iNt**CW8$H`v*4fdEjLhl`1U
> Ni>WOjJjjWw0RY`tDw+TQ  
> 
> delta 134
> zcmdlxfpN_QMlP3Nmk=Ef1_q{ziCof5?F}2%bKIpo*xdvC4LIUGJY9GlgM2*<49pA}
> zIN}{$f+og`c`$P_2rw{ovN13+sxvS!RDxt?7@-g-A Z11c2ZjdwLLW@rlt4|3vam^{&45den68LI#Q
> 

[Qemu-devel] [Bug 1830864] Re: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(_->isar); })' failed

[Peter Maydell]

This happens because:
 * the host kernel is older than 4.15 and does not expose ID registers to 
userspace via the KVM_GET_ONE_REG ioctl
 * our fallback set of ID register values in target/arm/kvm64.c 
kvm_arm_get_host_cpu_features() is extremely minimalist
 * the consistency checks on ID register values in arm_cpu_realizefn() are made 
unconditionally, rather than only if we're using TCG

https://patchwork.ozlabs.org/patch/1133724/ is a fix for this which
takes the approach of only asserting if we're using TCG, since that's
really the case we're guarding for problems with and the only one that's
a bug in QEMU (as opposed to an issue with the host kernel or host CPU).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830864

Title:
  Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
  isar_feature_arm_div(_->isar); })' failed

Status in QEMU:
  New

Bug description:
  The following assertion:

  assert(no_aa32 || cpu_isar_feature(arm_div, cpu));

  introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some
  asserts on aarch32 support", 2018-11-02), fails for me. I intended to
  launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host
  (APM Mustang A3).

  Libvirt generated the following QEMU command line:

  > LC_ALL=C \
  > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
  > QEMU_AUDIO_DRV=none \
  > /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \
  >   -name guest=f28.32bit,debug-threads=on \
  >   -S \
  >   -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes
 \
  >   -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \
  >   -cpu host,aarch64=off \
  >   -drive 
file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \
  >   -drive 
file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \
  >   -m 8192 \
  >   -realtime mlock=off \
  >   -smp 8,sockets=8,cores=1,threads=1 \
  >   -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \
  >   -no-user-config \
  >   -nodefaults \
  >   -chardev socket,id=charmonitor,fd=27,server,nowait \
  >   -mon chardev=charmonitor,id=monitor,mode=control \
  >   -rtc base=utc \
  >   -no-shutdown \
  >   -boot strict=on \
  >   -device 
pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 
\
  >   -device 
pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
  >   -device 
pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
  >   -device 
pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \
  >   -device 
pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \
  >   -device 
pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \
  >   -device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \
  >   -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \
  >   -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
  >   -drive 
file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap
 \
  >   -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
 \
  >   -drive 
file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap
 \
  >   -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on
 \
  >   -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \
  >   -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile=
 \
  >   -chardev pty,id=charserial0 \
  >   -serial chardev:charserial0 \
  >   -chardev socket,id=charchannel0,fd=31,server,nowait \
  >   -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 \
  >   -device usb-tablet,id=input0,bus=usb.0,port=1 \
  >   -device usb-kbd,id=input1,bus=usb.0,port=2 \
  >   -vnc 127.0.0.1:0 \
  >   -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \
  >   -object rng-random,id=objrng0,filename=/dev/urandom \
  >   -device 
virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0
 \
  >   -msg timestamp=on

  and then I got:

  > qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986:
  > arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
  > isar_feature_arm_div(_->isar); })' failed.

  QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch
  'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging",
  2019-05-23).

  (Originally reported on the mailing list in the following thread:
  
.)

To manage notifications about this bug go to:

[Qemu-devel] [PATCH v6] linux-user: fix to handle variably sized SIOCGSTAMP with new kernels

[Laurent Vivier]

From: Daniel P. Berrangé 

The SIOCGSTAMP symbol was previously defined in the
asm-generic/sockios.h header file. QEMU sees that header
indirectly via sys/socket.h

In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
Instead it provides only SIOCGSTAMP_OLD, which only uses a
32-bit time_t on 32-bit architectures.

The linux/sockios.h header then defines SIOCGSTAMP using
either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
on 32-bit architectures

To cope with this we must now convert the old and new type from
the target to the host one.

Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Laurent Vivier 
Reviewed-by: Arnd Bergmann 
---

Notes:
v6: [lv] fix IOCTLEntry entries (host_cmd and name)
v5: [lv] define special _OLD values for sh
define special case for SPARC64
define ioctl helpers
define target__kernel_sock_timeval and target__kernel_timespec and
converters to the host type
always use SIOCGSTAMP and SIOCGSTAMPNS on the host

v4: [lv] timeval64 and timespec64 are { long long , long }

v3: [lv] redefine TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMPNS_NEW,
timeval64 and timespec64 to use 0x89 type and abi_llong[2]

v2: [dpb] implement _NEW and _OLD variants

 linux-user/ioctls.h|  21 +-
 linux-user/syscall.c   | 140 +
 linux-user/syscall_defs.h  |  30 +++-
 linux-user/syscall_types.h |   6 --
 4 files changed, 159 insertions(+), 38 deletions(-)

diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 5e84dc7c3a77..3281c97ca263 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -222,8 +222,25 @@
   IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
   IOCTL(SIOCSPGRP, IOC_W, MK_PTR(TYPE_INT)) /* pid_t */
   IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
-  IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
-  IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
+
+  /*
+   * We can't use IOCTL_SPECIAL() because it will set
+   * host_cmd to XXX_OLD and XXX_NEW and these macros
+   * are not defined with kernel prior to 5.2.
+   * We must set host_cmd to the same value as in target_cmd
+   * otherwise the consistency check in syscall_init()
+   * will trigger an error.
+   * host_cmd is ignored by the do_ioctl_XXX() helpers.
+   * FIXME: create a macro to define this kind of entry
+   */
+  { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
+"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
+  { TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
+"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
+  { TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
+"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
+  { TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
+"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
 
   IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
   IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 39a37496fed5..8367cb138dfe 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1126,8 +1127,9 @@ static inline abi_long copy_from_user_timeval(struct 
timeval *tv,
 {
 struct target_timeval *target_tv;
 
-if (!lock_user_struct(VERIFY_READ, target_tv, target_tv_addr, 1))
+if (!lock_user_struct(VERIFY_READ, target_tv, target_tv_addr, 1)) {
 return -TARGET_EFAULT;
+}
 
 __get_user(tv->tv_sec, _tv->tv_sec);
 __get_user(tv->tv_usec, _tv->tv_usec);
@@ -1142,8 +1144,26 @@ static inline abi_long copy_to_user_timeval(abi_ulong 
target_tv_addr,
 {
 struct target_timeval *target_tv;
 
-if (!lock_user_struct(VERIFY_WRITE, target_tv, target_tv_addr, 0))
+if (!lock_user_struct(VERIFY_WRITE, target_tv, target_tv_addr, 0)) {
+return -TARGET_EFAULT;
+}
+
+__put_user(tv->tv_sec, _tv->tv_sec);
+__put_user(tv->tv_usec, _tv->tv_usec);
+
+unlock_user_struct(target_tv, target_tv_addr, 1);
+
+return 0;
+}
+
+static inline abi_long copy_to_user_timeval64(abi_ulong target_tv_addr,
+ const struct timeval *tv)
+{
+struct target__kernel_sock_timeval *target_tv;
+
+if (!lock_user_struct(VERIFY_WRITE, target_tv, target_tv_addr, 0)) {
 return -TARGET_EFAULT;
+}
 
 __put_user(tv->tv_sec, _tv->tv_sec);
 __put_user(tv->tv_usec, _tv->tv_usec);
@@ -1153,6 +1173,48 @@ static inline abi_long copy_to_user_timeval(abi_ulong 
target_tv_addr,
 return 0;
 }
 
+static inline abi_long target_to_host_timespec(struct timespec *host_ts,
+   abi_ulong target_addr)
+{
+struct target_timespec *target_ts;
+
+if (!lock_user_struct(VERIFY_READ, target_ts, 

Re: [Qemu-devel] [PATCH-for-4.2 v7 08/10] hw/acpi: Add system power down support to GED

[Igor Mammedov]

On Tue, 16 Jul 2019 16:38:14 +0100
Shameer Kolothum  wrote:

> This adds support to use GED for system power down event.
[...]

> @@ -232,6 +238,13 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, 
> AcpiEventStatusBits ev)
>  acpi_ged_event(s, sel);
>  }
>  
> +static void acpi_ged_pm_powerdown_req(Notifier *n, void *opaque)
> +{
> +AcpiGedState *s = container_of(n, AcpiGedState, powerdown_notifier);
> +
> +acpi_ged_event(s, ACPI_GED_PWR_DOWN_EVT);
> +}
> +
>  static void acpi_ged_device_realize(DeviceState *dev, Error **errp)
>  {
>  AcpiGedState *s = ACPI_GED(dev);
> @@ -243,6 +256,9 @@ static void acpi_ged_device_realize(DeviceState *dev, 
> Error **errp)
>  }
>  
>  acpi_ged_init(get_system_memory(), dev, >ged_state);
> +
> +s->powerdown_notifier.notify = acpi_ged_pm_powerdown_req;

one more thing:
I'd reuse virt_powerdown_req() instead.

pass it machine pointer and then from notifier you'd be able to get to acpi_dev

> +qemu_register_powerdown_notifier(>powerdown_notifier);
>  }
>  
>  static Property acpi_ged_properties[] = {
> diff --git a/include/hw/acpi/generic_event_device.h 
> b/include/hw/acpi/generic_event_device.h
> index f69d084c89..9e63b72cb9 100644
> --- a/include/hw/acpi/generic_event_device.h
> +++ b/include/hw/acpi/generic_event_device.h
> @@ -61,6 +61,8 @@
>  
>  #include "hw/acpi/memory_hotplug.h"
>  
> +#define ACPI_POWER_BUTTON_DEVICE "PWRB"
> +
>  #define TYPE_ACPI_GED "acpi-ged"
>  #define ACPI_GED(obj) \
>  OBJECT_CHECK(AcpiGedState, (obj), TYPE_ACPI_GED)
> @@ -79,6 +81,7 @@
>   * through GED.
>   */
>  #define ACPI_GED_MEM_HOTPLUG_EVT   0x1
> +#define ACPI_GED_PWR_DOWN_EVT  0x2
>  
>  typedef struct GEDState {
>  MemoryRegion io;
> @@ -88,6 +91,7 @@ typedef struct GEDState {
>  
>  typedef struct AcpiGedState {
>  DeviceClass parent_obj;
> +Notifier powerdown_notifier;
>  MemHotplugState memhp_state;
>  hwaddr memhp_base;
>  hwaddr ged_base;

Re: [Qemu-devel] [PATCH] ppc/pnv: update skiboot to v6.4

[Cédric Le Goater]

On 18/07/2019 08:16, David Gibson wrote:
> On Thu, Jul 18, 2019 at 03:12:17PM +0930, Joel Stanley wrote:
>> Currently we fail to boot a qemu powernv machine with a Power9
>> processor:
>>
>>  PLAT: Detected generic platform
>>  PLAT: Detected BMC platform generic
>>  CPU: All 1 processors called in...
>>  CHIPTOD: Unknown TOD type !
>>  CHIPTOD: Failed ChipTOD detection !
>>  Aborting!
>>
>> With v6.4 we can boot both a Power8 and Power9 powernv machine.
>>
>> Built from submodule with powerpc64le-linux-gnu-gcc (Debian 8.3.0-2).
>>
>> Signed-off-by: Joel Stanley 
> Applied to ppc-for-4.2, thanks.
> 
> If you could add both POWER8 and POWER9 smoke tests to
> boot-serial-test that would be even better.

There is one for POWER8 and adding an extra for POWER9 results
in a test conflict. So I came up with the patch below. Would that
be OK ?


C.

@@ -104,6 +104,7 @@ static testdef_t tests[] = {
   "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken",
   "Open Firmware" },
 { "ppc64", "powernv", "-cpu POWER8", "OPAL" },
+{ "ppc64", "powernv", "-cpu POWER9", "OPAL" },
 { "ppc64", "sam460ex", "-device e1000", "8086  100e" },
 { "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
 { "i386", "pc", "-device sga", "SGABIOS" },
@@ -222,6 +223,17 @@ static void test_machine(const void *dat
 close(ser_fd);
 }
 
+static char* build_testname(testdef_t *t)
+{
+char suffix[2] = "";
+
+if (!strcmp(t->machine, "powernv")) {
+sscanf(t->extra, "-cpu POWER%1s", suffix);
+}
+
+return g_strdup_printf("boot-serial/%s%s", t->machine, suffix);
+}
+
 int main(int argc, char *argv[])
 {
 const char *arch = qtest_get_arch();
@@ -231,7 +243,7 @@ int main(int argc, char *argv[])
 
 for (i = 0; tests[i].arch != NULL; i++) {
 if (strcmp(arch, tests[i].arch) == 0) {
-char *name = g_strdup_printf("boot-serial/%s", tests[i].machine);
+char *name = build_testname([i]);
 qtest_add_data_func(name, [i], test_machine);
 g_free(name);
 }

Re: [Qemu-devel] [PATCH-for-4.2 v7 09/10] hw/arm: Use GED for system_powerdown event

[Igor Mammedov]

On Tue, 16 Jul 2019 16:38:15 +0100
Shameer Kolothum  wrote:

> Use GED for system_powerdown event instead of GPIO for ACPI.
> Guest boot with DT still uses GPIO.
 

I'd hate to keep ACPI GPIO around but taking in account migration
wouldn't this patch break ACPI GPIO based button on 4.0 and older where
GED is not available and guest was booted as ACPI one and then rebooted on new 
QEMU?


> Signed-off-by: Shameer Kolothum 
> Reviewed-by: Eric Auger 
> ---
>  hw/arm/virt-acpi-build.c | 37 +
>  hw/arm/virt.c|  6 +++---
>  2 files changed, 4 insertions(+), 39 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 75657caa36..9178ca8e40 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -49,7 +49,6 @@
>  #include "kvm_arm.h"
>  
>  #define ARM_SPI_BASE 32
> -#define ACPI_POWER_BUTTON_DEVICE "PWRB"
>  
>  static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
>  {
> @@ -328,37 +327,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
> MemMapEntry *memmap,
>  aml_append(scope, dev);
>  }
>  
> -static void acpi_dsdt_add_gpio(Aml *scope, const MemMapEntry *gpio_memmap,
> -   uint32_t gpio_irq)
> -{
> -Aml *dev = aml_device("GPO0");
> -aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
> -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> -aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> -
> -Aml *crs = aml_resource_template();
> -aml_append(crs, aml_memory32_fixed(gpio_memmap->base, gpio_memmap->size,
> -   AML_READ_WRITE));
> -aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH,
> -  AML_EXCLUSIVE, _irq, 1));
> -aml_append(dev, aml_name_decl("_CRS", crs));
> -
> -Aml *aei = aml_resource_template();
> -/* Pin 3 for power button */
> -const uint32_t pin_list[1] = {3};
> -aml_append(aei, aml_gpio_int(AML_CONSUMER, AML_EDGE, AML_ACTIVE_HIGH,
> - AML_EXCLUSIVE, AML_PULL_UP, 0, pin_list, 1,
> - "GPO0", NULL, 0));
> -aml_append(dev, aml_name_decl("_AEI", aei));
> -
> -/* _E03 is handle for power button */
> -Aml *method = aml_method("_E03", 0, AML_NOTSERIALIZED);
> -aml_append(method, aml_notify(aml_name(ACPI_POWER_BUTTON_DEVICE),
> -  aml_int(0x80)));
> -aml_append(dev, method);
> -aml_append(scope, dev);
> -}
> -
>  static void acpi_dsdt_add_power_button(Aml *scope)
>  {
>  Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
> @@ -739,9 +707,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  (irqmap[VIRT_MMIO] + ARM_SPI_BASE), 
> NUM_VIRTIO_TRANSPORTS);
>  acpi_dsdt_add_pci(scope, memmap, (irqmap[VIRT_PCIE] + ARM_SPI_BASE),
>vms->highmem, vms->highmem_ecam);
> -acpi_dsdt_add_gpio(scope, [VIRT_GPIO],
> -   (irqmap[VIRT_GPIO] + ARM_SPI_BASE));
>  if (vms->acpi_dev) {
> +acpi_dsdt_add_power_button(scope);
>  build_ged_aml(scope, "\\_SB."GED_DEVICE,
>HOTPLUG_HANDLER(vms->acpi_dev),
>irqmap[VIRT_ACPI_GED] + ARM_SPI_BASE, 
> AML_SYSTEM_MEMORY);
> @@ -752,8 +719,6 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>   AML_SYSTEM_MEMORY);
>  }
>  
> -acpi_dsdt_add_power_button(scope);
> -
>  aml_append(dsdt, scope);
>  
>  /* copy AML table into ACPI tables blob and patch header there */
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ff05ad..6e55c25c5f 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -528,7 +528,7 @@ static inline DeviceState 
> *create_acpi_ged(VirtMachineState *vms, qemu_irq *pic)
>  {
>  DeviceState *dev;
>  int irq = vms->irqmap[VIRT_ACPI_GED];
> -uint32_t event = ACPI_GED_MEM_HOTPLUG_EVT;
> +uint32_t event = ACPI_GED_MEM_HOTPLUG_EVT | ACPI_GED_PWR_DOWN_EVT;
>  
>  dev = DEVICE(object_new(TYPE_ACPI_GED));
>  qdev_prop_set_uint64(dev, "memhp-base",
> @@ -1718,10 +1718,10 @@ static void machvirt_init(MachineState *machine)
>  
>  create_pcie(vms, pic);
>  
> -create_gpio(vms, pic);
> -
>  if (!vmc->no_acpi_dev && aarch64 && firmware_loaded && acpi_enabled) {
>  vms->acpi_dev = create_acpi_ged(vms, pic);
> +} else {
> +create_gpio(vms, pic);
>  }
>  
>  /* Create mmio transports, so the user can create virtio backends

[Qemu-devel] [PATCH for-4.1] target/arm: Limit ID register assertions to TCG

[Peter Maydell]

In arm_cpu_realizefn() we make several assertions about the values of
guest ID registers:
 * if the CPU provides AArch32 v7VE or better it must advertise the
   ARM_DIV feature
 * if the CPU provides AArch32 A-profile v6 or better it must
   advertise the Jazelle feature

These are essentially consistency checks that our ID register
specifications in cpu.c didn't accidentally miss out a feature,
because increasingly the TCG emulation gates features on the values
in ID registers rather than using old-style checks of ARM_FEATURE_FOO
bits.

Unfortunately, these asserts can cause problems if we're running KVM,
because in that case we don't control the values of the ID registers
-- we read them from the host kernel.  In particular, if the host
kernel is older than 4.15 then it doesn't expose the ID registers via
the KVM_GET_ONE_REG ioctl, and we set up dummy values for some
registers and leave the rest at zero.  (See the comment in
target/arm/kvm64.c kvm_arm_get_host_cpu_features().) This set of
dummy values is not sufficient to pass our assertions, and so on
those kernels running an AArch32 guest on AArch64 will assert.

We could provide a more sophisticated set of dummy ID registers in
this case, but that still leaves the possibility of a host CPU which
reports bogus ID register values that would cause us to assert.  It's
more robust to only do these ID register checks if we're using TCG,
as that is the only case where this is truly a QEMU code bug.

Reported-by: Laszlo Ersek 
Fixes: https://bugs.launchpad.net/qemu/+bug/1830864
Signed-off-by: Peter Maydell 
---
Laszlo, would you mind testing this on your setup? I don't have
a system with an old enough kernel to trigger the assert. (The
change is pretty much a "has to work" one though :-))

 target/arm/cpu.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 1959467fdc8..9eb40ff755f 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1369,6 +1369,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  * There exist AArch64 cpus without AArch32 support.  When KVM
  * queries ID_ISAR0_EL1 on such a host, the value is UNKNOWN.
  * Similarly, we cannot check ID_AA64PFR0 without AArch64 support.
+ * As a general principle, we also do not make ID register
+ * consistency checks anywhere unless using TCG, because only
+ * for TCG would a consistency-check failure be a QEMU bug.
  */
 if (arm_feature(>env, ARM_FEATURE_AARCH64)) {
 no_aa32 = !cpu_isar_feature(aa64_aa32, cpu);
@@ -1383,7 +1386,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
  * Security Extensions is ARM_FEATURE_EL3.
  */
-assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
+assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(arm_div, cpu));
 set_feature(env, ARM_FEATURE_LPAE);
 set_feature(env, ARM_FEATURE_V7);
 }
@@ -1409,7 +1412,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 if (arm_feature(env, ARM_FEATURE_V6)) {
 set_feature(env, ARM_FEATURE_V5);
 if (!arm_feature(env, ARM_FEATURE_M)) {
-assert(no_aa32 || cpu_isar_feature(jazelle, cpu));
+assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(jazelle, 
cpu));
 set_feature(env, ARM_FEATURE_AUXCR);
 }
 }
-- 
2.20.1

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Paolo Bonzini]

On 18/07/19 14:04, Marc-André Lureau wrote:
> Our module system does not support Windows, because it relies on
> resolving symbols from the main executable.
> 
> If there is enough interest in supporting modules on Windows, we could
> generate an import library for the executable and link with it:
> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
> 
> However, there is a small chicken egg problem, since the executable
> link and exports extra symbols needed by the library...

Yeah, with Meson it would be possible to do this easily, but for now
let's just drop support for modules on Windows.

Paolo

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Daniel P . Berrangé]

On Thu, Jul 18, 2019 at 04:04:13PM +0400, Marc-André Lureau wrote:
> Our module system does not support Windows, because it relies on
> resolving symbols from the main executable.
> 
> If there is enough interest in supporting modules on Windows, we could
> generate an import library for the executable and link with it:
> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
> 
> However, there is a small chicken egg problem, since the executable
> link and exports extra symbols needed by the library...

The "solution" to that would presumably be to put everything into a
library, and the executable merely becomes trivial main() that calls
a "runme" function in the library. It is kind of ugly though as we
would need a separate library for each system emulator executable.

Just ignoring modules on Windows looks like the prudent solution.

> 
> Signed-off-by: Marc-André Lureau 
> ---
>  configure | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[Qemu-devel] [PATCH] Allow bit 15 to be set to 1 on slbmfee and slbmfev

[Ivan Warren via Qemu-devel]

Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
Per this specification, bit 15 is implementation specific
so it may be 1, but can probably ne safely ignored.

Power ISA 2.07B (Power 7/Power 8) indicates the bit is
reserved but some none Linux operating systems do set
this bit to 1 when entering the debugger.
So it is likely it is implemented on those systems
but wasn't yet documented.

Signed-off-by: Ivan Warren 
---

The original creator of the patch is "Zhuowei Zhang" 
(https://twitter.com/zhuowei) but I couldn't find any e-mail address.


 target/ppc/translate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 4a5de28036..85f8b147ba 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -7064,8 +7064,8 @@ GEN_HANDLER2(mtsr_64b, "mtsr", 0x1F, 0x12, 0x06, 
0x0010F801, PPC_SEGMENT_64B),

 GEN_HANDLER2(mtsrin_64b, "mtsrin", 0x1F, 0x12, 0x07, 0x001F0001,
  PPC_SEGMENT_64B),
 GEN_HANDLER2(slbmte, "slbmte", 0x1F, 0x12, 0x0C, 0x001F0001, 
PPC_SEGMENT_64B),
-GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001F0001, 
PPC_SEGMENT_64B),
-GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001F0001, 
PPC_SEGMENT_64B),
+GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001E0001, 
PPC_SEGMENT_64B),
+GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001E0001, 
PPC_SEGMENT_64B),
 GEN_HANDLER2(slbfee_, "slbfee.", 0x1F, 0x13, 0x1E, 0x001F, 
PPC_SEGMENT_64B),

 #endif
 GEN_HANDLER(tlbia, 0x1F, 0x12, 0x0B, 0x03FFFC01, PPC_MEM_TLBIA),
--
2.20.1




smime.p7s
Description: Signature cryptographique S/MIME

Re: [Qemu-devel] [PATCH-for-4.2 v7 06/10] hw/arm/virt: Enable device memory cold/hot plug with ACPI boot

[Igor Mammedov]

On Tue, 16 Jul 2019 16:38:12 +0100
Shameer Kolothum  wrote:

> This initializes the GED device with base memory and irq, configures
> ged memory hotplug event and builds the corresponding aml code. With
> this, both hot and cold plug of device memory is enabled now for Guest
> with ACPI boot.
> 
> Memory cold plug support with Guest DT boot is not yet supported.
> 
> Signed-off-by: Shameer Kolothum 
> Reviewed-by: Eric Auger 
> ---
> v6 --> v7
>   Disabled ACPI GED dev creation for machine < 4.2.
> 
> ---
>  hw/arm/Kconfig   |  2 ++
>  hw/arm/virt-acpi-build.c | 14 +++
>  hw/arm/virt.c| 51 ++--
>  include/hw/arm/virt.h|  4 
>  4 files changed, 64 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 84961c17ab..ad7f7c089b 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -22,6 +22,8 @@ config ARM_VIRT
>  select ACPI_PCI
>  select MEM_DEVICE
>  select DIMM
> +select ACPI_MEMORY_HOTPLUG
> +select ACPI_HW_REDUCED
>  
>  config CHEETAH
>  bool
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 0afb372769..018b1e326d 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -40,6 +40,8 @@
>  #include "hw/acpi/aml-build.h"
>  #include "hw/acpi/utils.h"
>  #include "hw/acpi/pci.h"
> +#include "hw/acpi/memory_hotplug.h"
> +#include "hw/acpi/generic_event_device.h"
>  #include "hw/pci/pcie_host.h"
>  #include "hw/pci/pci.h"
>  #include "hw/arm/virt.h"
> @@ -705,6 +707,7 @@ static void
>  build_dsdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>  {
>  Aml *scope, *dsdt;
> +MachineState *ms = MACHINE(vms);
>  const MemMapEntry *memmap = vms->memmap;
>  const int *irqmap = vms->irqmap;
>  
> @@ -729,6 +732,17 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>vms->highmem, vms->highmem_ecam);
>  acpi_dsdt_add_gpio(scope, [VIRT_GPIO],
> (irqmap[VIRT_GPIO] + ARM_SPI_BASE));
> +if (vms->acpi_dev) {
> +build_ged_aml(scope, "\\_SB."GED_DEVICE,
> +  HOTPLUG_HANDLER(vms->acpi_dev),
> +  irqmap[VIRT_ACPI_GED] + ARM_SPI_BASE, 
> AML_SYSTEM_MEMORY);
> +}
> +
> +if (vms->acpi_dev && ms->ram_slots) {
> +build_memory_hotplug_aml(scope, ms->ram_slots, "\\_SB", NULL,
> + AML_SYSTEM_MEMORY);
> +}
> +
>  acpi_dsdt_add_power_button(scope);
>  
>  aml_append(dsdt, scope);
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index bbe156dc35..ff05ad 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -66,6 +66,7 @@
>  #include "target/arm/internals.h"
>  #include "hw/mem/pc-dimm.h"
>  #include "hw/mem/nvdimm.h"
> +#include "hw/acpi/generic_event_device.h"
>  
>  #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
>  static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
> @@ -136,6 +137,8 @@ static const MemMapEntry base_memmap[] = {
>  [VIRT_GPIO] =   { 0x0903, 0x1000 },
>  [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
>  [VIRT_SMMU] =   { 0x0905, 0x0002 },
> +[VIRT_PCDIMM_ACPI] ={ 0x0907, MEMORY_HOTPLUG_IO_LEN },
> +[VIRT_ACPI_GED] =   { 0x0908, ACPI_GED_REG_LEN },
>  [VIRT_MMIO] =   { 0x0a00, 0x0200 },
>  /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size 
> */
>  [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
> @@ -171,6 +174,7 @@ static const int a15irqmap[] = {
>  [VIRT_PCIE] = 3, /* ... to 6 */
>  [VIRT_GPIO] = 7,
>  [VIRT_SECURE_UART] = 8,
> +[VIRT_ACPI_GED] = 9,
>  [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */
>  [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */
>  [VIRT_SMMU] = 74,/* ...to 74 + NUM_SMMU_IRQS - 1 */
> @@ -520,6 +524,25 @@ static void fdt_add_pmu_nodes(const VirtMachineState 
> *vms)
>  }
>  }
>  
> +static inline DeviceState *create_acpi_ged(VirtMachineState *vms, qemu_irq 
> *pic)
> +{
> +DeviceState *dev;
> +int irq = vms->irqmap[VIRT_ACPI_GED];
> +uint32_t event = ACPI_GED_MEM_HOTPLUG_EVT;
> +
> +dev = DEVICE(object_new(TYPE_ACPI_GED));
> +qdev_prop_set_uint64(dev, "memhp-base",
> + vms->memmap[VIRT_PCDIMM_ACPI].base);
> +qdev_prop_set_uint64(dev, "ged-base", vms->memmap[VIRT_ACPI_GED].base);
> +qdev_prop_set_uint32(dev, "ged-event", event);
> +object_property_add_child(qdev_get_machine(), "acpi-ged",
> +  OBJECT(dev), NULL);
> +qdev_init_nofail(dev);
> +qdev_connect_gpio_out_named(dev, "ged-irq", 0, pic[irq]);

leaking 'dev' reference created by object_new(), you need to unref it here.

> +
> +return dev;
> +}
> +
>  static void create_its(VirtMachineState *vms, DeviceState 

Re: [Qemu-devel] [PATCH-for-4.2 v7 03/10] hw/acpi: Add ACPI Generic Event Device Support

[Igor Mammedov]

On Thu, 18 Jul 2019 10:52:10 +
Shameerali Kolothum Thodi  wrote:

> Hi Igor,
> 
> > -Original Message-
> > From: Qemu-devel
> > [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nongn
> > u.org] On Behalf Of Igor Mammedov
> > Sent: 17 July 2019 15:33
> > To: Shameerali Kolothum Thodi 
> > Cc: peter.mayd...@linaro.org; sa...@linux.intel.com;
> > shannon.zha...@gmail.com; ard.biesheu...@linaro.org;
> > qemu-devel@nongnu.org; xuwei (O) ; Linuxarm
> > ; eric.au...@redhat.com; qemu-...@nongnu.org;
> > sebastien.bo...@intel.com; ler...@redhat.com
> > Subject: Re: [Qemu-devel] [PATCH-for-4.2 v7 03/10] hw/acpi: Add ACPI Generic
> > Event Device Support
> > 
> > On Tue, 16 Jul 2019 16:38:09 +0100
> > Shameer Kolothum  wrote:  
> 
> [...]
> 
> > > +static void acpi_ged_event(AcpiGedState *s, uint32_t sel)
> > > +{
> > > +GEDState *ged_st = >ged_state;
> > > +/*
> > > + * Set the GED IRQ selector to the expected device type value. This
> > > + * way, the ACPI method will be able to trigger the right code based
> > > + * on a unique IRQ.  
> > comment isn't correct anymore, pls fix it  
> 
> True.
> 
> >   
> > > + */
> > > +qemu_mutex_lock(_st->lock);  
> > Is this lock really necessary?
> > (I thought that MMIO and monitor access is guarded by BQL)  
> 
> Hmm..I am not sure. This is to synchronize with the ged_st->sel update inside
> ged_read(). And also acpi_ged_event() gets called through 
> _power_down_notifier()
> as well. BQL guard is in place for all the paths here? 
power down command originates from HMP or QMP monitor, so you don't really
need a lock here.

> 
> >   
> > > +ged_st->sel |= sel;
> > > +qemu_mutex_unlock(_st->lock);
> > > +
> > > +/* Trigger the event by sending an interrupt to the guest. */
> > > +qemu_irq_pulse(s->irq);
> > > +}
> > > +
> > > +static void acpi_ged_init(MemoryRegion *as, DeviceState *dev, GEDState  
> > *ged_st)  
> > > +{
> > > +AcpiGedState *s = ACPI_GED(dev);
> > > +
> > > +assert(s->ged_base);
> > > +
> > > +qemu_mutex_init(_st->lock);
> > > +memory_region_init_io(_st->io, OBJECT(dev), _ops, ged_st,
> > > +  TYPE_ACPI_GED, ACPI_GED_REG_LEN);
> > > +memory_region_add_subregion(as, s->ged_base, _st->io);
> > > +qdev_init_gpio_out_named(DEVICE(s), >irq, "ged-irq", 1);
> > > +}
> > > +
> > > +static void acpi_ged_device_plug_cb(HotplugHandler *hotplug_dev,
> > > +DeviceState *dev, Error **errp)
> > > +{
> > > +AcpiGedState *s = ACPI_GED(hotplug_dev);
> > > +
> > > +if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> > > +if (s->memhp_state.is_enabled) {
> > > +acpi_memory_plug_cb(hotplug_dev, >memhp_state, dev,  
> > errp);  
> > > +} else {
> > > +error_setg(errp,
> > > + "memory hotplug is not  
> > enabled: %s.memory-hotplug-support "  
> > > + "is not set", object_get_typename(OBJECT(s)));
> > > +}
> > > +} else {
> > > +error_setg(errp, "virt: device plug request for unsupported  
> > device"  
> > > +   " type: %s", object_get_typename(OBJECT(dev)));
> > > +}
> > > +}
> > > +
> > > +static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits  
> > ev)  
> > > +{
> > > +AcpiGedState *s = ACPI_GED(adev);
> > > +uint32_t sel;
> > > +
> > > +if (ev & ACPI_MEMORY_HOTPLUG_STATUS) {
> > > +sel = ACPI_GED_MEM_HOTPLUG_EVT;
> > > +} else {
> > > +/* Unknown event. Return without generating interrupt. */
> > > +warn_report("GED: Unsupported event %d. No irq injected", ev);
> > > +return;
> > > +}
> > > +
> > > +/*
> > > + * We inject the hotplug interrupt. The IRQ selector will make
> > > + * the difference from the ACPI table.  
> > I don't get comment at all, pls rephrase/  
> 
> Ok. I think better to get rid of this comment here and update the one in 
> acpi_ged_event()
> appropriately.
> 
> >   
> > > + */
> > > +acpi_ged_event(s, sel);  
> > it seems to used only once and only here, suggest to drop acpi_ged_event()
> > and move it's code here.  
> 
> But patch #10 makes use of it from acpi_ged_pm_powerdown_req().
it looks like a valid shortcut but I'd make it follow 
AcpiInterface->send_event()
path for consistency so only one call chain would exist.


> 
> > > +}
> > > +
> > > +static void acpi_ged_device_realize(DeviceState *dev, Error **errp)
> > > +{
> > > +AcpiGedState *s = ACPI_GED(dev);
> > > +
> > > +if (s->memhp_state.is_enabled) {
> > > +acpi_memory_hotplug_init(get_system_memory(), OBJECT(dev),
> > > + >memhp_state,
> > > + s->memhp_base);
> > > +}
> > > +
> > > +acpi_ged_init(get_system_memory(), dev, >ged_state);
> > > +}
> > > +
> > > +static Property acpi_ged_properties[] = {
> > > +/*
> > > + * Memory hotplug 

Re: [Qemu-devel] [PULL 08/10] target/arm: Conditionalize some asserts on aarch32 support

[Peter Maydell]

On Wed, 17 Jul 2019 at 16:08, Laszlo Ersek  wrote:
>
> On 07/17/19 15:46, Peter Maydell wrote:
> > On Wed, 17 Jul 2019 at 14:36, Philippe Mathieu-Daudé  
> > wrote:
> >> I still wonder why this didn't assert on Peter's setup.
> >
> > My setup does not assert because my host kernel correctly
> > provides the ID register values to QEMU. Laszlo's appears
> > to be providing all-zeroes, which then obviously breaks
> > assertions being made about the sanity of those ID register
> > values...
>
> OK. Can you suggest a location that I should check in the host kernel?

I was about to write out the process of how we get these values
from the kernel, but as the first step of that I read through
QEMU's target/arm/kvm64.c:kvm_arm_get_host_cpu_features(),
which is the function which reads these values using the
KVM_GET_ONE_REG ioctl. It starts with an attempt to read
ID_AA64PFR0, and has a comment for the error-handling case:

/*
 * Before v4.15, the kernel only exposed a limited number of system
 * registers, not including any of the interesting AArch64 ID regs.
 * For the most part we could leave these fields as zero with minimal
 * effect, since this does not affect the values seen by the guest.
 *
 * However, it could cause problems down the line for QEMU,
 * so provide a minimal v8.0 default.
 *
 * ??? Could read MIDR and use knowledge from cpu64.c.
 * ??? Could map a page of memory into our temp guest and
 * run the tiniest of hand-crafted kernels to extract
 * the values seen by the guest.
 * ??? Either of these sounds like too much effort just
 * to work around running a modern host kernel.
 */

I have 4.15, and don't hit this assert; you have 4.14 and do,
so I think you're going to be going through this codepath which
currently sets only ahcf->isar.id_aa64pfr0 and none of the other
ID register fields in the isar struct.

I'm not sure exactly which kernel commits added the ID register
reading support. (The relevant kernel code is in
arch/arm64/kvm/sys_regs.c I think.)

Anyway, I think we need to do at least one of:
 * enhance the "provide a minimal v8.0 default" code in this
   condition in kvm_arm_get_host_cpu_features() so that it
   populates the ID registers sufficiently to avoid asserts
   and other bad things
 * make the asserts on ID register oddnesses be only for TCG
   (ie where QEMU controls the values) and not for KVM

thanks
-- PMM

[Qemu-devel] [PATCH v2 17/17] ppc/pnv: quiesce some XIVE errors

[Cédric Le Goater]

When dumping the END and NVT tables, the error logging is too noisy.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/pnv_xive.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index c1501a6b5bce..e7acab0dff51 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -27,7 +27,7 @@
 
 #include "pnv_xive_regs.h"
 
-#define XIVE_DEBUG
+#undef XIVE_DEBUG
 
 /*
  * Virtual structures table (VST)
@@ -172,7 +172,9 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive, 
uint32_t type,
 vsd = ldq_be_dma(_space_memory, vsd_addr);
 
 if (!(vsd & VSD_ADDRESS_MASK)) {
+#ifdef XIVE_DEBUG
 xive_error(xive, "VST: invalid %s entry %x !?", info->name, idx);
+#endif
 return 0;
 }
 
@@ -193,7 +195,9 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive, 
uint32_t type,
 vsd = ldq_be_dma(_space_memory, vsd_addr);
 
 if (!(vsd & VSD_ADDRESS_MASK)) {
+#ifdef XIVE_DEBUG
 xive_error(xive, "VST: invalid %s entry %x !?", info->name, idx);
+#endif
 return 0;
 }
 
-- 
2.21.0

[Qemu-devel] [PATCH v2 13/17] ppc/pnv: Dump the XIVE NVT table

[Cédric Le Goater]

This is to track the configuration of the base END index of the vCPU
and the Interrupt Pending Buffer. The NVT IPB is updated when an
interrupt can not be presented to a vCPU.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive_regs.h |  2 ++
 hw/intc/pnv_xive.c | 22 ++
 2 files changed, 24 insertions(+)

diff --git a/include/hw/ppc/xive_regs.h b/include/hw/ppc/xive_regs.h
index 92ff80d25456..b228ab0ba3ea 100644
--- a/include/hw/ppc/xive_regs.h
+++ b/include/hw/ppc/xive_regs.h
@@ -229,6 +229,8 @@ typedef struct XiveNVT {
 uint32_tw0;
 #define NVT_W0_VALID PPC_BIT32(0)
 uint32_tw1;
+#define NVT_W1_EQ_BLOCK  PPC_BITMASK32(0, 3)
+#define NVT_W1_EQ_INDEX  PPC_BITMASK32(4, 31)
 uint32_tw2;
 uint32_tw3;
 uint32_tw4;
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index 63243253b736..a086598c5e77 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -1540,6 +1540,21 @@ static const MemoryRegionOps pnv_xive_pc_ops = {
 },
 };
 
+static void xive_nvt_pic_print_info(XiveNVT *nvt, uint32_t nvt_idx,
+Monitor *mon)
+{
+uint8_t  eq_blk = xive_get_field32(NVT_W1_EQ_BLOCK, nvt->w1);
+uint32_t eq_idx = xive_get_field32(NVT_W1_EQ_INDEX, nvt->w1);
+
+if (!xive_nvt_is_valid(nvt)) {
+return;
+}
+
+monitor_printf(mon, "  %08x end:%02x/%04x IPB:%02x\n", nvt_idx,
+   eq_blk, eq_idx,
+   xive_get_field32(NVT_W4_IPB, nvt->w4));
+}
+
 void pnv_xive_pic_print_info(PnvXive *xive, Monitor *mon)
 {
 XiveRouter *xrtr = XIVE_ROUTER(xive);
@@ -1548,6 +1563,7 @@ void pnv_xive_pic_print_info(PnvXive *xive, Monitor *mon)
 uint32_t nr_ipis = pnv_xive_nr_ipis(xive, blk);
 XiveEAS eas;
 XiveEND end;
+XiveNVT nvt;
 int i;
 
 monitor_printf(mon, "XIVE[%x] Source %08x .. %08x\n", blk, srcno0,
@@ -1576,6 +1592,12 @@ void pnv_xive_pic_print_info(PnvXive *xive, Monitor *mon)
 while (!xive_router_get_end(xrtr, blk, i, )) {
 xive_end_eas_pic_print_info(, i++, mon);
 }
+
+monitor_printf(mon, "XIVE[%x] NVTT\n", blk);
+i = 0;
+while (!xive_router_get_nvt(xrtr, blk, i, )) {
+xive_nvt_pic_print_info(, i++, mon);
+}
 }
 
 static void pnv_xive_reset(void *dev)
-- 
2.21.0

Re: [Qemu-devel] No archives to download from www.qemu.org/download/

[Aleksandar Markovic]

On Thu, Jul 18, 2019 at 1:43 PM Daniel P. Berrangé 
wrote:

> On Thu, Jul 18, 2019 at 01:29:02PM +0200, Thomas Huth wrote:
> > On 18/07/2019 12.55, Aleksandar Markovic wrote:
> > > On Thu, Jul 18, 2019 at 10:58 AM Philippe Mathieu-Daudé <
> phi...@redhat.com>
> > > wrote:
> > >>
> > >> On 7/18/19 9:10 AM, Thomas Huth wrote:
> > >>> On 18/07/2019 08.25, Philippe Mathieu-Daudé wrote:
> > >
> >  ...
> > >
> >  Now there are no archive to download at this url...
> > >>>
> > >>> You just have to click on the "Source code" tab ... is that too hard?
> > >>
> > >> Argh it has been a rough night, now I feel ashamed. I scrolled but
> > >> missed that tab. Really sorry for crying wolf here :/
> > >>
> > >
> > > Download QEMU page 
> > >
> > > In all fairness to Philippe, this page could be better in terms of
> > > human-computer interaction... If one presses 'Download', one
> > > expects to get to the download links directly or obviously easily.
> >
> > I guess we should simply re-arrange the order of the tabs ... the
> > OS-agnostic source code tab should come first (since this is about what
> > we provide for download on our site), and then the others with
> > references to the distros etc.
>
> I'm not sure it is clear cut. I think its reasonable to say that users
> coming to QEMU are best served by using distro provided packages. Only
> those wishing to actually hack on QEMU, or who need newer than the
> distro provides, should prefer the source. Building from source has many
> more potential hurdles / failure points than installing distro packages,
> which can leave users with a worse first experience of QEMU.
>
>
Yes, Daniel, but here we blend two visitor activities onto a single page:
download source (and build), and install QEMU (from prebuilt binaries).
Now wonder a confusion arises.

Yours,
Aleksandar



> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
>

[Qemu-devel] [PATCH v2 05/17] ppc/xive: Provide escalation support

[Cédric Le Goater]

If the XIVE presenter can not find the NVT dispatched on any of the HW
threads, it can not deliver the interrupt. XIVE offers an escalation
mechanism to handle such scenarios and inform the hypervisor that an
action should be taken.

Escalation is configured by setting the 'e' bit and the EAS in word 4
& 5 to let the HW look for the escalation END on which to trigger a
new event.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xive.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 1ee5c1fe4534..89a09dde060b 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -1527,6 +1527,22 @@ static void xive_router_end_notify(XiveRouter *xrtr, 
uint8_t end_blk,
  * On HW, follows a "Broadcast Backlog" to IVPEs
  */
 }
+
+/*
+ * If activated, escalate notification using the ESe PQ bits and
+ * the EAS in w4-5
+ */
+if (!xive_end_is_escalate()) {
+return;
+}
+
+/*
+ * The END trigger becomes an Escalation trigger
+ */
+xive_router_end_notify(xrtr,
+   xive_get_field32(END_W4_ESC_END_BLOCK, end.w4),
+   xive_get_field32(END_W4_ESC_END_INDEX, end.w4),
+   xive_get_field32(END_W5_ESC_END_DATA,  end.w5));
 }
 
 void xive_router_notify(XiveNotifier *xn, uint32_t lisn)
-- 
2.21.0

[Qemu-devel] [PATCH v2 10/17] ppc/xive: Introduce xive_tctx_ipb_update()

[Cédric Le Goater]

We will use it to resend missed interrupts when a vCPU context is
pushed a HW thread.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h |  1 +
 hw/intc/xive.c| 15 +++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 206b23ecfab3..51e3c37b7483 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -418,6 +418,7 @@ uint64_t xive_tctx_tm_read(XiveTCTX *tctx, hwaddr offset, 
unsigned size);
 
 void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
 Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
+void xive_tctx_ipb_update(XiveTCTX *tctx, uint8_t ring, uint8_t ipb);
 
 static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, uint32_t nvt_idx)
 {
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 1b0eccb6df40..be66b1fb3261 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -132,6 +132,15 @@ static void xive_tctx_set_cppr(XiveTCTX *tctx, uint8_t 
ring, uint8_t cppr)
 xive_tctx_notify(tctx, ring);
 }
 
+void xive_tctx_ipb_update(XiveTCTX *tctx, uint8_t ring, uint8_t ipb)
+{
+uint8_t *regs = >regs[ring];
+
+regs[TM_IPB] |= ipb;
+regs[TM_PIPR] = ipb_to_pipr(regs[TM_IPB]);
+xive_tctx_notify(tctx, ring);
+}
+
 static inline uint32_t xive_tctx_word2(uint8_t *ring)
 {
 return *((uint32_t *) [TM_WORD2]);
@@ -330,8 +339,7 @@ static void xive_tm_set_os_cppr(XiveTCTX *tctx, hwaddr 
offset,
 static void xive_tm_set_os_pending(XiveTCTX *tctx, hwaddr offset,
uint64_t value, unsigned size)
 {
-ipb_update(>regs[TM_QW1_OS], value & 0xff);
-xive_tctx_notify(tctx, TM_QW1_OS);
+xive_tctx_ipb_update(tctx, TM_QW1_OS, priority_to_ipb(value & 0xff));
 }
 
 static uint64_t xive_tm_pull_os_ctx(XiveTCTX *tctx, hwaddr offset,
@@ -1445,8 +1453,7 @@ static bool xive_presenter_notify(XiveRouter *xrtr, 
uint8_t format,
 found = xive_presenter_match(xrtr, format, nvt_blk, nvt_idx, cam_ignore,
  priority, logic_serv, );
 if (found) {
-ipb_update(>regs[match.ring], priority);
-xive_tctx_notify(match.tctx, match.ring);
+xive_tctx_ipb_update(match.tctx, match.ring, 
priority_to_ipb(priority));
 }
 
 return found;
-- 
2.21.0

Re: [Qemu-devel] [PATCH] curses: assert get_wch return value is okay

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1563451264-46176-1-git-send-email-pbonz...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Subject: [Qemu-devel] [PATCH] curses: assert get_wch return value is okay
Message-id: 1563451264-46176-1-git-send-email-pbonz...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1563451264-46176-1-git-send-email-pbonz...@redhat.com -> 
patchew/1563451264-46176-1-git-send-email-pbonz...@redhat.com
Submodule 'capstone' (https://git.qemu.org/git/capstone.git) registered for 
path 'capstone'
Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
Submodule 'roms/QemuMacDrivers' (https://git.qemu.org/git/QemuMacDrivers.git) 
registered for path 'roms/QemuMacDrivers'
Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
Submodule 'roms/edk2' (https://git.qemu.org/git/edk2.git) registered for path 
'roms/edk2'
Submodule 'roms/ipxe' (https://git.qemu.org/git/ipxe.git) registered for path 
'roms/ipxe'
Submodule 'roms/openbios' (https://git.qemu.org/git/openbios.git) registered 
for path 'roms/openbios'
Submodule 'roms/openhackware' (https://git.qemu.org/git/openhackware.git) 
registered for path 'roms/openhackware'
Submodule 'roms/qemu-palcode' (https://git.qemu.org/git/qemu-palcode.git) 
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (https://git.qemu.org/git/seabios.git/) registered for 
path 'roms/seabios'
Submodule 'roms/seabios-hppa' (https://git.qemu.org/git/seabios-hppa.git) 
registered for path 'roms/seabios-hppa'
Submodule 'roms/sgabios' (https://git.qemu.org/git/sgabios.git) registered for 
path 'roms/sgabios'
Submodule 'roms/skiboot' (https://git.qemu.org/git/skiboot.git) registered for 
path 'roms/skiboot'
Submodule 'roms/u-boot' (https://git.qemu.org/git/u-boot.git) registered for 
path 'roms/u-boot'
Submodule 'roms/u-boot-sam460ex' (https://git.qemu.org/git/u-boot-sam460ex.git) 
registered for path 'roms/u-boot-sam460ex'
Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 
'slirp'
Submodule 'tests/fp/berkeley-softfloat-3' 
(https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 
'tests/fp/berkeley-softfloat-3'
Submodule 'tests/fp/berkeley-testfloat-3' 
(https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 
'tests/fp/berkeley-testfloat-3'
Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) 
registered for path 'ui/keycodemapdb'
Cloning into 'capstone'...
Submodule path 'capstone': checked out 
'22ead3e0bfdb87516656453336160e0a37b066bf'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Cloning into 'roms/QemuMacDrivers'...
Submodule path 'roms/QemuMacDrivers': checked out 
'90c488d5f4a407342247b9ea869df1c2d9c8e266'
Cloning into 'roms/SLOF'...
Submodule path 'roms/SLOF': checked out 
'ba1ab360eebe6338bb8d7d83a9220ccf7e213af3'
Cloning into 'roms/edk2'...
Submodule path 'roms/edk2': checked out 
'20d2e5a125e34fc8501026613a71549b2a1a3e54'
Submodule 'SoftFloat' (https://github.com/ucb-bar/berkeley-softfloat-3.git) 
registered for path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'
Submodule 'CryptoPkg/Library/OpensslLib/openssl' 
(https://github.com/openssl/openssl) registered for path 
'CryptoPkg/Library/OpensslLib/openssl'
Cloning into 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'...
Submodule path 'roms/edk2/ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3': 
checked out 'b64af41c3276f97f0e181920400ee056b9c88037'
Cloning into 'CryptoPkg/Library/OpensslLib/openssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl': checked out 
'50eaac9f3337667259de725451f201e784599687'
Submodule 'boringssl' (https://boringssl.googlesource.com/boringssl) registered 
for path 'boringssl'
Submodule 'krb5' (https://github.com/krb5/krb5) registered for path 'krb5'
Submodule 'pyca.cryptography' (https://github.com/pyca/cryptography.git) 
registered for path 'pyca-cryptography'
Cloning into 'boringssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/boringssl': 
checked out '2070f8ad9151dc8f3a73bffaa146b5e6937a583f'
Cloning into 'krb5'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5': checked 
out 'b9ad6c49505c96a088326b62a52568e3484f2168'
Cloning into 'pyca-cryptography'...
Submodule path 
'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/pyca-cryptography': checked out 
'09403100de2f6f1cdd0d484dcb8e620f1c335c8f'
Cloning into 'roms/ipxe'...
Submodule path 'roms/ipxe': checked out 

Re: [Qemu-devel] [Qemu-block] [PATCH-for-4.1] hw/ide/piix: Mark the PIIX IDE interfaces as not user_creatable

[Kevin Wolf]

Am 18.07.2019 um 11:26 hat Paolo Bonzini geschrieben:
> On 18/07/19 11:17, Philippe Mathieu-Daudé wrote:
> > The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
> > PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
> > TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be created
> > in part, it has to be created and used as a whole.
> > 
> > Similarly with the 'piix4-ide' device and the PIIX4 chipset
> > modelled as TYPE_PIIX4_PCI_DEVICE.
> > 
> > Disable the 'user_creatable' flag.
> > 
> > part of TYPE_PIIX3_PCI_DEVICE (TYPE_PIIX3_XEN_DEVICE)
> > 
> > Signed-off-by: Philippe Mathieu-Daudé 
> 
> This works though:
> 
>   qemu-system-x86_64 \
> -M q35,sata=off -device piix3-ide,addr=1f.2 \
> -drive if=none,file=freedos.raw,id=hd -device ide-hd,drive=hd
> 
> And it is a nice hack to mimic Q35's legacy IDE mode...

And I've seen it often enough that I'm sure users are using it.

If we want to remove it at all, we'd have to go through the usual
deprecation period. But as long as we don't have another option for
getting a legacy IDE controller on Q35, I don't think we should remove
this.

Kevin

[Qemu-devel] [PATCH v2 16/17] ppc/pnv: Introduce a pnv_xive_get_block_id() interface to XiveRouter

[Cédric Le Goater]

When PC_TCTXT_CHIPID_OVERRIDE is configured, the PC_TCTXT_CHIPID field
overrides the hardwired chip ID in the Powerbus operations and for CAM
compares. This is typically used in one block-per-chip configurations
to associate a unique block id number to each IC of the system.

The model does support multiple blocks per chip.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/pnv_xive.h |  3 --
 include/hw/ppc/xive.h |  2 ++
 hw/intc/pnv_xive.c| 66 +--
 hw/intc/spapr_xive.c  |  6 
 hw/intc/xive.c| 10 +-
 5 files changed, 53 insertions(+), 34 deletions(-)

diff --git a/include/hw/ppc/pnv_xive.h b/include/hw/ppc/pnv_xive.h
index 4fdaa9247d65..f4c7caad40ee 100644
--- a/include/hw/ppc/pnv_xive.h
+++ b/include/hw/ppc/pnv_xive.h
@@ -72,9 +72,6 @@ typedef struct PnvXive {
 /* Interrupt controller registers */
 uint64_t  regs[0x300];
 
-/* Can be configured by FW */
-uint32_t  tctx_chipid;
-
 /*
  * Virtual Structure Descriptor tables : EAT, SBE, ENDT, NVTT, IRQ
  * These are in a SRAM protected by ECC.
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 251a8f2de10e..8828dd1eb06c 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -355,6 +355,7 @@ typedef struct XiveRouterClass {
 int (*write_nvt)(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
  XiveNVT *nvt, uint8_t word_number);
 XiveTCTX *(*get_tctx)(XiveRouter *xrtr, CPUState *cs);
+uint8_t (*get_block_id)(XiveRouter *xrtr);
 } XiveRouterClass;
 
 int xive_router_get_eas(XiveRouter *xrtr, uint8_t eas_blk, uint32_t eas_idx,
@@ -368,6 +369,7 @@ int xive_router_get_nvt(XiveRouter *xrtr, uint8_t nvt_blk, 
uint32_t nvt_idx,
 int xive_router_write_nvt(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
   XiveNVT *nvt, uint8_t word_number);
 XiveTCTX *xive_router_get_tctx(XiveRouter *xrtr, CPUState *cs);
+uint8_t xive_router_get_block_id(XiveRouter *xrtr);
 void xive_router_notify(XiveNotifier *xn, uint32_t lisn);
 
 /*
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index 403e8c8ca5b4..c1501a6b5bce 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -83,6 +83,23 @@ static inline uint64_t SETFIELD(uint64_t mask, uint64_t word,
 return (word & ~mask) | ((value << ctz64(mask)) & mask);
 }
 
+/*
+ * When PC_TCTXT_CHIPID_OVERRIDE is configured, the PC_TCTXT_CHIPID
+ * field overrides the hardwired chip ID in the Powerbus operations
+ * and for CAM compares
+ */
+static uint8_t pnv_xive_block_id(PnvXive *xive)
+{
+uint8_t blk = xive->chip->chip_id;
+uint64_t cfg_val = xive->regs[PC_TCTXT_CFG >> 3];
+
+if (cfg_val & PC_TCTXT_CHIPID_OVERRIDE) {
+blk = GETFIELD(PC_TCTXT_CHIPID, cfg_val);
+}
+
+return blk;
+}
+
 /*
  * Remote access to controllers. HW uses MMIOs. For now, a simple scan
  * of the chips is good enough.
@@ -98,7 +115,7 @@ static PnvXive *pnv_xive_get_ic(uint8_t blk)
 Pnv9Chip *chip9 = PNV9_CHIP(pnv->chips[i]);
 PnvXive *xive = >xive;
 
-if (xive->chip->chip_id == blk) {
+if (pnv_xive_block_id(xive) == blk) {
 return xive;
 }
 }
@@ -384,6 +401,11 @@ static XiveTCTX *pnv_xive_get_tctx(XiveRouter *xrtr, 
CPUState *cs)
 return tctx;
 }
 
+static uint8_t pnv_xive_get_block_id(XiveRouter *xrtr)
+{
+return pnv_xive_block_id(PNV_XIVE(xrtr));
+}
+
 /*
  * The internal sources (IPIs) of the interrupt controller have no
  * knowledge of the XIVE chip on which they reside. Encode the block
@@ -394,7 +416,7 @@ static XiveTCTX *pnv_xive_get_tctx(XiveRouter *xrtr, 
CPUState *cs)
 static void pnv_xive_notify(XiveNotifier *xn, uint32_t srcno)
 {
 PnvXive *xive = PNV_XIVE(xn);
-uint8_t blk = xive->chip->chip_id;
+uint8_t blk = pnv_xive_block_id(xive);
 
 xive_router_notify(xn, XIVE_SRCNO(blk, srcno));
 }
@@ -758,21 +780,9 @@ static void pnv_xive_ic_reg_write(void *opaque, hwaddr 
offset,
 case PC_TCTXT_CFG:
 /*
  * TODO: block group support
- *
- * PC_TCTXT_CFG_BLKGRP_EN
- * PC_TCTXT_CFG_HARD_CHIPID_BLK :
- *   Moves the chipid into block field for hardwired CAM compares.
- *   Block offset value is adjusted to 0b0..01 & ThrdId
- *
- *   Will require changes in xive_presenter_tctx_match(). I am
- *   not sure how to handle that yet.
  */
-
-/* Overrides hardwired chip ID with the chip ID field */
-if (val & PC_TCTXT_CHIPID_OVERRIDE) {
-xive->tctx_chipid = GETFIELD(PC_TCTXT_CHIPID, val);
-}
 break;
+
 case PC_TCTXT_TRACK:
 /*
  * PC_TCTXT_TRACK_EN:
@@ -1555,7 +1565,8 @@ static void xive_nvt_pic_print_info(XiveNVT *nvt, 
uint32_t nvt_idx,
 void pnv_xive_pic_print_info(PnvXive *xive, Monitor *mon)
 {
 XiveRouter *xrtr = XIVE_ROUTER(xive);
-uint8_t blk = xive->chip->chip_id;
+uint8_t blk =