[Qemu-devel] [PATCH v1 26/27] hw/i2c/Makefile.objs: Create new CONFIG_* variables for EEPROM and ACPI controller

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

Create separate variables for these components, they are
used in many boards but not all.  This allows finer-grain
selection of the included code with default-configs/*.mak.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 1 +
 default-configs/i386-softmmu.mak| 2 ++
 default-configs/mips-softmmu-common.mak | 2 ++
 default-configs/ppc-softmmu.mak | 1 +
 hw/i2c/Makefile.objs| 5 +++--
 5 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index d3fc82256f..d2c8b52f6d 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -150,6 +150,7 @@ CONFIG_ACPI=y
 CONFIG_ARM_VIRT=y
 CONFIG_SMBIOS=y
 CONFIG_ASPEED_SOC=y
+CONFIG_SMBUS_EEPROM=y
 CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
 CONFIG_FW_CFG_DMA=y
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 71c9f6fbcb..15b628757b 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -62,6 +62,8 @@ CONFIG_I82801B11=y
 CONFIG_SMBIOS=y
 CONFIG_PXB=y
 CONFIG_ACPI_VMGENID=y
+CONFIG_ACPI_SMBUS=y
+CONFIG_SMBUS_EEPROM=y
 CONFIG_FW_CFG_DMA=y
 CONFIG_I2C=y
 CONFIG_SEV=$(CONFIG_KVM)
diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 479fb4d900..ded74980e1 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -39,3 +39,5 @@ CONFIG_I2C=y
 CONFIG_R4K=y
 CONFIG_MALTA=y
 CONFIG_MIPSSIM=y
+CONFIG_ACPI_SMBUS=y
+CONFIG_SMBUS_EEPROM=y
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 7f80f0ccba..52acb7cf39 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -36,6 +36,7 @@ CONFIG_AT24C=y
 CONFIG_BITBANG_I2C=y
 CONFIG_M41T80=y
 CONFIG_VGA_CIRRUS=y
+CONFIG_SMBUS_EEPROM=y
 
 # For Macs
 CONFIG_ESCC=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 82e747e1cd..cecee486f7 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -1,8 +1,9 @@
-common-obj-$(CONFIG_I2C) += core.o smbus.o smbus_eeprom.o
+common-obj-$(CONFIG_I2C) += core.o smbus.o
+common-obj-$(CONFIG_SMBUS_EEPROM) += smbus_eeprom.o
 common-obj-$(CONFIG_DDC) += i2c-ddc.o
 common-obj-$(CONFIG_VERSATILE_I2C) += versatile_i2c.o
 common-obj-$(CONFIG_ACPI_X86) += smbus_ich9.o
-common-obj-$(CONFIG_APM) += pm_smbus.o
+common-obj-$(CONFIG_ACPI_SMBUS) += pm_smbus.o
 common-obj-$(CONFIG_BITBANG_I2C) += bitbang_i2c.o
 common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 22/27] hw/hppa/Makefile.objs: Create CONFIG_* for hppa

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/hppa-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
---
 default-configs/hppa-softmmu.mak | 1 +
 hw/hppa/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/hppa-softmmu.mak b/default-configs/hppa-softmmu.mak
index 4badc0521e..b594a6ddd9 100644
--- a/default-configs/hppa-softmmu.mak
+++ b/default-configs/hppa-softmmu.mak
@@ -10,3 +10,4 @@ CONFIG_IDE_CMD646=y
 # CONFIG_IDE_MMIO=y
 CONFIG_VIRTIO_VGA=y
 CONFIG_MC146818RTC=y
+CONFIG_DINO=y
diff --git a/hw/hppa/Makefile.objs b/hw/hppa/Makefile.objs
index bef241ed25..67838f50a3 100644
--- a/hw/hppa/Makefile.objs
+++ b/hw/hppa/Makefile.objs
@@ -1 +1 @@
-obj-y += machine.o pci.o dino.o
+obj-$(CONFIG_DINO) += pci.o machine.o dino.o
-- 
2.17.1




Re: [Qemu-devel] [Qemu-ppc] [PATCH v4 2/3] target/ppc: Add GDB callbacks for SPRs

2019-01-30 Thread Alexey Kardashevskiy



On 31/01/2019 03:30, Fabiano Rosas wrote:
> Alexey Kardashevskiy  writes:
> 
>>
>> but this is a register which does not have endianness, the endianness
>> appears here because the interface between gdb and qemu is
>> uint8_t*==bytestream but this interface should have fixed endianness
>> imho (now it is bigendian afaict).
>>
>> Something is not right here...
> 
> Having a fixed endianness would not work because GDB have no way of
> knowing how to represent what comes from the remote end.

It definitely would. A register is stored as "unsigned long" in QEMU and
all gdb has to do is printf("%lx") and that is it. The problem is that
we want to pass it as a byte stream from the gdb_read_register() hook
all the way to gdb and for some reason gdb does not define endianness of
that stream but rather tries guessing the endianness which is broken.

Today I was debugging rtas/clientinterface calls which a little endian
kernel makes and these calls need to switch to the big endian first. And
gdb goes nuts when this switch happens (note that I did not give an ELF
to gdb this time so it picked LE itself). Even if it could fetch the
endianness from QEMU, it would fail as it is an LE bit in MSR which is a
register which is parsed according to the gdb's idea of endianness :)


> It will
> always check the target endianness before printing a value, even if it
> refers to a register:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/findvar.c;hb=HEAD#l49
> 
> So in our case the contents of mem_buf need to match both the guest
> endianness *and* what GDB has set for 'show endian' because it will
> detect it automatically from the ELF. If it guesses incorrectly because
> there is no ELF, we need to use the 'set endian' command.
> 
> By the way, this is already the behavior for the registers that are
> already implemented (e.g. $msr). Here's the commit that introduced
> that:
> 
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8a286ce4502356ce0b97a2424a2cb7
> 
> Now, what might be a source of confusion here is the fact that we
> *always* do a bswap when the host is LE because QEMU thinks that the ppc
> guest is always BE. That requires the maybe_bswap function to make
> things right in the end.
> 
> What I could do is try to improve this by only swapping when the
> guest's actual endianness (msr_le) is different from the host's.

The bytestream for registers should have fixed endianness. But looking
at the gdb code makes me think it is not going to happen :(


> That
> is not entirely within the scope of this patch, though.

True. But since you are touching this, may be you could fix gdb too :)

Does gdb tell QEMU about what endianness it thinks that QEMU is using?
Or can it read it from QEMU? I cannot easily spot this in QEMU...


-- 
Alexey



[Qemu-devel] [PATCH v1 21/27] hw/cris/Makefile.objs: Create CONFIG_* for cris

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/cris-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/cris-softmmu.mak | 1 +
 hw/cris/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/cris-softmmu.mak b/default-configs/cris-softmmu.mak
index d970d50158..a637c4b4bf 100644
--- a/default-configs/cris-softmmu.mak
+++ b/default-configs/cris-softmmu.mak
@@ -4,3 +4,4 @@ CONFIG_ETRAXFS=y
 CONFIG_NAND=y
 CONFIG_PTIMER=y
 CONFIG_PFLASH_CFI02=y
+CONFIG_AXIS=y
diff --git a/hw/cris/Makefile.objs b/hw/cris/Makefile.objs
index 7624173f77..a4a27b3a13 100644
--- a/hw/cris/Makefile.objs
+++ b/hw/cris/Makefile.objs
@@ -1,2 +1,2 @@
 obj-y += boot.o
-obj-y += axis_dev88.o
+obj-$(CONFIG_AXIS) += axis_dev88.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 19/27] hw/sparc64/Makefile.objs: Create CONFIG_* for sparc64

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/sparc64-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/sparc64-softmmu.mak | 2 ++
 hw/sparc64/Makefile.objs| 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/default-configs/sparc64-softmmu.mak 
b/default-configs/sparc64-softmmu.mak
index ce63d47046..1fae4888db 100644
--- a/default-configs/sparc64-softmmu.mak
+++ b/default-configs/sparc64-softmmu.mak
@@ -17,3 +17,5 @@ CONFIG_SUNHME=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
 CONFIG_SUN4V_RTC=y
+CONFIG_SUN4U=y
+CONFIG_NIAGARA=y
diff --git a/hw/sparc64/Makefile.objs b/hw/sparc64/Makefile.objs
index 117e0ff27d..af0525c1a2 100644
--- a/hw/sparc64/Makefile.objs
+++ b/hw/sparc64/Makefile.objs
@@ -1,4 +1,4 @@
 obj-y += sparc64.o
-obj-y += sun4u_iommu.o
-obj-y += sun4u.o
-obj-y += niagara.o
\ No newline at end of file
+obj-$(CONFIG_SUN4U) += sun4u_iommu.o
+obj-$(CONFIG_SUN4U) += sun4u.o
+obj-$(CONFIG_NIAGARA) += niagara.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 16/27] hw/xtensa/Makefile.objs: Build xtensa_sim and xtensa_fpga conditionally

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

Add the new CONFIG_* values to default-config/xtensa*-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
Acked-by: Max Filippov 
---
 default-configs/xtensa-softmmu.mak   | 3 +++
 default-configs/xtensaeb-softmmu.mak | 3 +++
 hw/xtensa/Makefile.objs  | 4 ++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/default-configs/xtensa-softmmu.mak 
b/default-configs/xtensa-softmmu.mak
index 9d8899cde7..baf90ca162 100644
--- a/default-configs/xtensa-softmmu.mak
+++ b/default-configs/xtensa-softmmu.mak
@@ -3,3 +3,6 @@
 CONFIG_SERIAL=y
 CONFIG_OPENCORES_ETH=y
 CONFIG_PFLASH_CFI01=y
+
+CONFIG_XTENSA_SIM=y
+CONFIG_XTENSA_FPGA=y
diff --git a/default-configs/xtensaeb-softmmu.mak 
b/default-configs/xtensaeb-softmmu.mak
index 9d8899cde7..baf90ca162 100644
--- a/default-configs/xtensaeb-softmmu.mak
+++ b/default-configs/xtensaeb-softmmu.mak
@@ -3,3 +3,6 @@
 CONFIG_SERIAL=y
 CONFIG_OPENCORES_ETH=y
 CONFIG_PFLASH_CFI01=y
+
+CONFIG_XTENSA_SIM=y
+CONFIG_XTENSA_FPGA=y
diff --git a/hw/xtensa/Makefile.objs b/hw/xtensa/Makefile.objs
index cb4998d2bf..62e244fa53 100644
--- a/hw/xtensa/Makefile.objs
+++ b/hw/xtensa/Makefile.objs
@@ -1,4 +1,4 @@
 obj-y += pic_cpu.o
-obj-y += sim.o
 obj-y += xtensa_memory.o
-obj-y += xtfpga.o
+obj-$(CONFIG_XTENSA_SIM) += sim.o
+obj-$(CONFIG_XTENSA_FPGA) += xtfpga.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 15/27] hw/lm32/Makefile.objs: Conditionally build lm32 and milkmyst

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

CONFIG_LM32 and CONFIG_MILKYMIST added for lm32 and milkmyst build.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 hw/lm32/Makefile.objs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/lm32/Makefile.objs b/hw/lm32/Makefile.objs
index ea6418ae59..c3941866c7 100644
--- a/hw/lm32/Makefile.objs
+++ b/hw/lm32/Makefile.objs
@@ -1,3 +1,3 @@
 # LM32 boards
-obj-y += lm32_boards.o
-obj-y += milkymist.o
+obj-$(CONFIG_LM32) += lm32_boards.o
+obj-$(CONFIG_MILKYMIST) += milkymist.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 13/27] hw/s390/Makefile.objs: Create new CONFIG_* variables for s390x boards and devices

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

Make hw/s390x configurable and add new CONFIG_* to the
default-configs/s390x*-softmmu.mak. This will be used to
enable/disable vfio-ccw.

Signed-off-by: Paolo Bonzini 
---
 default-configs/s390x-softmmu.mak | 1 +
 hw/s390x/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/s390x-softmmu.mak 
b/default-configs/s390x-softmmu.mak
index 5eef375924..8bb7e438c8 100644
--- a/default-configs/s390x-softmmu.mak
+++ b/default-configs/s390x-softmmu.mak
@@ -8,3 +8,4 @@ CONFIG_S390_FLIC_KVM=$(CONFIG_KVM)
 CONFIG_VFIO_CCW=$(CONFIG_LINUX)
 CONFIG_WDT_DIAG288=y
 CONFIG_VFIO_AP=$(CONFIG_LINUX)
+CONFIG_S390_CCW_VIRTIO=y
diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
index ca68806e44..a18c471913 100644
--- a/hw/s390x/Makefile.objs
+++ b/hw/s390x/Makefile.objs
@@ -5,7 +5,7 @@ obj-y += sclpquiesce.o
 obj-y += sclpcpu.o
 obj-y += ipl.o
 obj-y += css.o
-obj-y += s390-virtio-ccw.o
+obj-$(CONFIG_S390_CCW_VIRTIO) += s390-virtio-ccw.o
 obj-y += 3270-ccw.o
 obj-y += virtio-ccw.o
 obj-$(CONFIG_VIRTIO_SERIAL) += virtio-ccw-serial.o
-- 
2.17.1




Re: [Qemu-devel] [PATCH] scripts: use git archive in archive-source

2019-01-30 Thread Gerd Hoffmann
  Hi,

> > +git archive --format tar $HEAD > "$tar_file"
> > +test $? -ne 0 && error "failed to archive qemu"
> >  for sm in $submodules; do
> > -git submodule update --init $sm
> > -test $? -ne 0 && error "failed to init submodule $sm"
> > +   git submodule update --init "$sm"
> 
> The current archive-source.sh code is careful to not touch the
> developer's current git checkout, because it runs  submodule
> update in a clone'd tree. The earlier patch hunk gets rid of the
> clone, so now submodule update is touching the developer's master
> git checkout. IMHO this is not acceptable - running tests (which
> use archive-source.sh) must never alter the developer's git checkout
> status in any way.

Can easily be fixed, the sha1 can be pulled out of "git submodule
status" instead of updating the submodules & use HEAD.

The only question is what to do best on uninitialized submodules.
Options are:
 * fetch the submodule into the developer tree (once).
 * clone the submodule into a temporary directory (each run).
 * throw an error.

cheers,
  Gerd




Re: [Qemu-devel] [Qemu-block] [PATCH v3 1/1] drive-mirror: add incremental mode

2019-01-30 Thread 滴滴云
 I am so sorry that the format problem has caused trouble for reviewers. I am 
very unfamiliar with the specification, but I will try my best to correct it. 
 As for ‘Signed-off-by’, I didn't understand the meaning of 'signed-off-by' at 
first. But now I have created an ID of myself by using gpg, and add it to git 
config.

在 2019/1/31 下午12:32,“Eric Blake” 写入:

On 1/30/19 10:01 PM, mahaocong wrote:
> From: mahaocong 
> 

You are STILL missing the commit message body, even though I requested
it [1].  Please 'git commit --amend', and paste in the contents that you
are sticking in your 0/1 cover letter that actually describe the details
behind this patch. Also, since you are sending a single patch, you don't
need a 0/1 cover letter (they are mandatory if you send 2 or more
patches in series; but don't add anything when you send just one patch,
although they don't hurt, as long as you do a correct division between
cover letter having information for the reviewer and patch itself having
a self-contained commit message).

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg00122.html

> Signed-off-by: mahaocong 

I previously mentioned [2] that you probably want to use a proper name
(typically more than one word), not a username. While I am not in a
position to argue whether 'mahaocong' is how you sign legal documents,
or what you may use in other open source projects, it is at least
courteous to reply to a reviewer's request when stating that you are
intentionally not going to do something about the request.

[2] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg00407.html

> ---

Here, after the --- marker, is a good place to describe how v3 differs
from v2, to speed up reviewers efforts if they have already looked at
the earlier version, and want to see what you changed in response to
their comments.

Just a UI review on my part (I haven't looked at the code proper, in
part because I'm still waiting for you to fix the commit message problem
- it's tough to justify reviewing in more depth when there are things
from the earlier version that are still not corrected)

> +++ b/qapi/block-core.json
> @@ -1727,6 +1727,11 @@
>  #(all the disk, only the sectors allocated in the topmost image, 
or
>  #only new I/O).
>  #
> +# @bitmap: the name of user-created-bitmap which is used on incremental 
mode
> +#  drive-mirror. If user select incremental mode, bitmap should 
not be
> +#  null, and can not set granularity, because the mirror bitmap 
should
> +#  have the same granularity with user-created-bitmap.

Missing a '(since 4.0)' tag. The grammar is awkward; maybe:

@bitmap: the name of a pre-existing bitmap to use in incremental mode;
must be present for incremental mode and absent otherwise. In
incremental mode, granularity should not be set, because the bitmap's
granularity is used instead.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org





[Qemu-devel] [PATCH v1 11/27] hw/ppc/Makefile.objs: Build all boards conditinally with CONFIG_*

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

CONFIG_PPC405, CONFIG_PPC440, CONFIG_MAC_OLDWORLD, CONFIG_MAX_NEWWORLD
and CONFIG_VIRTEX configuration options created for
default-configs/ppc*-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Yang Zhong 
Reviewed-by: Thomas Huth 
---
 default-configs/ppc-softmmu.mak |  7 ++-
 hw/ppc/Makefile.objs| 11 ++-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 23d871fb3e..7f80f0ccba 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -21,6 +21,10 @@ CONFIG_E500=y
 CONFIG_OPENPIC_KVM=$(call land,$(CONFIG_E500),$(CONFIG_KVM))
 CONFIG_PLATFORM_BUS=y
 CONFIG_ETSEC=y
+CONFIG_PPC405=y
+CONFIG_PPC440=y
+CONFIG_VIRTEX=y
+
 # For Sam460ex
 CONFIG_SAM460EX=y
 CONFIG_USB_EHCI_SYSBUS=y
@@ -34,7 +38,6 @@ CONFIG_M41T80=y
 CONFIG_VGA_CIRRUS=y
 
 # For Macs
-CONFIG_MAC=y
 CONFIG_ESCC=y
 CONFIG_MACIO=y
 CONFIG_MACIO_GPIO=y
@@ -50,6 +53,8 @@ CONFIG_GRACKLE_PCI=y
 CONFIG_UNIN_PCI=y
 CONFIG_DEC_PCI=y
 CONFIG_IDE_MACIO=y
+CONFIG_MAC_OLDWORLD=y
+CONFIG_MAC_NEWWORLD=y
 
 # For PReP
 CONFIG_PREP=y
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 4e0c1c0941..7d815b7d57 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -14,19 +14,20 @@ endif
 obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
 # PowerPC 4xx boards
 obj-y += ppc4xx_devs.o ppc405_uc.o
-obj-$(CONFIG_PPC4XX) += ppc4xx_pci.o ppc405_boards.o
-obj-$(CONFIG_PPC4XX) += ppc440_bamboo.o ppc440_pcix.o ppc440_uc.o
+obj-$(CONFIG_PPC405) += ppc405_boards.o
+obj-$(CONFIG_PPC440) += ppc440_bamboo.o ppc440_pcix.o ppc440_uc.o
+obj-$(CONFIG_PPC4XX) += ppc4xx_pci.o
 obj-$(CONFIG_SAM460EX) += sam460ex.o
 # PReP
 obj-$(CONFIG_PREP) += prep.o
 obj-$(CONFIG_PREP) += prep_systemio.o
 obj-${CONFIG_RS6000_MC} += rs6000_mc.o
 # OldWorld PowerMac
-obj-$(CONFIG_MAC) += mac_oldworld.o
+obj-$(CONFIG_MAC_OLDWORLD) += mac_oldworld.o
 # NewWorld PowerMac
-obj-$(CONFIG_MAC) += mac_newworld.o
+obj-$(CONFIG_MAC_NEWWORLD) += mac_newworld.o
 # e500
 obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
 obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
 # PowerPC 440 Xilinx ML507 reference board.
-obj-$(CONFIG_XILINX) += virtex_ml507.o
+obj-$(CONFIG_VIRTEX) += virtex_ml507.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 25/27] hw/tricore/Makefile.objs: Create CONFIG_* for tricore

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/tricore-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/tricore-softmmu.mak | 1 +
 hw/tricore/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/tricore-softmmu.mak 
b/default-configs/tricore-softmmu.mak
index e69de29bb2..c397cff38a 100644
--- a/default-configs/tricore-softmmu.mak
+++ b/default-configs/tricore-softmmu.mak
@@ -0,0 +1 @@
+CONFIG_TRICORE=y
diff --git a/hw/tricore/Makefile.objs b/hw/tricore/Makefile.objs
index 435e095cff..5501f6c1a8 100644
--- a/hw/tricore/Makefile.objs
+++ b/hw/tricore/Makefile.objs
@@ -1 +1 @@
-obj-y += tricore_testboard.o
+obj-$(CONFIG_TRICORE) += tricore_testboard.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 20/27] hw/alpha/Makefile.objs: Create CONFIG_* for alpha

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/alpha-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
Reviewed-by: Richard Henderson 
---
 default-configs/alpha-softmmu.mak | 1 +
 hw/alpha/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/alpha-softmmu.mak 
b/default-configs/alpha-softmmu.mak
index 4d654eaa0b..49cb7ce351 100644
--- a/default-configs/alpha-softmmu.mak
+++ b/default-configs/alpha-softmmu.mak
@@ -19,3 +19,4 @@ CONFIG_I8259=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
 CONFIG_SMC37C669=y
+CONFIG_DP264=y
diff --git a/hw/alpha/Makefile.objs b/hw/alpha/Makefile.objs
index 5c742756f0..62fdf3edec 100644
--- a/hw/alpha/Makefile.objs
+++ b/hw/alpha/Makefile.objs
@@ -1 +1 @@
-obj-y += dp264.o pci.o typhoon.o
+obj-$(CONFIG_DP264) += dp264.o pci.o typhoon.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 17/27] hw/nios2/Makefile.objs: Conditionally build nios2

2019-01-30 Thread Yang Zhong
CONFIG_NIOS2_10M50 added for 10m50 dev board.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/nios2-softmmu.mak | 1 +
 hw/nios2/Makefile.objs| 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/default-configs/nios2-softmmu.mak 
b/default-configs/nios2-softmmu.mak
index 74dc70caae..ab42d0fc28 100644
--- a/default-configs/nios2-softmmu.mak
+++ b/default-configs/nios2-softmmu.mak
@@ -4,3 +4,4 @@ CONFIG_NIOS2=y
 CONFIG_SERIAL=y
 CONFIG_PTIMER=y
 CONFIG_ALTERA_TIMER=y
+CONFIG_NIOS2_10M50=y
diff --git a/hw/nios2/Makefile.objs b/hw/nios2/Makefile.objs
index 6b5c421760..89a419a9f5 100644
--- a/hw/nios2/Makefile.objs
+++ b/hw/nios2/Makefile.objs
@@ -1 +1,2 @@
-obj-y = boot.o cpu_pic.o 10m50_devboard.o
+obj-y = boot.o cpu_pic.o
+obj-$(CONFIG_NIOS2_10M50) += 10m50_devboard.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 23/27] hw/moxie/Makefile.objs: Conditionally build moxie

2019-01-30 Thread Yang Zhong
CONFIG_MOXIE added for moxiesim board.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/moxie-softmmu.mak | 1 +
 hw/moxie/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/moxie-softmmu.mak 
b/default-configs/moxie-softmmu.mak
index e00d04..17ba906dc2 100644
--- a/default-configs/moxie-softmmu.mak
+++ b/default-configs/moxie-softmmu.mak
@@ -5,3 +5,4 @@ CONFIG_MC146818RTC=y
 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y
 CONFIG_VGA=y
+CONFIG_MOXIESIM=y
diff --git a/hw/moxie/Makefile.objs b/hw/moxie/Makefile.objs
index bfc90012fd..ddbf300f54 100644
--- a/hw/moxie/Makefile.objs
+++ b/hw/moxie/Makefile.objs
@@ -1,2 +1,2 @@
 # moxie boards
-obj-y += moxiesim.o
+obj-$(CONFIG_MOXIESIM) += moxiesim.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 09/27] hw/microblaze/Makefile.objs: Create configs for petalogix and xilinx boards

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

CONFIG_PETALOGIX_* and CONFIG_XLNX_*  configs added to
default-configs/microblaze-softmmu.mak and
default-configs/microblazeel-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/microblaze-softmmu.mak | 3 +++
 hw/microblaze/Makefile.objs| 6 +++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/default-configs/microblaze-softmmu.mak 
b/default-configs/microblaze-softmmu.mak
index 7fca8e4c99..14837cf74a 100644
--- a/default-configs/microblaze-softmmu.mak
+++ b/default-configs/microblaze-softmmu.mak
@@ -10,3 +10,6 @@ CONFIG_XILINX_ETHLITE=y
 CONFIG_SSI=y
 CONFIG_SSI_M25P80=y
 CONFIG_XLNX_ZYNQMP=y
+CONFIG_PETALOGIX_S3ADSP1800=y
+CONFIG_PETALOGIX_ML605=y
+CONFIG_XLNX_ZYNQMP_PMU=y
diff --git a/hw/microblaze/Makefile.objs b/hw/microblaze/Makefile.objs
index ae9fd40de7..8595a62f6c 100644
--- a/hw/microblaze/Makefile.objs
+++ b/hw/microblaze/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += petalogix_s3adsp1800_mmu.o
-obj-y += petalogix_ml605_mmu.o
-obj-y += xlnx-zynqmp-pmu.o
+obj-$(CONFIG_PETALOGIX_S3ADSP1800) += petalogix_s3adsp1800_mmu.o
+obj-$(CONFIG_PETALOGIX_ML605) += petalogix_ml605_mmu.o
+obj-$(CONFIG_XLNX_ZYNQMP_PMU) += xlnx-zynqmp-pmu.o
 obj-y += boot.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 06/27] hw/i386/Makefile.objs: Build pc_piix* and pc_q35 boards

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

CONFIG_PIIX and CONFIG_Q35 created for the pc board object files. These
are enabled automatically at default-configs/i386-softmmu.mak and
default-configs/x86_64-softmmu.mak

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/i386-softmmu.mak | 2 ++
 hw/i386/Makefile.objs| 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 48da9968cc..71c9f6fbcb 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -68,3 +68,5 @@ CONFIG_SEV=$(CONFIG_KVM)
 CONFIG_VTD=y
 CONFIG_AMD_IOMMU=y
 CONFIG_PAM=y
+CONFIG_I440FX=y
+CONFIG_Q35=y
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index fa87a14152..3de7ca2bb9 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -1,6 +1,8 @@
 obj-$(CONFIG_KVM) += kvm/
 obj-y += multiboot.o
-obj-y += pc.o pc_piix.o pc_q35.o
+obj-y += pc.o
+obj-$(CONFIG_I440FX) += pc_piix.o
+obj-$(CONFIG_Q35) += pc_q35.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_VTD) += x86-iommu.o intel_iommu.o
 obj-$(CONFIG_AMD_IOMMU) += x86-iommu.o amd_iommu.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 18/27] hw/riscv/Makefile.objs: Create CONFIG_* for riscv boards

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/riscv*-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Alistair Francis 
---
 default-configs/riscv32-softmmu.mak |  7 +++
 default-configs/riscv64-softmmu.mak |  7 +++
 hw/riscv/Makefile.objs  | 22 +++---
 3 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/default-configs/riscv32-softmmu.mak 
b/default-configs/riscv32-softmmu.mak
index fbfd1d4e4b..65337166e1 100644
--- a/default-configs/riscv32-softmmu.mak
+++ b/default-configs/riscv32-softmmu.mak
@@ -12,3 +12,10 @@ CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 
 CONFIG_VGA=y
 CONFIG_VGA_PCI=y
+
+CONFIG_SPIKE=y
+CONFIG_HART=y
+CONFIG_SIFIVE_E=y
+CONFIG_SIFIVE=y
+CONFIG_SIFIVE_U=y
+CONFIG_RISCV_VIRT=y
diff --git a/default-configs/riscv64-softmmu.mak 
b/default-configs/riscv64-softmmu.mak
index fbfd1d4e4b..65337166e1 100644
--- a/default-configs/riscv64-softmmu.mak
+++ b/default-configs/riscv64-softmmu.mak
@@ -12,3 +12,10 @@ CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 
 CONFIG_VGA=y
 CONFIG_VGA_PCI=y
+
+CONFIG_SPIKE=y
+CONFIG_HART=y
+CONFIG_SIFIVE_E=y
+CONFIG_SIFIVE=y
+CONFIG_SIFIVE_U=y
+CONFIG_RISCV_VIRT=y
diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
index 1dde01d39d..79bfb3abf9 100644
--- a/hw/riscv/Makefile.objs
+++ b/hw/riscv/Makefile.objs
@@ -1,11 +1,11 @@
-obj-y += riscv_htif.o
-obj-y += riscv_hart.o
-obj-y += sifive_e.o
-obj-y += sifive_clint.o
-obj-y += sifive_prci.o
-obj-y += sifive_plic.o
-obj-y += sifive_test.o
-obj-y += sifive_u.o
-obj-y += sifive_uart.o
-obj-y += spike.o
-obj-y += virt.o
+obj-$(CONFIG_SPIKE) += riscv_htif.o
+obj-$(CONFIG_HART) += riscv_hart.o
+obj-$(CONFIG_SIFIVE_E) += sifive_e.o
+obj-$(CONFIG_SIFIVE) += sifive_clint.o
+obj-$(CONFIG_SIFIVE) += sifive_prci.o
+obj-$(CONFIG_SIFIVE) += sifive_plic.o
+obj-$(CONFIG_SIFIVE) += sifive_test.o
+obj-$(CONFIG_SIFIVE_U) += sifive_u.o
+obj-$(CONFIG_SIFIVE) += sifive_uart.o
+obj-$(CONFIG_SPIKE) += spike.o
+obj-$(CONFIG_RISCV_VIRT) += virt.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 12/27] hw/sh4/Makefile.objs: New CONFIG_* varibales created for sh4 boards and device

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

Make hw/sh4 configurable and add new CONFIG_* to the
default-configs/sh4*-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/sh4-softmmu.mak   | 2 ++
 default-configs/sh4eb-softmmu.mak | 2 ++
 hw/sh4/Makefile.objs  | 4 ++--
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/default-configs/sh4-softmmu.mak b/default-configs/sh4-softmmu.mak
index caeccd55be..1fdb009151 100644
--- a/default-configs/sh4-softmmu.mak
+++ b/default-configs/sh4-softmmu.mak
@@ -19,3 +19,5 @@ CONFIG_PCSPK=y
 CONFIG_I82374=y
 CONFIG_I8257=y
 CONFIG_MC146818RTC=y
+CONFIG_R2D=y
+CONFIG_SHIX=y
diff --git a/default-configs/sh4eb-softmmu.mak 
b/default-configs/sh4eb-softmmu.mak
index 53b9cd7b5a..3b550a5fe8 100644
--- a/default-configs/sh4eb-softmmu.mak
+++ b/default-configs/sh4eb-softmmu.mak
@@ -19,3 +19,5 @@ CONFIG_PCSPK=y
 CONFIG_I82374=y
 CONFIG_I8257=y
 CONFIG_MC146818RTC=y
+CONFIG_R2D=y
+CONFIG_SHIX=y
diff --git a/hw/sh4/Makefile.objs b/hw/sh4/Makefile.objs
index 2393702c57..2a707f9473 100644
--- a/hw/sh4/Makefile.objs
+++ b/hw/sh4/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += shix.o r2d.o
-
 obj-y += sh7750.o sh7750_regnames.o
 obj-y += sh_pci.o
+obj-$(CONFIG_R2D) +=  r2d.o
+obj-$(CONFIG_SHIX) += shix.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 07/27] hw/arm/Makefile.objs: CONFIG_VIRT created for virt board

2019-01-30 Thread Yang Zhong
make virt code configurable and the new CONFIG_VIRT definitions
added to the default-configs/arm-softmmu.mak to replace CONFIG_ACPI
in arm board.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 1 +
 hw/arm/Makefile.objs| 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 107f801367..d3fc82256f 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -147,6 +147,7 @@ CONFIG_XIO3130=y
 CONFIG_IOH3420=y
 CONFIG_I82801B11=y
 CONFIG_ACPI=y
+CONFIG_ARM_VIRT=y
 CONFIG_SMBIOS=y
 CONFIG_ASPEED_SOC=y
 CONFIG_GPIO_KEY=y
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 50c7b4a927..dab3f88a7c 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -1,4 +1,5 @@
-obj-y += boot.o virt.o sysbus-fdt.o
+obj-y += boot.o sysbus-fdt.o
+obj-$(CONFIG_ARM_VIRT) += virt.o
 obj-$(CONFIG_ACPI) += virt-acpi-build.o
 obj-$(CONFIG_DIGIC) += digic_boards.o
 obj-$(CONFIG_EXYNOS4) += exynos4_boards.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 14/27] hw/sparc/Makefile.objs: CONFIG_* for sun4m and leon3 created

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

CONFIG_LEON3 added to default-configs/sparc-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/sparc-softmmu.mak | 2 ++
 hw/sparc/Makefile.objs| 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/default-configs/sparc-softmmu.mak 
b/default-configs/sparc-softmmu.mak
index 12f97eeb20..59a4a3d693 100644
--- a/default-configs/sparc-softmmu.mak
+++ b/default-configs/sparc-softmmu.mak
@@ -18,4 +18,6 @@ CONFIG_CS4231=y
 CONFIG_GRLIB=y
 CONFIG_STP2000=y
 CONFIG_ECCMEMCTL=y
+
 CONFIG_SUN4M=y
+CONFIG_LEON3=y
diff --git a/hw/sparc/Makefile.objs b/hw/sparc/Makefile.objs
index e2d0828c39..d57e33f83e 100644
--- a/hw/sparc/Makefile.objs
+++ b/hw/sparc/Makefile.objs
@@ -1 +1,3 @@
-obj-y += sun4m_iommu.o sun4m.o leon3.o
+obj-$(CONFIG_SUN4M) += sun4m_iommu.o
+obj-$(CONFIG_SUN4M) += sun4m.o
+obj-$(CONFIG_LEON3) += leon3.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 04/27] hw/pci-host/Makefile.objs: make CONFIGS clear for PCI EXPRESS

2019-01-30 Thread Yang Zhong
Change the CONFIGs for PCI EXPRESS and make module name more
clear for code files.

Signed-off-by: Yang Zhong 
Cc: Michael S. Tsirkin 
Signed-off-by: Paolo Bonzini 
---
 default-configs/arm-softmmu.mak  | 4 ++--
 default-configs/i386-softmmu.mak | 2 +-
 default-configs/mips64el-softmmu.mak | 2 +-
 default-configs/pci.mak  | 2 +-
 default-configs/riscv32-softmmu.mak  | 2 +-
 default-configs/riscv64-softmmu.mak  | 2 +-
 hw/net/Makefile.objs | 4 ++--
 hw/pci-host/Makefile.objs| 8 
 8 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 3c9351f029..107f801367 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -122,7 +122,7 @@ CONFIG_VERSATILE=y
 CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
-CONFIG_PCI_GENERIC=y
+CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 CONFIG_VFIO_XGMAC=y
 CONFIG_VFIO_AMD_XGBE=y
 
@@ -153,7 +153,7 @@ CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
 CONFIG_FW_CFG_DMA=y
 CONFIG_XILINX_AXI=y
-CONFIG_PCI_DESIGNWARE=y
+CONFIG_PCI_EXPRESS_DESIGNWARE=y
 
 CONFIG_STRONGARM=y
 CONFIG_HIGHBANK=y
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 64c998c4c8..2f919df346 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -47,7 +47,7 @@ CONFIG_ISA_TESTDEV=y
 CONFIG_VMPORT=y
 CONFIG_SGA=y
 CONFIG_LPC_ICH9=y
-CONFIG_PCI_Q35=y
+CONFIG_PCI_EXPRESS_Q35=y
 CONFIG_APIC=y
 CONFIG_IOAPIC=y
 CONFIG_PVPANIC=y
diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index c2ae313f47..9eb1208b58 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -12,4 +12,4 @@ CONFIG_JAZZ_LED=y
 CONFIG_VT82C686=y
 CONFIG_MIPS_BOSTON=y
 CONFIG_FITLOADER=y
-CONFIG_PCI_XILINX=y
+CONFIG_PCI_EXPRESS_XILINX=y
diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index 6c7be12779..83738cbb65 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -22,7 +22,7 @@ CONFIG_MEGASAS_SCSI_PCI=y
 CONFIG_MPTSAS_SCSI_PCI=y
 CONFIG_RTL8139_PCI=y
 CONFIG_E1000_PCI=y
-CONFIG_E1000E_PCI=y
+CONFIG_E1000E_PCI_EXPRESS=y
 CONFIG_IDE_CORE=y
 CONFIG_IDE_QDEV=y
 CONFIG_IDE_PCI=y
diff --git a/default-configs/riscv32-softmmu.mak 
b/default-configs/riscv32-softmmu.mak
index c9c5971409..fbfd1d4e4b 100644
--- a/default-configs/riscv32-softmmu.mak
+++ b/default-configs/riscv32-softmmu.mak
@@ -8,7 +8,7 @@ CONFIG_VIRTIO_MMIO=y
 
 CONFIG_CADENCE=y
 
-CONFIG_PCI_GENERIC=y
+CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 
 CONFIG_VGA=y
 CONFIG_VGA_PCI=y
diff --git a/default-configs/riscv64-softmmu.mak 
b/default-configs/riscv64-softmmu.mak
index c9c5971409..fbfd1d4e4b 100644
--- a/default-configs/riscv64-softmmu.mak
+++ b/default-configs/riscv64-softmmu.mak
@@ -8,7 +8,7 @@ CONFIG_VIRTIO_MMIO=y
 
 CONFIG_CADENCE=y
 
-CONFIG_PCI_GENERIC=y
+CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 
 CONFIG_VGA=y
 CONFIG_VGA_PCI=y
diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
index fa461d4463..a43351aa04 100644
--- a/hw/net/Makefile.objs
+++ b/hw/net/Makefile.objs
@@ -7,8 +7,8 @@ common-obj-$(CONFIG_EEPRO100_PCI) += eepro100.o
 common-obj-$(CONFIG_PCNET_PCI) += pcnet-pci.o
 common-obj-$(CONFIG_PCNET_COMMON) += pcnet.o
 common-obj-$(CONFIG_E1000_PCI) += e1000.o e1000x_common.o
-common-obj-$(CONFIG_E1000E_PCI) += net_tx_pkt.o net_rx_pkt.o
-common-obj-$(CONFIG_E1000E_PCI) += e1000e.o e1000e_core.o e1000x_common.o
+common-obj-$(CONFIG_E1000E_PCI_EXPRESS) += net_tx_pkt.o net_rx_pkt.o
+common-obj-$(CONFIG_E1000E_PCI_EXPRESS) += e1000e.o e1000e_core.o 
e1000x_common.o
 common-obj-$(CONFIG_RTL8139_PCI) += rtl8139.o
 common-obj-$(CONFIG_VMXNET3_PCI) += net_tx_pkt.o net_rx_pkt.o
 common-obj-$(CONFIG_VMXNET3_PCI) += vmxnet3.o
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index 6d6597c065..073d5124d1 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -14,8 +14,8 @@ common-obj-$(CONFIG_VERSATILE_PCI) += versatile.o
 common-obj-$(CONFIG_PCI_SABRE) += sabre.o
 common-obj-$(CONFIG_FULONG) += bonito.o
 common-obj-$(CONFIG_PCI_PIIX) += piix.o
-common-obj-$(CONFIG_PCI_Q35) += q35.o
-common-obj-$(CONFIG_PCI_GENERIC) += gpex.o
-common-obj-$(CONFIG_PCI_XILINX) += xilinx-pcie.o
+common-obj-$(CONFIG_PCI_EXPRESS_Q35) += q35.o
+common-obj-$(CONFIG_PCI_EXPRESS_GENERIC_BRIDGE) += gpex.o
+common-obj-$(CONFIG_PCI_EXPRESS_XILINX) += xilinx-pcie.o
 
-common-obj-$(CONFIG_PCI_DESIGNWARE) += designware.o
+common-obj-$(CONFIG_PCI_EXPRESS_DESIGNWARE) += designware.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 24/27] hw/openrisc/Makefile.objs: Create CONFIG_* for openrisc

2019-01-30 Thread Yang Zhong
Add the new configs to default-configs/or1k-sofmmu.mak.

Signed-off-by: Yang Zhong 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/or1k-softmmu.mak | 1 +
 hw/openrisc/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/or1k-softmmu.mak b/default-configs/or1k-softmmu.mak
index 6f5824fd48..6a0f2ef6cf 100644
--- a/default-configs/or1k-softmmu.mak
+++ b/default-configs/or1k-softmmu.mak
@@ -3,3 +3,4 @@
 CONFIG_SERIAL=y
 CONFIG_OPENCORES_ETH=y
 CONFIG_OMPIC=y
+CONFIG_OR1K_SIM=y
diff --git a/hw/openrisc/Makefile.objs b/hw/openrisc/Makefile.objs
index 61246b149b..aa04de7f5a 100644
--- a/hw/openrisc/Makefile.objs
+++ b/hw/openrisc/Makefile.objs
@@ -1,2 +1,2 @@
 obj-y = pic_cpu.o cputimer.o
-obj-y += openrisc_sim.o 
+obj-$(CONFIG_OR1K_SIM) += openrisc_sim.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 10/27] hw/mips/Makefile.objs: Create CONFIG_* for r4k, malta, mipssim boards

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

Add the new configs to default-configs/mips*-sofmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Yang Zhong 
Reviewed-by: Thomas Huth 
---
 default-configs/mips-softmmu-common.mak | 3 +++
 hw/mips/Makefile.objs   | 5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index fae2347ee7..479fb4d900 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -36,3 +36,6 @@ CONFIG_EMPTY_SLOT=y
 CONFIG_MIPS_CPS=y
 CONFIG_MIPS_ITU=y
 CONFIG_I2C=y
+CONFIG_R4K=y
+CONFIG_MALTA=y
+CONFIG_MIPSSIM=y
diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
index 17a311aaba..525809af07 100644
--- a/hw/mips/Makefile.objs
+++ b/hw/mips/Makefile.objs
@@ -1,7 +1,8 @@
-obj-y += mips_r4k.o mips_malta.o mips_mipssim.o
 obj-y += addr.o mips_int.o
+obj-$(CONFIG_R4K) += mips_r4k.o
+obj-$(CONFIG_MALTA) += gt64xxx_pci.o mips_malta.o
+obj-$(CONFIG_MIPSSIM) += mips_mipssim.o
 obj-$(CONFIG_JAZZ) += mips_jazz.o
 obj-$(CONFIG_FULONG) += mips_fulong2e.o
-obj-y += gt64xxx_pci.o
 obj-$(CONFIG_MIPS_CPS) += cps.o
 obj-$(CONFIG_MIPS_BOSTON) += boston.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 03/27] vfio: move conditional up to hw/Makefile.objs

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

Instead of wrapping the entire Makefile.objs with an ifeq/endif, just
include the directory only for Linux.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 hw/Makefile.objs  | 2 +-
 hw/vfio/Makefile.objs | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 39d882af6f..22dd211363 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -30,7 +30,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += ssi/
 devices-dirs-$(CONFIG_SOFTMMU) += timer/
 devices-dirs-$(CONFIG_TPM) += tpm/
 devices-dirs-$(CONFIG_SOFTMMU) += usb/
-devices-dirs-$(CONFIG_SOFTMMU) += vfio/
+devices-dirs-$(CONFIG_LINUX) += vfio/
 devices-dirs-$(CONFIG_SOFTMMU) += virtio/
 devices-dirs-$(CONFIG_SOFTMMU) += watchdog/
 devices-dirs-$(CONFIG_SOFTMMU) += xen/
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index 8b3f664d85..91805893f7 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -1,4 +1,3 @@
-ifeq ($(CONFIG_LINUX), y)
 obj-$(CONFIG_SOFTMMU) += common.o
 obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o
 obj-$(CONFIG_VFIO_CCW) += ccw.o
@@ -7,4 +6,3 @@ obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
 obj-$(CONFIG_VFIO_AMD_XGBE) += amd-xgbe.o
 obj-$(CONFIG_SOFTMMU) += spapr.o
 obj-$(CONFIG_VFIO_AP) += ap.o
-endif
-- 
2.17.1




[Qemu-devel] [PATCH v1 02/27] ide: split ioport registration to a separate file

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

This is not needed on ARM, and brings in ISA bus code which is otherwise not
necessary.

Signed-off-by: Paolo Bonzini 
---
 hw/ide/Makefile.objs |  4 +--
 hw/ide/core.c| 25 -
 hw/ide/ioport.c  | 66 
 3 files changed, 68 insertions(+), 27 deletions(-)
 create mode 100644 hw/ide/ioport.c

diff --git a/hw/ide/Makefile.objs b/hw/ide/Makefile.objs
index fc328ffbe8..a142add90e 100644
--- a/hw/ide/Makefile.objs
+++ b/hw/ide/Makefile.objs
@@ -1,8 +1,8 @@
 common-obj-$(CONFIG_IDE_CORE) += core.o atapi.o
 common-obj-$(CONFIG_IDE_QDEV) += qdev.o
 common-obj-$(CONFIG_IDE_PCI) += pci.o
-common-obj-$(CONFIG_IDE_ISA) += isa.o
-common-obj-$(CONFIG_IDE_PIIX) += piix.o
+common-obj-$(CONFIG_IDE_ISA) += isa.o ioport.o
+common-obj-$(CONFIG_IDE_PIIX) += piix.o ioport.o
 common-obj-$(CONFIG_IDE_CMD646) += cmd646.o
 common-obj-$(CONFIG_IDE_MACIO) += macio.o
 common-obj-$(CONFIG_IDE_MMIO) += mmio.o
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c3d779db6e..84832008b8 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2686,31 +2686,6 @@ void ide_exit(IDEState *s)
 qemu_vfree(s->io_buffer);
 }
 
-static const MemoryRegionPortio ide_portio_list[] = {
-{ 0, 8, 1, .read = ide_ioport_read, .write = ide_ioport_write },
-{ 0, 1, 2, .read = ide_data_readw, .write = ide_data_writew },
-{ 0, 1, 4, .read = ide_data_readl, .write = ide_data_writel },
-PORTIO_END_OF_LIST(),
-};
-
-static const MemoryRegionPortio ide_portio2_list[] = {
-{ 0, 1, 1, .read = ide_status_read, .write = ide_cmd_write },
-PORTIO_END_OF_LIST(),
-};
-
-void ide_init_ioport(IDEBus *bus, ISADevice *dev, int iobase, int iobase2)
-{
-/* ??? Assume only ISA and PCI configurations, and that the PCI-ISA
-   bridge has been setup properly to always register with ISA.  */
-isa_register_portio_list(dev, >portio_list,
- iobase, ide_portio_list, bus, "ide");
-
-if (iobase2) {
-isa_register_portio_list(dev, >portio2_list,
- iobase2, ide_portio2_list, bus, "ide");
-}
-}
-
 static bool is_identify_set(void *opaque, int version_id)
 {
 IDEState *s = opaque;
diff --git a/hw/ide/ioport.c b/hw/ide/ioport.c
new file mode 100644
index 00..a0b3c1f6a1
--- /dev/null
+++ b/hw/ide/ioport.c
@@ -0,0 +1,66 @@
+/*
+ * QEMU IDE disk and CD/DVD-ROM Emulator
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2006 Openedhand Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/hw.h"
+#include "hw/isa/isa.h"
+#include "qemu/error-report.h"
+#include "qemu/timer.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/blockdev.h"
+#include "sysemu/dma.h"
+#include "hw/block/block.h"
+#include "sysemu/block-backend.h"
+#include "qapi/error.h"
+#include "qemu/cutils.h"
+#include "sysemu/replay.h"
+
+#include "hw/ide/internal.h"
+#include "trace.h"
+
+static const MemoryRegionPortio ide_portio_list[] = {
+{ 0, 8, 1, .read = ide_ioport_read, .write = ide_ioport_write },
+{ 0, 1, 2, .read = ide_data_readw, .write = ide_data_writew },
+{ 0, 1, 4, .read = ide_data_readl, .write = ide_data_writel },
+PORTIO_END_OF_LIST(),
+};
+
+static const MemoryRegionPortio ide_portio2_list[] = {
+{ 0, 1, 1, .read = ide_status_read, .write = ide_cmd_write },
+PORTIO_END_OF_LIST(),
+};
+
+void ide_init_ioport(IDEBus *bus, ISADevice *dev, int iobase, int iobase2)
+{
+/* ??? Assume only ISA and PCI configurations, and that the PCI-ISA
+   bridge has been setup properly to always register with ISA.  */
+isa_register_portio_list(dev, >portio_list,
+ iobase, ide_portio_list, bus, "ide");
+
+if (iobase2) {
+isa_register_portio_list(dev, >portio2_list,
+ iobase2, ide_portio2_list, bus, "ide");
+}
+}
-- 
2.17.1




[Qemu-devel] [PATCH v1 08/27] hw/m68k/Makefile.objs: Conditionally build boards

2019-01-30 Thread Yang Zhong
From: Ákos Kovács 

CONFIG_AN5206, CONFIG_MCF5206 and CONFIG_MCF5208 make
variables created for m68k boards, and added to
default-configs/m86k-softmmu.mak.

Signed-off-by: Ákos Kovács 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/m68k-softmmu.mak | 2 ++
 hw/m68k/Makefile.objs| 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/default-configs/m68k-softmmu.mak b/default-configs/m68k-softmmu.mak
index 60f7cdfbf2..27f5274244 100644
--- a/default-configs/m68k-softmmu.mak
+++ b/default-configs/m68k-softmmu.mak
@@ -2,3 +2,5 @@
 
 CONFIG_COLDFIRE=y
 CONFIG_PTIMER=y
+CONFIG_AN5206=y
+CONFIG_MCF5208=y
diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
index d1f089c08a..482f8477b4 100644
--- a/hw/m68k/Makefile.objs
+++ b/hw/m68k/Makefile.objs
@@ -1,2 +1,2 @@
-obj-y += an5206.o mcf5208.o
-obj-y += mcf5206.o mcf_intc.o
+obj-$(CONFIG_AN5206) += an5206.o mcf5206.o
+obj-$(CONFIG_MCF5208) += mcf5208.o mcf_intc.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 00/27] make qemu configurable for Kconfig

2019-01-30 Thread Yang Zhong
This patch set is part of Kconfig task, and our target is to make
all platform's code file configurable for Kconfig, which is suitable
for add "config XXX" for all platforms.

As for Kconfig patch set(RFC v5), please ref below thread:
http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg06466.html

The change list:

non-rfc v5 --> v1:
   patch 1 : update the commit message(Thomas Huth)
   patch 2 : add ioport.o to ide isa and ide piix(Thomas Huth)
   patch 7 : CONFIG_ARM_VIRT to replace CONFIG_VIRT(Thomas Huth)
   patch 13: CONFIG_S390_CCW_VIRTIO is only for s390-virtio-ccw.o(Thomas 
Huth)
   patch 23: CONFIG_MOXIESIM to replace CONFIG_MOXIE(Thomas Huth)
   patch 24: CONFIG_OR1K_SIM to replace CONFIG_OPENRISC(Thomas Huth)

Paolo Bonzini (8):
  arm: disable CONFIG_SERIAL_ISA
  ide: split ioport registration to a separate file
  vfio: move conditional up to hw/Makefile.objs
  build: actually use CONFIG_PAM
  hw/i386/Makefile.objs: Build pc_piix* and pc_q35 boards
  hw/s390/Makefile.objs: Create new CONFIG_* variables for s390x boards
and devices
  hw/i2c/Makefile.objs: Create new CONFIG_* variables for EEPROM and
ACPI controller
  hw/vfio/Makefile.objs: Create new CONFIG_* variables for VFIO core and
PCI

Yang Zhong (11):
  hw/pci-host/Makefile.objs: make CONFIGS clear for PCI EXPRESS
  hw/arm/Makefile.objs: CONFIG_VIRT created for virt board
  hw/nios2/Makefile.objs: Conditionally build nios2
  hw/riscv/Makefile.objs: Create CONFIG_* for riscv boards
  hw/sparc64/Makefile.objs: Create CONFIG_* for sparc64
  hw/alpha/Makefile.objs: Create CONFIG_* for alpha
  hw/cris/Makefile.objs: Create CONFIG_* for cris
  hw/hppa/Makefile.objs: Create CONFIG_* for hppa
  hw/moxie/Makefile.objs: Conditionally build moxie
  hw/openrisc/Makefile.objs: Create CONFIG_* for openrisc
  hw/tricore/Makefile.objs: Create CONFIG_* for tricore

Ákos Kovács (8):
  hw/m68k/Makefile.objs: Conditionally build boards
  hw/microblaze/Makefile.objs: Create configs for petalogix and xilinx
boards
  hw/mips/Makefile.objs: Create CONFIG_* for r4k, malta, mipssim boards
  hw/ppc/Makefile.objs: Build all boards conditinally with CONFIG_*
  hw/sh4/Makefile.objs: New CONFIG_* varibales created for sh4 boards
and device
  hw/sparc/Makefile.objs: CONFIG_* for sun4m and leon3 created
  hw/lm32/Makefile.objs: Conditionally build lm32 and milkmyst
  hw/xtensa/Makefile.objs: Build xtensa_sim and xtensa_fpga
conditionally

 default-configs/alpha-softmmu.mak   |  1 +
 default-configs/arm-softmmu.mak |  9 ++--
 default-configs/cris-softmmu.mak|  1 +
 default-configs/hppa-softmmu.mak|  1 +
 default-configs/i386-softmmu.mak|  7 ++-
 default-configs/m68k-softmmu.mak|  2 +
 default-configs/microblaze-softmmu.mak  |  3 ++
 default-configs/mips-softmmu-common.mak |  5 ++
 default-configs/mips64el-softmmu.mak|  2 +-
 default-configs/moxie-softmmu.mak   |  1 +
 default-configs/nios2-softmmu.mak   |  1 +
 default-configs/or1k-softmmu.mak|  1 +
 default-configs/pci.mak |  4 +-
 default-configs/ppc-softmmu.mak |  8 ++-
 default-configs/ppc64-softmmu.mak   |  1 +
 default-configs/riscv32-softmmu.mak |  9 +++-
 default-configs/riscv64-softmmu.mak |  9 +++-
 default-configs/s390x-softmmu.mak   |  6 ++-
 default-configs/sh4-softmmu.mak |  2 +
 default-configs/sh4eb-softmmu.mak   |  2 +
 default-configs/sparc-softmmu.mak   |  2 +
 default-configs/sparc64-softmmu.mak |  2 +
 default-configs/tricore-softmmu.mak |  1 +
 default-configs/xtensa-softmmu.mak  |  3 ++
 default-configs/xtensaeb-softmmu.mak|  3 ++
 hw/Makefile.objs|  2 +-
 hw/alpha/Makefile.objs  |  2 +-
 hw/arm/Makefile.objs|  3 +-
 hw/cris/Makefile.objs   |  2 +-
 hw/hppa/Makefile.objs   |  2 +-
 hw/i2c/Makefile.objs|  5 +-
 hw/i386/Makefile.objs   |  4 +-
 hw/ide/Makefile.objs|  4 +-
 hw/ide/core.c   | 25 --
 hw/ide/ioport.c | 66 +
 hw/lm32/Makefile.objs   |  4 +-
 hw/m68k/Makefile.objs   |  4 +-
 hw/microblaze/Makefile.objs |  6 +--
 hw/mips/Makefile.objs   |  5 +-
 hw/moxie/Makefile.objs  |  2 +-
 hw/net/Makefile.objs|  4 +-
 hw/nios2/Makefile.objs  |  3 +-
 hw/openrisc/Makefile.objs   |  2 +-
 hw/pci-host/Makefile.objs   | 10 ++--
 hw/ppc/Makefile.objs| 11 +++--
 hw/riscv/Makefile.objs  | 22 -
 hw/s390x/Makefile.objs  |  2 +-
 hw/sh4/Makefile.objs|  4 +-
 hw/sparc/Makefile.objs  |  4 +-
 hw/sparc64/Makefile.objs|  6 +--
 hw/tricore/Makefile.objs   

[Qemu-devel] [PATCH v1 05/27] build: actually use CONFIG_PAM

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

Do not link it unconditionally into all binaries.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Yang Zhong 
Reviewed-by: Thomas Huth 
---
 default-configs/i386-softmmu.mak | 1 +
 hw/pci-host/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 2f919df346..48da9968cc 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -67,3 +67,4 @@ CONFIG_I2C=y
 CONFIG_SEV=$(CONFIG_KVM)
 CONFIG_VTD=y
 CONFIG_AMD_IOMMU=y
+CONFIG_PAM=y
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index 073d5124d1..a9cd3e022d 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -1,4 +1,4 @@
-common-obj-y += pam.o
+common-obj-$(CONFIG_PAM) += pam.o
 
 # PPC devices
 common-obj-$(CONFIG_PREP_PCI) += prep.o
-- 
2.17.1




[Qemu-devel] [PATCH v1 01/27] arm: disable CONFIG_SERIAL_ISA

2019-01-30 Thread Yang Zhong
From: Paolo Bonzini 

ARM should not have an ISA bus, this device should not be enabled.
Kconfig allows to clean up the dependencies and remove CONFIG_ISA_BUS=y
from ARM, and then catches a contradiction between the hardcoded
CONFIG_SERIAL_ISA=y and CONFIG_ISA_BUS=n.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 1 -
 1 file changed, 1 deletion(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 2420491aac..3c9351f029 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -6,7 +6,6 @@ CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
-CONFIG_SERIAL_ISA=y
 CONFIG_PTIMER=y
 CONFIG_SD=y
 CONFIG_MAX7310=y
-- 
2.17.1




[Qemu-devel] [PATCH v3 8/8] acpi: rewrite the _FIT method to use it in _HMA method

2019-01-30 Thread Tao Xu
Per Igor's comment, rewrite NFIT code to build _HMA method.

We rewirte the function nvdimm_build_common_dsm(Aml *dev) and
nvdimm_build_fit(Aml *dev) in hw/acpi/nvdimm.c so that we can use
method_number as input to decide to generate _FIT or _HMA method.

Reviewed-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 hw/acpi/hmat.c  | 208 +
 hw/acpi/hmat.h  |   1 -
 hw/acpi/nvdimm.c| 389 ++--
 hw/i386/acpi-build.c|   2 +-
 include/hw/mem/nvdimm.h |  11 ++
 5 files changed, 270 insertions(+), 341 deletions(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index d802e1cce1..37ece80101 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -100,10 +100,10 @@ static void classify_proximity_domains(void)
 
 static void hmat_build_hma(GArray *hma, PCMachineState *pcms)
 {
-/*
- * The Proximity Domain of System Physical Address ranges defined
- * in the HMAT, NFIT and SRAT tables shall match each other.
- */
+/*
+ * The Proximity Domain of System Physical Address ranges defined
+ * in the HMAT, NFIT and SRAT tables shall match each other.
+ */
 
 GSList *device_list = NULL;
 AcpiHmatLBInfo *hmat_lb;
@@ -386,112 +386,6 @@ static void hmat_build_hma_buffer(PCMachineState *pcms)
 hma_buf->dirty = true;
 }
 
-static void hmat_build_common_aml(Aml *dev)
-{
-Aml *method, *ifctx, *hmam_mem;
-Aml *unsupport;
-Aml *pckg, *pckg_index, *pckg_buf, *field;
-Aml *hmam_out_buf, *hmam_out_buf_size;
-uint8_t byte_list[1];
-
-method = aml_method(HMA_COMMON_METHOD, 1, AML_SERIALIZED);
-hmam_mem = aml_local(6);
-hmam_out_buf = aml_local(7);
-
-aml_append(method, aml_store(aml_name(HMAM_ACPI_MEM_ADDR), hmam_mem));
-
-/* map _HMA memory and IO into ACPI namespace. */
-aml_append(method, aml_operation_region(HMAM_IOPORT, AML_SYSTEM_IO,
-   aml_int(HMAM_ACPI_IO_BASE), HMAM_ACPI_IO_LEN));
-aml_append(method, aml_operation_region(HMAM_MEMORY,
-   AML_SYSTEM_MEMORY, hmam_mem, HMAM_MEMORY_SIZE));
-
-/*
- * _HMAC notifier:
- * HMAM_NOTIFY: write the address of DSM memory and notify QEMU to
- *emulate the access.
- *
- * It is the IO port so that accessing them will cause VM-exit, the
- * control will be transferred to QEMU.
- */
-field = aml_field(HMAM_IOPORT, AML_DWORD_ACC, AML_NOLOCK,
-  AML_PRESERVE);
-aml_append(field, aml_named_field(HMAM_NOTIFY,
-   sizeof(uint32_t) * BITS_PER_BYTE));
-aml_append(method, field);
-
-/*
- * _HMAC input:
- * HMAM_OFFSET: store the current offset of _HMA buffer.
- *
- * They are RAM mapping on host so that these accesses never cause VMExit.
- */
-field = aml_field(HMAM_MEMORY, AML_DWORD_ACC, AML_NOLOCK,
-  AML_PRESERVE);
-aml_append(field, aml_named_field(HMAM_OFFSET,
-   sizeof(typeof_field(HmatHmamIn, offset)) * BITS_PER_BYTE));
-aml_append(method, field);
-
-/*
- * _HMAC output:
- * HMAM_OUT_BUF_SIZE: the size of the buffer filled by QEMU.
- * HMAM_OUT_BUF: the buffer QEMU uses to store the result.
- *
- * Since the page is reused by both input and out, the input data
- * will be lost after storing new result into ODAT so we should fetch
- * all the input data before writing the result.
- */
-field = aml_field(HMAM_MEMORY, AML_DWORD_ACC, AML_NOLOCK,
-  AML_PRESERVE);
-aml_append(field, aml_named_field(HMAM_OUT_BUF_SIZE,
-   sizeof(typeof_field(HmatHmamOut, len)) * BITS_PER_BYTE));
-aml_append(field, aml_named_field(HMAM_OUT_BUF,
-   (sizeof(HmatHmamOut) - sizeof(uint32_t)) * BITS_PER_BYTE));
-aml_append(method, field);
-
-/*
- * do not support any method if HMA memory address has not been
- * patched.
- */
-unsupport = aml_if(aml_equal(hmam_mem, aml_int(0x0)));
-byte_list[0] = HMAM_RET_STATUS_UNSUPPORT;
-aml_append(unsupport, aml_return(aml_buffer(1, byte_list)));
-aml_append(method, unsupport);
-
-/* The parameter (Arg0) of _HMAC is a package which contains a buffer. */
-pckg = aml_arg(0);
-ifctx = aml_if(aml_and(aml_equal(aml_object_type(pckg),
-   aml_int(4 /* Package */)) /* It is a Package? */,
-   aml_equal(aml_sizeof(pckg), aml_int(1)) /* 1 element */,
-   NULL));
-
-pckg_index = aml_local(2);
-pckg_buf = aml_local(3);
-aml_append(ifctx, aml_store(aml_index(pckg, aml_int(0)), pckg_index));
-aml_append(ifctx, aml_store(aml_derefof(pckg_index), pckg_buf));
-aml_append(ifctx, aml_store(pckg_buf, aml_name(HMAM_OFFSET)));
-aml_append(method, ifctx);
-
-/*
- * tell QEMU about the real address of HMA memory, then QEMU
- * gets the control and fills the result in _HMAC memory.
- */
-aml_append(method, aml_store(hmam_mem, aml_name(HMAM_NOTIFY)));
-
-

[Qemu-devel] [PATCH v3 1/8] hmat acpi: Build Memory Subsystem Address Range Structure(s) in ACPI HMAT

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

HMAT is defined in ACPI 6.2: 5.2.27 Heterogeneous Memory Attribute Table (HMAT).
The specification references below link:
http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf

It describes the memory attributes, such as memory side cache
attributes and bandwidth and latency details, related to the
System Physical Address (SPA) Memory Ranges. The software is
expected to use this information as hint for optimization.

This structure describes the System Physical Address(SPA) range
occupied by memory subsystem and its associativity with processor
proximity domain as well as hint for memory usage.

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 default-configs/i386-softmmu.mak |   1 +
 hw/acpi/Makefile.objs|   1 +
 hw/acpi/hmat.c   | 134 +++
 hw/acpi/hmat.h   |  52 
 hw/i386/acpi-build.c | 123 +---
 hw/i386/acpi-build.h |  10 +++
 include/sysemu/numa.h|   2 +
 numa.c   |   6 ++
 8 files changed, 284 insertions(+), 45 deletions(-)
 create mode 100644 hw/acpi/hmat.c
 create mode 100644 hw/acpi/hmat.h

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 64c998c4c8..3b77640f9d 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -67,3 +67,4 @@ CONFIG_I2C=y
 CONFIG_SEV=$(CONFIG_KVM)
 CONFIG_VTD=y
 CONFIG_AMD_IOMMU=y
+CONFIG_ACPI_HMAT=y
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 2d46e3789a..932ba42d13 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -6,6 +6,7 @@ common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
 common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
+common-obj-$(CONFIG_ACPI_HMAT) += hmat.o
 common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
 
 common-obj-y += acpi_interface.o
diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
new file mode 100644
index 00..7e0fc0a9ae
--- /dev/null
+++ b/hw/acpi/hmat.c
@@ -0,0 +1,134 @@
+/*
+ * HMAT ACPI Implementation
+ *
+ * Copyright(C) 2018 Intel Corporation.
+ *
+ * Author:
+ *  Liu jingqi 
+ *
+ * HMAT is defined in ACPI 6.2.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see 
+ */
+
+#include "qemu/osdep.h"
+#include "sysemu/numa.h"
+#include "hw/i386/pc.h"
+#include "hw/i386/acpi-build.h"
+#include "hw/acpi/hmat.h"
+#include "hw/nvram/fw_cfg.h"
+
+/* Build Memory Subsystem Address Range Structure */
+static void build_hmat_spa(GArray *table_data,
+uint64_t base, uint64_t length, int node)
+{
+uint16_t flags = 0;
+
+if (numa_info[node].is_initiator) {
+flags |= HMAT_SPA_PROC_VALID;
+}
+if (numa_info[node].is_target) {
+flags |= HMAT_SPA_MEM_VALID;
+}
+
+/* Memory Subsystem Address Range Structure */
+/* Type */
+build_append_int_noprefix(table_data, 0, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, 40, 4);
+/* Flags */
+build_append_int_noprefix(table_data, flags, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Process Proximity Domain */
+build_append_int_noprefix(table_data, node, 4);
+/* Memory Proximity Domain */
+build_append_int_noprefix(table_data, node, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+/* System Physical Address Range Base */
+build_append_int_noprefix(table_data, base, 8);
+/* System Physical Address Range Length */
+build_append_int_noprefix(table_data, length, 8);
+}
+
+static int pc_dimm_device_list(Object *obj, void *opaque)
+{
+GSList **list = opaque;
+
+if (object_dynamic_cast(obj, TYPE_PC_DIMM)) {
+*list = g_slist_append(*list, DEVICE(obj));
+}
+
+object_child_foreach(obj, pc_dimm_device_list, opaque);
+return 0;
+}
+
+/*
+ * The Proximity Domain of System Physical Address ranges defined
+ * in the HMAT, NFIT and SRAT tables shall match each other.
+ */
+static void hmat_build_spa(GArray *table_data, PCMachineState *pcms)
+{
+GSList *device_list = NULL;
+uint64_t mem_base, mem_len;
+int i;
+
+if 

[Qemu-devel] [PATCH v3 4/8] Extend the command-line to provide memory latency and bandwidth information

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

Add -numa hmat-lb option to provide System Locality Latency and
Bandwidth Information. These memory attributes help to build
System Locality Latency and Bandwidth Information Structure(s)
in ACPI Heterogeneous Memory Attribute Table (HMAT).

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 numa.c  | 124 
 qapi/misc.json  |  94 +++-
 qemu-options.hx |  28 ++-
 3 files changed, 243 insertions(+), 3 deletions(-)

diff --git a/numa.c b/numa.c
index 9ee4f6f258..97b77356ad 100644
--- a/numa.c
+++ b/numa.c
@@ -40,6 +40,7 @@
 #include "qemu/option.h"
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
+#include "hw/acpi/hmat.h"
 
 QemuOptsList qemu_numa_opts = {
 .name = "numa",
@@ -180,6 +181,123 @@ static void parse_numa_distance(NumaDistOptions *dist, 
Error **errp)
 have_numa_distance = true;
 }
 
+static void parse_numa_hmat_lb(MachineState *ms, NumaHmatLBOptions *node,
+   Error **errp)
+{
+struct numa_hmat_lb_info *hmat_lb = 0;
+
+if (node->data_type <= HMATLB_DATA_TYPE_WRITE_LATENCY) {
+if (!node->has_latency) {
+error_setg(errp, "Please specify the latency.");
+return;
+}
+if (node->has_bandwidth) {
+error_setg(errp, "Please do not specify the bandwidth "
+   "since the data type is latency.");
+return;
+}
+if (node->has_base_bw) {
+error_setg(errp, "Please do not specify the base-bw "
+   "since the data type is latency.");
+return;
+}
+}
+
+if (node->data_type >= HMATLB_DATA_TYPE_ACCESS_BANDWIDTH) {
+if (!node->has_bandwidth) {
+error_setg(errp, "Please specify the bandwidth.");
+return;
+}
+if (node->has_latency) {
+error_setg(errp, "Please do not specify the latency "
+   "since the data type is bandwidth.");
+return;
+}
+if (node->has_base_lat) {
+error_setg(errp, "Please do not specify the base-lat "
+   "since the data type is bandwidth.");
+return;
+}
+}
+
+if (node->initiator >= nb_numa_nodes) {
+error_setg(errp, "Invalid initiator=%"
+   PRIu16 ", it should be less than %d.",
+   node->initiator, nb_numa_nodes);
+return;
+}
+if (!numa_info[node->initiator].is_initiator) {
+error_setg(errp, "Invalid initiator=%"
+   PRIu16 ", it isn't an initiator proximity domain.",
+   node->initiator);
+return;
+}
+
+if (node->target >= nb_numa_nodes) {
+error_setg(errp, "Invalid initiator=%"
+   PRIu16 ", it should be less than %d.",
+   node->target, nb_numa_nodes);
+return;
+}
+if (!numa_info[node->target].is_target) {
+error_setg(errp, "Invalid target=%"
+   PRIu16 ", it isn't a target proximity domain.",
+   node->target);
+return;
+}
+
+if (node->has_latency) {
+hmat_lb = hmat_lb_info[node->hierarchy][node->data_type];
+if (!hmat_lb) {
+hmat_lb = g_malloc0(sizeof(*hmat_lb));
+hmat_lb_info[node->hierarchy][node->data_type] = hmat_lb;
+} else if (hmat_lb->latency[node->initiator][node->target]) {
+error_setg(errp, "Duplicate configuration of the latency for "
+   "initiator=%" PRIu16 " and target=%" PRIu16 ".",
+   node->initiator, node->target);
+return;
+}
+
+/* Only the first time of setting the base unit is valid. */
+if ((hmat_lb->base_lat == 0) && (node->has_base_lat)) {
+hmat_lb->base_lat = node->base_lat;
+}
+
+hmat_lb->latency[node->initiator][node->target] = node->latency;
+}
+
+if (node->has_bandwidth) {
+hmat_lb = hmat_lb_info[node->hierarchy][node->data_type];
+
+if (!hmat_lb) {
+hmat_lb = g_malloc0(sizeof(*hmat_lb));
+hmat_lb_info[node->hierarchy][node->data_type] = hmat_lb;
+} else if (hmat_lb->bandwidth[node->initiator][node->target]) {
+error_setg(errp, "Duplicate configuration of the bandwidth for "
+   "initiator=%" PRIu16 " and target=%" PRIu16 ".",
+   node->initiator, node->target);
+return;
+}
+
+/* Only the first time of setting the base unit is valid. */
+if (hmat_lb->base_bw == 0) {
+if (!node->has_base_bw) {
+error_setg(errp, "Please provide the base-bw!");
+return;
+} else {
+hmat_lb->base_bw = node->base_bw;
+}
+}
+
+

[Qemu-devel] [PATCH v3 7/8] hmat acpi: move some function inside of the caller

2019-01-30 Thread Tao Xu
Per Igor comments, these function is used only once,
move its body inside of the caller

Reviewed-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 hw/acpi/hmat.c | 93 --
 1 file changed, 37 insertions(+), 56 deletions(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 93c72ab14e..d802e1cce1 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -84,22 +84,41 @@ static int pc_dimm_device_list(Object *obj, void *opaque)
 return 0;
 }
 
+static void classify_proximity_domains(void)
+{
+int node;
+
+for (node = 0; node < nb_numa_nodes; node++) {
+if (numa_info[node].is_initiator) {
+initiator_pxm[num_initiator++] = node;
+}
+if (numa_info[node].is_target) {
+target_pxm[num_target++] = node;
+}
+}
+}
+
+static void hmat_build_hma(GArray *hma, PCMachineState *pcms)
+{
 /*
  * The Proximity Domain of System Physical Address ranges defined
  * in the HMAT, NFIT and SRAT tables shall match each other.
  */
-static void hmat_build_spa(GArray *table_data, PCMachineState *pcms)
-{
+
 GSList *device_list = NULL;
+AcpiHmatLBInfo *hmat_lb;
+AcpiHmatCacheInfo *hmat_cache;
+struct numa_hmat_lb_info *numa_hmat_lb;
+struct numa_hmat_cache_info *numa_hmat_cache;
 uint64_t mem_base, mem_len;
-int i;
+int i, j, hrchy, type, level;
 
 if (pcms->numa_nodes && !mem_ranges_number) {
 build_mem_ranges(pcms);
 }
 
 for (i = 0; i < mem_ranges_number; i++) {
-hmat_build_spa_info(table_data, mem_ranges[i].base,
+build_hmat_spa(hma, mem_ranges[i].base,
 mem_ranges[i].length, mem_ranges[i].node);
 }
 
@@ -113,30 +132,10 @@ static void hmat_build_spa(GArray *table_data, 
PCMachineState *pcms)
 mem_len = object_property_get_uint(OBJECT(dimm), PC_DIMM_SIZE_PROP,
NULL);
 i = object_property_get_uint(OBJECT(dimm), PC_DIMM_NODE_PROP, NULL);
-hmat_build_spa_info(table_data, mem_base, mem_len, i);
-}
-}
-
-static void classify_proximity_domains(void)
-{
-int node;
-
-for (node = 0; node < nb_numa_nodes; node++) {
-if (numa_info[node].is_initiator) {
-initiator_pxm[num_initiator++] = node;
-}
-if (numa_info[node].is_target) {
-target_pxm[num_target++] = node;
-}
+build_hmat_spa(hma, mem_base, mem_len, i);
 }
-}
-
-static void hmat_build_lb(GArray *table_data)
-{
-AcpiHmatLBInfo *hmat_lb;
-struct numa_hmat_lb_info *numa_hmat_lb;
-int i, j, hrchy, type;
 
+/* Build HMAT System Locality Latency and Bandwidth Information. */
 if (!num_initiator && !num_target) {
 classify_proximity_domains();
 }
@@ -154,8 +153,8 @@ static void hmat_build_lb(GArray *table_data)
 uint32_t size;
 uint8_t m, n;
 
-start = table_data->len;
-hmat_lb = acpi_data_push(table_data, sizeof(*hmat_lb));
+start = hma->len;
+hmat_lb = acpi_data_push(hma, sizeof(*hmat_lb));
 
 hmat_lb->type  = cpu_to_le16(ACPI_HMAT_LB_INFO);
 hmat_lb->flags = numa_hmat_lb->hierarchy;
@@ -174,19 +173,19 @@ static void hmat_build_lb(GArray *table_data)
 
 /* the initiator proximity domain list */
 for (i = 0; i < num_initiator; i++) {
-list_entry = acpi_data_push(table_data, sizeof(uint32_t));
+list_entry = acpi_data_push(hma, sizeof(uint32_t));
 *list_entry = cpu_to_le32(initiator_pxm[i]);
 }
 
 /* the target proximity domain list */
 for (i = 0; i < num_target; i++) {
-list_entry = acpi_data_push(table_data, sizeof(uint32_t));
+list_entry = acpi_data_push(hma, sizeof(uint32_t));
 *list_entry = cpu_to_le32(target_pxm[i]);
 }
 
 /* latency or bandwidth entries */
 size = sizeof(uint16_t) * num_initiator * num_target;
-entry_start = acpi_data_push(table_data, size);
+entry_start = acpi_data_push(hma, size);
 
 for (i = 0; i < num_initiator; i++) {
 m = initiator_pxm[i];
@@ -200,26 +199,20 @@ static void hmat_build_lb(GArray *table_data)
 }
 }
 }
-hmat_lb = (AcpiHmatLBInfo *)(table_data->data + start);
-hmat_lb->length = cpu_to_le16(table_data->len - start);
+hmat_lb = (AcpiHmatLBInfo *)(hma->data + start);
+hmat_lb->length = cpu_to_le16(hma->len - start);
 }
 }
 }
-}
-
-static void hmat_build_cache(GArray *table_data)
-{
-AcpiHmatCacheInfo *hmat_cache;
-struct numa_hmat_cache_info *numa_hmat_cache;
-int i, 

[Qemu-devel] [PATCH v3 5/8] numa: Extend the command-line to provide memory side cache information

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

Add -numa hmat-cache option to provide Memory Side Cache Information.
These memory attributes help to build Memory Side Cache Information
Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 numa.c | 72 ++
 qapi/misc.json | 72 --
 2 files changed, 142 insertions(+), 2 deletions(-)

diff --git a/numa.c b/numa.c
index 97b77356ad..c2f4049689 100644
--- a/numa.c
+++ b/numa.c
@@ -298,6 +298,72 @@ static void parse_numa_hmat_lb(MachineState *ms, 
NumaHmatLBOptions *node,
 }
 }
 
+static void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
+Error **errp)
+{
+struct numa_hmat_cache_info *hmat_cache;
+
+if (node->node_id >= nb_numa_nodes) {
+error_setg(errp, "Invalid node-id=%" PRIu32
+   ", it should be less than %d.",
+   node->node_id, nb_numa_nodes);
+return;
+}
+if (!numa_info[node->node_id].is_target) {
+error_setg(errp, "Invalid node-id=%" PRIu32
+   ", it isn't a target proximity domain.",
+   node->node_id);
+return;
+}
+
+if (node->total > MAX_HMAT_CACHE_LEVEL) {
+error_setg(errp, "Invalid total=%" PRIu8
+   ", it should be less than or equal to %d.",
+   node->total, MAX_HMAT_CACHE_LEVEL);
+return;
+}
+if (node->level > node->total) {
+error_setg(errp, "Invalid level=%" PRIu8
+   ", it should be less than or equal to"
+   " total=%" PRIu8 ".",
+   node->level, node->total);
+return;
+}
+if (hmat_cache_info[node->node_id][node->level]) {
+error_setg(errp, "Duplicate configuration of the side cache for "
+   "node-id=%" PRIu32 " and level=%" PRIu8 ".",
+   node->node_id, node->level);
+return;
+}
+
+if ((node->level > 1) &&
+hmat_cache_info[node->node_id][node->level - 1] &&
+(node->size >=
+hmat_cache_info[node->node_id][node->level - 1]->size)) {
+error_setg(errp, "Invalid size=0x%" PRIx64
+   ", the size of level=%" PRIu8
+   " should be less than the size(0x%" PRIx64
+   ") of level=%" PRIu8 ".",
+   node->size, node->level,
+   hmat_cache_info[node->node_id][node->level - 1]->size,
+   node->level - 1);
+return;
+}
+
+hmat_cache = g_malloc0(sizeof(*hmat_cache));
+
+hmat_cache->mem_proximity = node->node_id;
+hmat_cache->size = node->size;
+hmat_cache->total_levels = node->total;
+hmat_cache->level = node->level;
+hmat_cache->associativity = node->assoc;
+hmat_cache->write_policy = node->policy;
+hmat_cache->line_size = node->line;
+hmat_cache->num_smbios_handles = 0;
+
+hmat_cache_info[node->node_id][node->level] = hmat_cache;
+}
+
 static
 void set_numa_options(MachineState *ms, NumaOptions *object, Error **errp)
 {
@@ -337,6 +403,12 @@ void set_numa_options(MachineState *ms, NumaOptions 
*object, Error **errp)
 goto end;
 }
 break;
+case NUMA_OPTIONS_TYPE_HMAT_CACHE:
+parse_numa_hmat_cache(ms, >u.hmat_cache, );
+if (err) {
+goto end;
+}
+break;
 default:
 abort();
 }
diff --git a/qapi/misc.json b/qapi/misc.json
index 10ba90bb39..58adca5ff1 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -2784,10 +2784,12 @@
 #
 # @hmat-lb: memory latency and bandwidth information (Since: 4.0)
 #
+# @hmat-cache: memory side cache information (Since: 4.0)
+#
 # Since: 2.1
 ##
 { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
+   'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] }
 
 ##
 # @NumaOptions:
@@ -2803,7 +2805,8 @@
 'node': 'NumaNodeOptions',
 'dist': 'NumaDistOptions',
 'cpu': 'NumaCpuOptions',
-'hmat-lb': 'NumaHmatLBOptions' }}
+'hmat-lb': 'NumaHmatLBOptions',
+'hmat-cache': 'NumaHmatCacheOptions' }}
 
 ##
 # @NumaNodeOptions:
@@ -2953,6 +2956,71 @@
'*latency': 'uint16',
'*bandwidth': 'uint16' }}
 
+##
+# @HmatCacheAssociativity:
+#
+# Cache associativity in the Memory Side Cache
+# Information Structure of HMAT
+#
+# @none: None
+#
+# @direct: Direct Mapped
+#
+# @complex: Complex Cache Indexing (implementation specific)
+#
+# Since: 4.0
+##
+{ 'enum': 'HmatCacheAssociativity',
+  'data': [ 'none', 'direct', 'complex' ] }
+
+##
+# @HmatCacheWritePolicy:
+#
+# Cache write policy in the Memory Side Cache
+# Information Structure of HMAT
+#
+# @none: None
+#
+# @write-back: Write Back (WB)
+#
+# @write-through: Write Through (WT)
+#
+# Since: 4.0
+##
+{ 'enum': 'HmatCacheWritePolicy',
+  'data': [ 'none', 'write-back', 

[Qemu-devel] [PATCH v3 3/8] hmat acpi: Build Memory Side Cache Information Structure(s) in ACPI HMAT

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

This structure describes memory side cache information for memory
proximity domains if the memory side cache is present and the
physical device(SMBIOS handle) forms the memory side cache.
The software could use this information to effectively place
the data in memory to maximize the performance of the system
memory that use the memory side cache.

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 hw/acpi/hmat.c | 56 ++
 hw/acpi/hmat.h | 47 ++
 2 files changed, 103 insertions(+)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index e3deeaa36b..912ab4f94d 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -30,6 +30,8 @@
 #include "hw/nvram/fw_cfg.h"
 
 struct numa_hmat_lb_info *hmat_lb_info[HMAT_LB_LEVELS][HMAT_LB_TYPES] = {0};
+struct numa_hmat_cache_info
+   *hmat_cache_info[MAX_NODES][MAX_HMAT_CACHE_LEVEL + 1] = {0};
 
 static uint32_t initiator_pxm[MAX_NODES], target_pxm[MAX_NODES];
 static uint32_t num_initiator, num_target;
@@ -205,6 +207,57 @@ static void hmat_build_lb(GArray *table_data)
 }
 }
 
+static void hmat_build_cache(GArray *table_data)
+{
+AcpiHmatCacheInfo *hmat_cache;
+struct numa_hmat_cache_info *numa_hmat_cache;
+int i, level;
+
+for (i = 0; i < nb_numa_nodes; i++) {
+for (level = 0; level <= MAX_HMAT_CACHE_LEVEL; level++) {
+numa_hmat_cache = hmat_cache_info[i][level];
+if (numa_hmat_cache) {
+uint64_t start = table_data->len;
+
+hmat_cache = acpi_data_push(table_data, sizeof(*hmat_cache));
+hmat_cache->length = cpu_to_le32(sizeof(*hmat_cache));
+hmat_cache->type = cpu_to_le16(ACPI_HMAT_CACHE_INFO);
+hmat_cache->mem_proximity =
+cpu_to_le32(numa_hmat_cache->mem_proximity);
+hmat_cache->cache_size  = cpu_to_le64(numa_hmat_cache->size);
+hmat_cache->cache_attr  = HMAT_CACHE_TOTAL_LEVEL(
+  numa_hmat_cache->total_levels);
+hmat_cache->cache_attr |= HMAT_CACHE_CURRENT_LEVEL(
+  numa_hmat_cache->level);
+hmat_cache->cache_attr |= HMAT_CACHE_ASSOC(
+  numa_hmat_cache->associativity);
+hmat_cache->cache_attr |= HMAT_CACHE_WRITE_POLICY(
+  numa_hmat_cache->write_policy);
+hmat_cache->cache_attr |= HMAT_CACHE_LINE_SIZE(
+  numa_hmat_cache->line_size);
+hmat_cache->cache_attr = cpu_to_le32(hmat_cache->cache_attr);
+
+if (numa_hmat_cache->num_smbios_handles != 0) {
+uint16_t *smbios_handles;
+int size;
+
+size = hmat_cache->num_smbios_handles * sizeof(uint16_t);
+smbios_handles = acpi_data_push(table_data, size);
+
+hmat_cache = (AcpiHmatCacheInfo *)
+ (table_data->data + start);
+hmat_cache->length += size;
+
+/* TBD: set smbios handles */
+memset(smbios_handles, 0, size);
+}
+hmat_cache->num_smbios_handles =
+cpu_to_le16(numa_hmat_cache->num_smbios_handles);
+}
+}
+}
+}
+
 static void hmat_build_hma(GArray *hma, PCMachineState *pcms)
 {
 /* Build HMAT Memory Subsystem Address Range. */
@@ -212,6 +265,9 @@ static void hmat_build_hma(GArray *hma, PCMachineState 
*pcms)
 
 /* Build HMAT System Locality Latency and Bandwidth Information. */
 hmat_build_lb(hma);
+
+/* Build HMAT Memory Side Cache Information. */
+hmat_build_cache(hma);
 }
 
 void hmat_build_acpi(GArray *table_data, BIOSLinker *linker,
diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
index ffef9f6243..3e32741192 100644
--- a/hw/acpi/hmat.h
+++ b/hw/acpi/hmat.h
@@ -33,6 +33,15 @@
 
 #define ACPI_HMAT_SPA   0
 #define ACPI_HMAT_LB_INFO   1
+#define ACPI_HMAT_CACHE_INFO2
+
+#define MAX_HMAT_CACHE_LEVEL3
+
+#define HMAT_CACHE_TOTAL_LEVEL(level)  (level & 0xF)
+#define HMAT_CACHE_CURRENT_LEVEL(level)((level & 0xF) << 4)
+#define HMAT_CACHE_ASSOC(assoc)((assoc & 0xF) << 8)
+#define HMAT_CACHE_WRITE_POLICY(policy)((policy & 0xF) << 12)
+#define HMAT_CACHE_LINE_SIZE(size) ((size & 0x) << 16)
 
 /* ACPI HMAT sub-structure header */
 #define ACPI_HMAT_SUB_HEADER_DEF\
@@ -81,6 +90,17 @@ struct AcpiHmatLBInfo {
 } QEMU_PACKED;
 typedef struct AcpiHmatLBInfo AcpiHmatLBInfo;
 
+struct AcpiHmatCacheInfo {
+ACPI_HMAT_SUB_HEADER_DEF
+uint32_tmem_proximity;
+uint32_treserved;
+uint64_tcache_size;
+uint32_tcache_attr;
+uint16_treserved2;
+uint16_t

[Qemu-devel] [PATCH v3 6/8] hmat acpi: Implement _HMA method to update HMAT at runtime

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

OSPM evaluates HMAT only during system initialization.
Any changes to the HMAT state at runtime or information
regarding HMAT for hot plug are communicated using _HMA method.

_HMA is an optional object that enables the platform to provide
the OS with updated Heterogeneous Memory Attributes information
at runtime. _HMA provides OSPM with the latest HMAT in entirety
overriding existing HMAT.

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 hw/acpi/hmat.c   | 355 +++
 hw/acpi/hmat.h   |  71 +
 hw/i386/acpi-build.c |   4 +-
 hw/i386/pc.c |   2 +
 hw/i386/pc_piix.c|   3 +
 hw/i386/pc_q35.c |   3 +
 include/hw/i386/pc.h |   2 +
 7 files changed, 439 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 912ab4f94d..93c72ab14e 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -270,6 +270,267 @@ static void hmat_build_hma(GArray *hma, PCMachineState 
*pcms)
 hmat_build_cache(hma);
 }
 
+static uint64_t
+hmat_hma_method_read(void *opaque, hwaddr addr, unsigned size)
+{
+printf("BUG: we never read _HMA IO Port.\n");
+return 0;
+}
+
+/* _HMA Method: read HMA data. */
+static void hmat_handle_hma_method(AcpiHmaState *state,
+   HmatHmamIn *in, hwaddr hmam_mem_addr)
+{
+HmatHmaBuffer *hma_buf = >hma_buf;
+HmatHmamOut *read_hma_out;
+GArray *hma;
+uint32_t read_len = 0, ret_status;
+int size;
+
+le32_to_cpus(>offset);
+
+hma = hma_buf->hma;
+if (in->offset > hma->len) {
+ret_status = HMAM_RET_STATUS_INVALID;
+goto exit;
+}
+
+   /* It is the first time to read HMA. */
+if (!in->offset) {
+hma_buf->dirty = false;
+} else if (hma_buf->dirty) { /* HMA has been changed during Reading HMA. */
+ret_status = HMAM_RET_STATUS_HMA_CHANGED;
+goto exit;
+}
+
+ret_status = HMAM_RET_STATUS_SUCCESS;
+read_len = MIN(hma->len - in->offset,
+   HMAM_MEMORY_SIZE - 2 * sizeof(uint32_t));
+exit:
+size = sizeof(HmatHmamOut) + read_len;
+read_hma_out = g_malloc(size);
+
+read_hma_out->len = cpu_to_le32(size);
+read_hma_out->ret_status = cpu_to_le32(ret_status);
+memcpy(read_hma_out->data, hma->data + in->offset, read_len);
+
+cpu_physical_memory_write(hmam_mem_addr, read_hma_out, size);
+
+g_free(read_hma_out);
+}
+
+static void
+hmat_hma_method_write(void *opaque, hwaddr addr, uint64_t val, unsigned size)
+{
+AcpiHmaState *state = opaque;
+hwaddr hmam_mem_addr = val;
+HmatHmamIn *in;
+
+in = g_new(HmatHmamIn, 1);
+cpu_physical_memory_read(hmam_mem_addr, in, sizeof(*in));
+
+hmat_handle_hma_method(state, in, hmam_mem_addr);
+}
+
+static const MemoryRegionOps hmat_hma_method_ops = {
+.read = hmat_hma_method_read,
+.write = hmat_hma_method_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
+};
+
+static void hmat_init_hma_buffer(HmatHmaBuffer *hma_buf)
+{
+hma_buf->hma = g_array_new(false, true /* clear */, 1);
+}
+
+static uint8_t hmat_acpi_table_checksum(uint8_t *buffer, uint32_t length)
+{
+uint8_t sum = 0;
+uint8_t *end = buffer + length;
+
+while (buffer < end) {
+sum = (uint8_t) (sum + *(buffer++));
+}
+return (uint8_t)(0 - sum);
+}
+
+static void hmat_build_header(AcpiTableHeader *h,
+ const char *sig, int len, uint8_t rev,
+ const char *oem_id, const char *oem_table_id)
+{
+memcpy(>signature, sig, 4);
+h->length = cpu_to_le32(len);
+h->revision = rev;
+
+if (oem_id) {
+strncpy((char *)h->oem_id, oem_id, sizeof h->oem_id);
+} else {
+memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
+}
+
+if (oem_table_id) {
+strncpy((char *)h->oem_table_id, oem_table_id, 
sizeof(h->oem_table_id));
+} else {
+memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
+memcpy(h->oem_table_id + 4, sig, 4);
+}
+
+h->oem_revision = cpu_to_le32(1);
+memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
+h->asl_compiler_revision = cpu_to_le32(1);
+
+/* Caculate the checksum of acpi table. */
+h->checksum = 0;
+h->checksum = hmat_acpi_table_checksum((uint8_t *)h, len);
+}
+
+static void hmat_build_hma_buffer(PCMachineState *pcms)
+{
+HmatHmaBuffer *hma_buf = &(pcms->acpi_hma_state.hma_buf);
+
+/* Free the old hma buffer before new allocation. */
+g_array_free(hma_buf->hma, true);
+
+hma_buf->hma = g_array_new(false, true /* clear */, 1);
+acpi_data_push(hma_buf->hma, 40);
+
+/* build HMAT in a given buffer. */
+hmat_build_hma(hma_buf->hma, pcms);
+hmat_build_header((void *)hma_buf->hma->data,
+  "HMAT", hma_buf->hma->len, 1, NULL, NULL);
+hma_buf->dirty = true;
+}
+
+static void hmat_build_common_aml(Aml *dev)
+{
+Aml *method, *ifctx, *hmam_mem;
+   

[Qemu-devel] [PATCH v3 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

2019-01-30 Thread Tao Xu
This series of patches will build Heterogeneous Memory Attribute Table (HMAT)
according to the command line. The ACPI HMAT describes the memory attributes,
such as memory side cache attributes and bandwidth and latency details,
related to the System Physical Address (SPA) Memory Ranges.
The software is expected to use this information as hint for optimization.

OSPM evaluates HMAT only during system initialization. Any changes to the HMAT
state at runtime or information regarding HMAT for hot plug are communicated
using the _HMA method.

>From 1 to 6 patches are the former V1 patches. From 7 to 8 patches are the
updates per Igor and Eric's comments.

The V2 patches link:
http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg02276.html
The V1 RESEND patches link:
http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg05368.html

Changelog:
v3:
  Per Eric's comments
- rebase the fixing patch into the jingqi's patches
- update the version tag from 3.10 to 4.0
v2:
  Per Igor and Eric's comments, fix some coding style and small issues:
- update the version number in qapi/misc.json
- including the expansion of the acronym HMAT in qapi/misc.json
- correct spell mistakes in qapi/misc.json and qemu-options.hx
- fix the comment syle in hw/i386/acpi-build.c
and hw/acpi/hmat.h
   - remove some unnecessary head files in hw/acpi/hmat.c
   - use hardcoded numbers from spec to generate
   Memory Subsystem Address Range Structure in hw/acpi/hmat.c
   - drop the struct AcpiHmat and AcpiHmatSpaRange
in hw/acpi/hmat.h
  Per Igor's comment, rewrite NFIT code to build _HMA method.

Liu Jingqi (6):
  hmat acpi: Build Memory Subsystem Address Range Structure(s) in ACPI
HMAT
  hmat acpi: Build System Locality Latency and Bandwidth Information
Structure(s) in ACPI HMAT
  hmat acpi: Build Memory Side Cache Information Structure(s) in ACPI
HMAT
  Extend the command-line to provide memory latency and bandwidth
information
  numa: Extend the command-line to provide memory side cache information
  hmat acpi: Implement _HMA method to update HMAT at runtime

Tao Xu (2):
  hmat acpi: move some function inside of the caller
  acpi: rewrite the _FIT method to use it in _HMA method

 default-configs/i386-softmmu.mak |   1 +
 hw/acpi/Makefile.objs|   1 +
 hw/acpi/hmat.c   | 424 +++
 hw/acpi/hmat.h   | 245 ++
 hw/acpi/nvdimm.c | 389 ++--
 hw/i386/acpi-build.c | 125 +
 hw/i386/acpi-build.h |  10 +
 hw/i386/pc.c |   2 +
 hw/i386/pc_piix.c|   3 +
 hw/i386/pc_q35.c |   3 +
 include/hw/i386/pc.h |   2 +
 include/hw/mem/nvdimm.h  |  11 +
 include/sysemu/numa.h|   2 +
 numa.c   | 202 +++
 qapi/misc.json   | 162 +++-
 qemu-options.hx  |  28 +-
 16 files changed, 1427 insertions(+), 183 deletions(-)
 create mode 100644 hw/acpi/hmat.c
 create mode 100644 hw/acpi/hmat.h

-- 
2.17.1




[Qemu-devel] [PATCH v3 2/8] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s) in ACPI HMAT

2019-01-30 Thread Tao Xu
From: Liu Jingqi 

This structure describes the memory access latency and bandwidth
information from various memory access initiator proximity domains.
The latency and bandwidth numbers represented in this structure
correspond to rated latency and bandwidth for the platform.
The software could use this information as hint for optimization.

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---
 hw/acpi/hmat.c | 98 ++
 hw/acpi/hmat.h | 76 +++
 2 files changed, 174 insertions(+)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 7e0fc0a9ae..e3deeaa36b 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -29,6 +29,11 @@
 #include "hw/acpi/hmat.h"
 #include "hw/nvram/fw_cfg.h"
 
+struct numa_hmat_lb_info *hmat_lb_info[HMAT_LB_LEVELS][HMAT_LB_TYPES] = {0};
+
+static uint32_t initiator_pxm[MAX_NODES], target_pxm[MAX_NODES];
+static uint32_t num_initiator, num_target;
+
 /* Build Memory Subsystem Address Range Structure */
 static void build_hmat_spa(GArray *table_data,
 uint64_t base, uint64_t length, int node)
@@ -110,10 +115,103 @@ static void hmat_build_spa(GArray *table_data, 
PCMachineState *pcms)
 }
 }
 
+static void classify_proximity_domains(void)
+{
+int node;
+
+for (node = 0; node < nb_numa_nodes; node++) {
+if (numa_info[node].is_initiator) {
+initiator_pxm[num_initiator++] = node;
+}
+if (numa_info[node].is_target) {
+target_pxm[num_target++] = node;
+}
+}
+}
+
+static void hmat_build_lb(GArray *table_data)
+{
+AcpiHmatLBInfo *hmat_lb;
+struct numa_hmat_lb_info *numa_hmat_lb;
+int i, j, hrchy, type;
+
+if (!num_initiator && !num_target) {
+classify_proximity_domains();
+}
+
+for (hrchy = HMAT_LB_MEM_MEMORY;
+ hrchy <= HMAT_LB_MEM_CACHE_3RD_LEVEL; hrchy++) {
+for (type = HMAT_LB_DATA_ACCESS_LATENCY;
+ type <= HMAT_LB_DATA_WRITE_BANDWIDTH; type++) {
+numa_hmat_lb = hmat_lb_info[hrchy][type];
+
+if (numa_hmat_lb) {
+uint64_t start;
+uint32_t *list_entry;
+uint16_t *entry, *entry_start;
+uint32_t size;
+uint8_t m, n;
+
+start = table_data->len;
+hmat_lb = acpi_data_push(table_data, sizeof(*hmat_lb));
+
+hmat_lb->type  = cpu_to_le16(ACPI_HMAT_LB_INFO);
+hmat_lb->flags = numa_hmat_lb->hierarchy;
+hmat_lb->data_type = numa_hmat_lb->data_type;
+hmat_lb->num_initiator = cpu_to_le32(num_initiator);
+hmat_lb->num_target= cpu_to_le32(num_target);
+
+if (type <= HMAT_LB_DATA_WRITE_LATENCY) {
+hmat_lb->base_unit = cpu_to_le32(numa_hmat_lb->base_lat);
+} else {
+hmat_lb->base_unit = cpu_to_le32(numa_hmat_lb->base_bw);
+}
+if (!hmat_lb->base_unit) {
+hmat_lb->base_unit = cpu_to_le32(1);
+}
+
+/* the initiator proximity domain list */
+for (i = 0; i < num_initiator; i++) {
+list_entry = acpi_data_push(table_data, sizeof(uint32_t));
+*list_entry = cpu_to_le32(initiator_pxm[i]);
+}
+
+/* the target proximity domain list */
+for (i = 0; i < num_target; i++) {
+list_entry = acpi_data_push(table_data, sizeof(uint32_t));
+*list_entry = cpu_to_le32(target_pxm[i]);
+}
+
+/* latency or bandwidth entries */
+size = sizeof(uint16_t) * num_initiator * num_target;
+entry_start = acpi_data_push(table_data, size);
+
+for (i = 0; i < num_initiator; i++) {
+m = initiator_pxm[i];
+for (j = 0; j < num_target; j++) {
+n = target_pxm[j];
+entry = entry_start + i * num_target + j;
+if (type <= HMAT_LB_DATA_WRITE_LATENCY) {
+*entry = cpu_to_le16(numa_hmat_lb->latency[m][n]);
+} else {
+*entry = 
cpu_to_le16(numa_hmat_lb->bandwidth[m][n]);
+}
+}
+}
+hmat_lb = (AcpiHmatLBInfo *)(table_data->data + start);
+hmat_lb->length = cpu_to_le16(table_data->len - start);
+}
+}
+}
+}
+
 static void hmat_build_hma(GArray *hma, PCMachineState *pcms)
 {
 /* Build HMAT Memory Subsystem Address Range. */
 hmat_build_spa(hma, pcms);
+
+/* Build HMAT System Locality Latency and Bandwidth Information. */
+hmat_build_lb(hma);
 }
 
 void hmat_build_acpi(GArray *table_data, BIOSLinker 

Re: [Qemu-devel] [PR RFC] RISC-V Patches for 3.2, Part 3

2019-01-30 Thread Thomas Huth
On 2019-01-30 20:01, Palmer Dabbelt wrote:
> On Wed, 30 Jan 2019 09:45:33 PST (-0800), ebl...@redhat.com wrote:
>> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>>> The following changes since commit
>>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>>>
>>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config
>>> struct (2019-01-21 17:20:36 +)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://github.com/palmer-dabbelt/qemu.git
>>> tags/riscv-for-master-3.2-part3
>>>
>>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>>>
>>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
>>> 11:33:38 -0800)
>>>
>>> 
>>> RISC-V Patches for 3.2, Part 3
>>
>> There is no 3.2 release; the next release is named 4.0.  However, if you
>> don't want to bother with sending a v2 pull request just to fix the
>> merge commit message, that's okay with me.
> 
> Ah, sorry.  I think I'm just going to leave it as is, I'll get it right
> next time.

Also note that you used "PR RFC" in the title ... so not sure whether
Peter's scripts will catch this PR as a valid one...

 Thomas




Re: [Qemu-devel] [RFC PATCH 3/5] ppc: Express dependencies of the Mac machines with kconfig

2019-01-30 Thread Thomas Huth
On 2019-01-30 18:13, Mark Cave-Ayland wrote:
> On 30/01/2019 09:43, Thomas Huth wrote:
> 
>> This will make it for example easier if the users want to disable
>> one of the two machines for their builds.
>>
>> Cc: Mark Cave-Ayland 
>> Signed-off-by: Thomas Huth 
>> ---
[...]
>> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
>> index 3ebe30f..f392502 100644
>> --- a/hw/misc/Kconfig
>> +++ b/hw/misc/Kconfig
>> @@ -59,6 +59,14 @@ config MOS6522
>>  
>>  config MACIO
>>  bool
>> +select CUDA
>> +select ESCC
>> +select IDE_MACIO
>> +select MACIO_GPIO
>> +select MAC_DBDMA
>> +select MAC_NVRAM
>> +select MAC_PMU
>> +select MOS6522
> 
> Technically MACIO_GPIO and MAC_PMU are MAC_NEWWORLD only, so we might want to 
> split
> this down further?

I can also change the lines into:

select MACIO_GPIO if MAC_NEWWORLD
select MAC_PMU if MAC_NEWWORLD

>> diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
>> index 809830e..f6b4206 100644
>> --- a/hw/ppc/Kconfig
>> +++ b/hw/ppc/Kconfig
>> @@ -44,9 +44,16 @@ config RS6000_MC
>>  
>>  config MAC_OLDWORLD
>>  bool
>> +select ADB
>> +select GRACKLE_PCI
>> +select HEATHROW_PIC
>> +select MACIO
>>  
>>  config MAC_NEWWORLD
>>  bool
>> +select ADB
>> +select MACIO
>> +select UNIN_PCI
> 
> Also MAC_NEWWORLD has an in-built USB PCI bridge (OHCI) which populates with 
> a USB
> keyboard/mouse rather than ADB when using -M mac99,via=pmu, but I presume USB 
> is
> handled elsewhere?

Yes, in hw/usb/Kconfig we have:

config USB_OHCI
bool
default y if PCI_DEVICES
depends on PCI
select USB

 Thomas



Re: [Qemu-devel] [PATCH] Fix for RSP vCont packet

2019-01-30 Thread Lucien Murray-Pitts via Qemu-devel
The result is that vCont now does not recognise the case where no 
process/thread is provided after the action.

This may not show up with GDB, but using Lauterbach Trace32, and Hexrays IDA 
Pro this issue is immediately seen.
The response is a "$#00" empty packet, showing it is unsupported packet.

This is defined in the RSP document as "An action with no thread-id matches all 
threads."
(https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html#vCont-packet )

Thus the valid vCont packets now are as below, however parsing is still not 
very strict.
  vCont;c/s - Step/Continue all threads
  vCont;c/s:[pX.]Y  - Step/Continue optional process X, thread Y
  vCont;C##/S##:[pX.]Y  - Step/Continue with signal ## on optional process 
X, thread Y
  * If X or Y are -1 then it applies the action to all processes/threads.

Signed-off-by: Lucien Murray-Pitts 
---
 gdbstub.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index bfc7afb509..ce0dde2e24 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1169,6 +1169,7 @@ static int is_query_packet(const char *p, const char 
*query, char separator)
  */
 static int gdb_handle_vcont(GDBState *s, const char *p)
 {
+GDBThreadIdKind vcontThreadType ;
 int res, signal = 0;
 char cur_action;
 char *newstates;
@@ -1218,12 +1219,23 @@ static int gdb_handle_vcont(GDBState *s, const char *p)
 goto out;
 }
 
-if (*p++ != ':') {
+/*
+ * In the case we have vCont;c or vCont;s - action is on all threads
+ * Alternatively vCont;c;s:p1.1 is a possible, but meaningless format,
+ * And in the else the "vCont;c:p1.1;... format is supported.
+ */
+if (*p == '\0' || *p == ';') {
+vcontThreadType = GDB_ALL_THREADS ;
+pid = 1 ;
+tid = 1 ;
+} else if (*p++ == ':') {
+vcontThreadType = read_thread_id(p, , , ) ;
+} else {
 res = -ENOTSUP;
 goto out;
 }
 
-switch (read_thread_id(p, , , )) {
+switch (vcontThreadType) {
 case GDB_READ_THREAD_ERR:
 res = -EINVAL;
 goto out;
-- 
2.17.2




Re: [Qemu-devel] [Qemu-block] [PATCH v3 1/1] drive-mirror: add incremental mode

2019-01-30 Thread Eric Blake
On 1/30/19 10:01 PM, mahaocong wrote:
> From: mahaocong 
> 

You are STILL missing the commit message body, even though I requested
it [1].  Please 'git commit --amend', and paste in the contents that you
are sticking in your 0/1 cover letter that actually describe the details
behind this patch. Also, since you are sending a single patch, you don't
need a 0/1 cover letter (they are mandatory if you send 2 or more
patches in series; but don't add anything when you send just one patch,
although they don't hurt, as long as you do a correct division between
cover letter having information for the reviewer and patch itself having
a self-contained commit message).

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg00122.html

> Signed-off-by: mahaocong 

I previously mentioned [2] that you probably want to use a proper name
(typically more than one word), not a username. While I am not in a
position to argue whether 'mahaocong' is how you sign legal documents,
or what you may use in other open source projects, it is at least
courteous to reply to a reviewer's request when stating that you are
intentionally not going to do something about the request.

[2] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg00407.html

> ---

Here, after the --- marker, is a good place to describe how v3 differs
from v2, to speed up reviewers efforts if they have already looked at
the earlier version, and want to see what you changed in response to
their comments.

Just a UI review on my part (I haven't looked at the code proper, in
part because I'm still waiting for you to fix the commit message problem
- it's tough to justify reviewing in more depth when there are things
from the earlier version that are still not corrected)

> +++ b/qapi/block-core.json
> @@ -1727,6 +1727,11 @@
>  #(all the disk, only the sectors allocated in the topmost image, or
>  #only new I/O).
>  #
> +# @bitmap: the name of user-created-bitmap which is used on incremental mode
> +#  drive-mirror. If user select incremental mode, bitmap should not 
> be
> +#  null, and can not set granularity, because the mirror bitmap 
> should
> +#  have the same granularity with user-created-bitmap.

Missing a '(since 4.0)' tag. The grammar is awkward; maybe:

@bitmap: the name of a pre-existing bitmap to use in incremental mode;
must be present for incremental mode and absent otherwise. In
incremental mode, granularity should not be set, because the bitmap's
granularity is used instead.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v3 1/1] drive-mirror: add incremental mode

2019-01-30 Thread mahaocong
From: mahaocong 

Signed-off-by: mahaocong 
---
 block/mirror.c| 46 ++
 blockdev.c| 37 +++--
 include/block/block_int.h |  3 ++-
 qapi/block-core.json  |  7 ++-
 4 files changed, 77 insertions(+), 16 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index ab59ad77e8..c59aefe9f0 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -50,6 +50,7 @@ typedef struct MirrorBlockJob {
 /* Used to block operations on the drive-mirror-replace target */
 Error *replace_blocker;
 bool is_none_mode;
+BdrvDirtyBitmap *src_bitmap;
 BlockMirrorBackingMode backing_mode;
 MirrorCopyMode copy_mode;
 BlockdevOnError on_source_error, on_target_error;
@@ -814,6 +815,15 @@ static int coroutine_fn mirror_dirty_init(MirrorBlockJob 
*s)
 return 0;
 }
 
+/*
+ * init dirty bitmap by using user bitmap. usr->hbitmap will be copy to
+ * mirror bitmap->hbitmap instead of reuse it.
+ */
+static void coroutine_fn mirror_dirty_init_incremental(MirrorBlockJob *s, 
Error **errp)
+{
+bdrv_merge_dirty_bitmap(s->dirty_bitmap, s->src_bitmap, NULL, errp);
+}
+
 /* Called when going out of the streaming phase to flush the bulk of the
  * data to the medium, or just before completing.
  */
@@ -839,6 +849,7 @@ static int coroutine_fn mirror_run(Job *job, Error **errp)
 char backing_filename[2]; /* we only need 2 characters because we are only
  checking for a NULL string */
 int ret = 0;
+Error *local_err = NULL;
 
 if (job_is_cancelled(>common.job)) {
 goto immediate_exit;
@@ -913,9 +924,19 @@ static int coroutine_fn mirror_run(Job *job, Error **errp)
 
 s->last_pause_ns = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
 if (!s->is_none_mode) {
-ret = mirror_dirty_init(s);
-if (ret < 0 || job_is_cancelled(>common.job)) {
-goto immediate_exit;
+/* incremental mode */
+if (s->src_bitmap) {
+mirror_dirty_init_incremental(s, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+ret = -1;
+goto immediate_exit;
+}
+} else {
+ret = mirror_dirty_init(s);
+if (ret < 0 || job_is_cancelled(>common.job)) {
+goto immediate_exit;
+}
 }
 }
 
@@ -1484,7 +1505,8 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
  BlockCompletionFunc *cb,
  void *opaque,
  const BlockJobDriver *driver,
- bool is_none_mode, BlockDriverState *base,
+ bool is_none_mode, BdrvDirtyBitmap *src_bitmap,
+ BlockDriverState *base,
  bool auto_complete, const char *filter_node_name,
  bool is_mirror, MirrorCopyMode copy_mode,
  Error **errp)
@@ -1598,6 +1620,7 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
 s->on_source_error = on_source_error;
 s->on_target_error = on_target_error;
 s->is_none_mode = is_none_mode;
+s->src_bitmap = src_bitmap;
 s->backing_mode = backing_mode;
 s->copy_mode = copy_mode;
 s->base = base;
@@ -1664,7 +1687,8 @@ void mirror_start(const char *job_id, BlockDriverState 
*bs,
   BlockDriverState *target, const char *replaces,
   int creation_flags, int64_t speed,
   uint32_t granularity, int64_t buf_size,
-  MirrorSyncMode mode, BlockMirrorBackingMode backing_mode,
+  MirrorSyncMode mode, BdrvDirtyBitmap *src_bitmap,
+  BlockMirrorBackingMode backing_mode,
   BlockdevOnError on_source_error,
   BlockdevOnError on_target_error,
   bool unmap, const char *filter_node_name,
@@ -1673,17 +1697,14 @@ void mirror_start(const char *job_id, BlockDriverState 
*bs,
 bool is_none_mode;
 BlockDriverState *base;
 
-if (mode == MIRROR_SYNC_MODE_INCREMENTAL) {
-error_setg(errp, "Sync mode 'incremental' not supported");
-return;
-}
 is_none_mode = mode == MIRROR_SYNC_MODE_NONE;
 base = mode == MIRROR_SYNC_MODE_TOP ? backing_bs(bs) : NULL;
 mirror_start_job(job_id, bs, creation_flags, target, replaces,
  speed, granularity, buf_size, backing_mode,
  on_source_error, on_target_error, unmap, NULL, NULL,
- _job_driver, is_none_mode, base, false,
- filter_node_name, true, copy_mode, errp);
+ _job_driver, is_none_mode,
+ src_bitmap, base, false, filter_node_name, true,
+ copy_mode, errp);
 }
 
 void commit_active_start(const char 

[Qemu-devel] [PATCH v3 0/1] Drive-mirror: add incremental mode

2019-01-30 Thread mahaocong
From: mahaocong 

This patch adds possibility to start mirroring with user-created-bitmap.
On full mode, mirror create a non-named-bitmap by scanning whole block-chain,
and on top mode, mirror create a bitmap by scanning the top block layer. So I
think I can copy a user-created-bitmap and use it as the initial state of the
mirror, the same as incremental mode drive-backup, and I call this new mode
as incremental mode drive-mirror.

A possible usage scene of incremental mode mirror is live migration. For 
maintain
the block data and recover after a malfunction, someone may backup data to ceph
or other distributed storage. On qemu incremental backup, we need to create a 
new
bitmap and attach to block device before the first backup job. Then the bitmap
records the change after the backup job. If we want to migration this vm, we can
migrate block data between source and destionation by using drive-mirror 
directly,
or use backup data and backup-bitmap to reduce the data should be synchronize.
To do this, we should first create a new image in destination and set backing 
file
as backup image, then set backup-bitmap as the initial state of incremental mode
drive-mirror, and synchronize dirty block starting with the state set by the 
last
incremental backup job. When the mirror complete, we get an active layer on 
destination,
and its backing file is backup image on ceph. Then we can do live copy data from
backing files into overlay images by using block-stream, or do backup 
continually.

In this scene, It seems that If the guest os doesn't write too many data after 
the
last backup, the incremental mode may transmit less data than full mode or top
mode. However, if the write data is too many, there is no advantage on 
incremental
mode compare with other mode.

This scene can be described as following steps:
1.create rbd image in ceph, and map nbd device with rbd image.
2.create a new bitmap and attach to block device.
3.do full mode backup on nbd device and thus sync it to the rbd image.
4.severl times incremental mode backup.
5.create new image in destination and set its backing file as backup image.
6.do live-migration, and migrate block data by incremental mode drive-mirror
  with bitmap created from step 2.

mahaocong (1):
  drive-mirror: add incremental mode
  compare with old version, there are following changes:
  1.replace the copy bitmap function by bdrv_merge_dirty_bitmap
  2.remove checking for cancelled after mirror_dirty_init_incremental for bitmap
copyimg don't have yield point.
  3.adjuest input parameters on mirror_start_job and mirror_start, and so It is
no need to find bitmap on mirror_dirty_init_incremental again.
  4.assert the bitmap name is NULL on blockdev_mirror_common.
  5.change the parameter's name in qmp command 'drive-mirror' from 'bitmap_name'
to 'bitmap'.

 block/mirror.c| 46 ++
 blockdev.c| 37 +++--
 include/block/block_int.h |  3 ++-
 qapi/block-core.json  |  7 ++-
 4 files changed, 77 insertions(+), 16 deletions(-)

-- 
2.14.1





Re: [Qemu-devel] [PATCH] Fix for RSP vCont packet

2019-01-30 Thread Lucien Anti-Spam via Qemu-devel
 

On Thursday, January 31, 2019, 12:47:23 PM GMT+9, Eric Blake 
 wrote:  
 
 On 1/30/19 6:41 PM, Lucien Anti-Spam via Qemu-devel wrote:
> > This fixes a regression in rsp packet vCont due to recently added 
> > multiprocess support. (Short commit hash: e40e520).
> > 
> Your mailer completely botched the message (wrong line endings?)  Can ...
Sorry about that - none of my linux machines have smtp access and my workaround 
mangled it.I am trying to work out another way around that now.
  


Re: [Qemu-devel] [PATCH] Fix for RSP vCont packet

2019-01-30 Thread Eric Blake
On 1/30/19 6:41 PM, Lucien Anti-Spam via Qemu-devel wrote:
> This fixes a regression in rsp packet vCont due to recently added 
> multiprocess support. (Short commit hash: e40e520).
> 

Your mailer completely botched the message (wrong line endings?)  Can
you please resend, preferably using git send-email, or at a minimum
attaching git format-patch output rather than inline pasting, so that we
stand a chance of seeing what you actually intended?

> The result is that vCont now does not recognise the case where no 
> process/thread is provided after the action.
> This may not show up with GDB, but using Lauterbach Trace32, and Hexrays IDA 
> Pro this issue is immediately seen.The response is a "$#00" empty packet, 
> showing it is unsupported packet.
> This is defined in the RSP document as "An action with no thread-id matches 
> all 
> threads."(https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html#vCont-packet
>  )
> Thus the valid vCont packets now are as below, however parsing is still not 
> very strict.  vCont;c/s                 - Step/Continue all threads  
> vCont;c/s:[pX.]Y          - Step/Continue optional process X, thread Y  
> vCont;C##/S##:[pX.]Y      - Step/Continue with signal ## on optional process 
> X, thread Y  * If X or Y are -1 then it applies the action to all 
> processes/threads.
> Signed-off-by: Lucien Murray-Pitts --- gdbstub.c 
> | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
> diff --git a/gdbstub.c b/gdbstub.cindex bfc7afb509..ce0dde2e24 100644--- 
> a/gdbstub.c+++ b/gdbstub.c@@ -1169,6 +1169,7 @@ static int 
> is_query_packet(const char *p, const char *query, char separator)  */ static 
> int gdb_handle_vcont(GDBState *s, const char *p) {+    GDBThreadIdKind 
> vcontThreadType ;     int res, signal = 0;     char cur_action;     char 
> *newstates;@@ -1218,12 +1219,23 @@ static int gdb_handle_vcont(GDBState *s, 
> const char *p)             goto out;         } -        if (*p++ != ':') {+   
>      /*+         * In the case we have vCont;c or vCont;s - action is on all 
> threads+         * Alternatively vCont;c;s:p1.1 is a possible, but 
> meaningless format,+         * And in the else the "vCont;c:p1.1;... format 
> is supported.+         */+        if (*p == '\0' || *p == ';') {+            
> vcontThreadType = GDB_ALL_THREADS ;+            pid = 1 ;+            tid = 1 
> ;+        } else if (*p++ == ':') {+            vcontThreadType = 
> read_thread_id(p, , , ) ;+        } else {             res = 
> -ENOTSUP;             goto out;         } -        switch (read_thread_id(p, 
> , , )) {+        switch (vcontThreadType) {         case 
> GDB_READ_THREAD_ERR:             res = -EINVAL;             goto out;-- 2.17.2
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v5 0/8] target/ppc: remove various endian hacks from int_helper.c

2019-01-30 Thread David Gibson
On Wed, Jan 30, 2019 at 08:36:30PM +, Mark Cave-Ayland wrote:
> >From working on the TCG vector operations patchset, it is apparent that there
> are a large number of endian-based hacks in int_helper.c which can be removed 
> by
> making use of the various Vsr* macros.
> 
> Patch 1 is simple enough, and implements the complete set of Vsr* macros for
> both big endian and little endian hosts.
> 
> Patches 2 and 3 rework the vector merge and multiply algorithms so that they
> no longer require the endian-dependent HI_IDX and LO_IDX macros.
> 
> Patches 4 and 5 then completely remove the HI_IDX/LO_IDX and EL_IDX macros by
> replacing the element accesses with their equivalent Vsr* macro instead.
> 
> Patches 6 and 7 tidy up the VEXT_SIGNED macro and fix a potential shift bug
> in the ROTRu32 and ROTRu64 macros pointed out by Richard during the review of
> v1.
> 
> Finally patch 8 is an inspection-based removal of other HOST_WORDS_BIGENDIAN
> hacks in int_helper.c, again replacing accesses with the relevant Vsr* macro
> instead.
> 
> Note that there are still some endian hacks left in int_helper.c after this
> patchset: in particular the delightfully evil VECTOR_FOR_INORDER_I macro still
> remains in places where the index variable was used for purposes other than
> accessing elements within the vector.
> 
> There were also some parts where additional conversion could be done, but I
> wasn't confident enough to make the change without access to PPC64 test images
> or real big-endian host hardware.
> 
> Signed-off-by: Mark Cave-Ayland 

Applied to ppc-for-4.0, thanks.

> 
> 
> v5:
> - Rebase onto master
> - Update vmrg{l,h} algorithm macros in patch 2 as per Richard's suggestion
> 
> v4:
> - Rebase onto master
> - Add R-B tag from Richard for patch 4
> - Use Richard's improved vmrg{l,h} algorithm in patch 2
> 
> v3:
> - Rebase onto master
> - Add R-B tags from Richard
> 
> v2:
> - Add R-B tags from Richard
> - Add patches 6 and 7 to simplify the VEXT_SIGNED macro and fix a potential
>   shift bug in the ROTRu32 and ROTRu64 macros
> - Don't require ordered access for VNEG and VGENERIC_DO macros as pointed out
>   by Richard
> 
> 
> Mark Cave-Ayland (8):
>   target/ppc: implement complete set of Vsr* macros
>   target/ppc: rework vmrg{l,h}{b,h,w} instructions to use Vsr* macros
>   target/ppc: rework vmul{e,o}{s,u}{b,h,w} instructions to use Vsr*
> macros
>   target/ppc: eliminate use of HI_IDX and LO_IDX macros from
> int_helper.c
>   target/ppc: eliminate use of EL_IDX macros from int_helper.c
>   target/ppc: simplify VEXT_SIGNED macro in int_helper.c
>   target/ppc: remove ROTRu32 and ROTRu64 macros from int_helper.c
>   target/ppc: remove various HOST_WORDS_BIGENDIAN hacks in int_helper.c
> 
>  target/ppc/int_helper.c | 523 
> +++-
>  target/ppc/internal.h   |   9 +-
>  2 files changed, 217 insertions(+), 315 deletions(-)
> 

-- 
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] ppc: remove the interrupt presenters from under PowerPCCPU

2019-01-30 Thread David Gibson
On Mon, Jan 28, 2019 at 07:55:52AM +0100, Cédric Le Goater wrote:
> These fields have now been replaced by equivalents under the machine
> data.
> 
> Signed-off-by: Cédric Le Goater 

Applied to ppc-for-4.0, thanks.

> ---
>  target/ppc/cpu.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index a62ff60414f4..2c22292e7f41 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1178,9 +1178,6 @@ do {\
>  typedef struct PPCVirtualHypervisor PPCVirtualHypervisor;
>  typedef struct PPCVirtualHypervisorClass PPCVirtualHypervisorClass;
>  
> -struct XiveTCTX;
> -struct ICPState;
> -
>  /**
>   * PowerPCCPU:
>   * @env: #CPUPPCState
> @@ -1198,8 +1195,6 @@ struct PowerPCCPU {
>  int vcpu_id;
>  uint32_t compat_pvr;
>  PPCVirtualHypervisor *vhyp;
> -struct ICPState *icp;
> -struct XiveTCTX *tctx;
>  void *machine_data;
>  int32_t node_id; /* NUMA node this CPU belongs to */
>  PPCHash64Options *hash64_opts;

-- 
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] NSIS - including DLL dependencies for Windows

2019-01-30 Thread Adam Baxter
Hi,
How do I gather and include the required DLLs (SDL, zlib etc) in the NSIS
installer? (and also in a standalone build to be zipped up, but that's less
important)

I noticed the wiki doesn't really mention bundling dependencies anywhere.

The official unofficial windows builds are documented at
https://qemu.weilnetz.de/FAQ but this doesn't cover building the actual
installer.

Regards,
Adam


Re: [Qemu-devel] [PATCH] iotests/236: fix transaction kwarg order

2019-01-30 Thread Eric Blake
On 1/30/19 8:26 PM, John Snow wrote:
> It's not enough to order the kwargs for consistent QMP log output,
> we must also sort any sub-dictionaries in lists that appear as values.
> 
> Reported-by: Kevin Wolf 
> Signed-off-by: John Snow 
> ---
>  tests/qemu-iotests/236.out| 56 +--
>  tests/qemu-iotests/iotests.py | 21 ++---
>  2 files changed, 39 insertions(+), 38 deletions(-)
> 

> +++ b/tests/qemu-iotests/iotests.py
> @@ -76,15 +76,16 @@ def qemu_img(*args):
>  sys.stderr.write('qemu-img received signal %i: %s\n' % (-exitcode, ' 
> '.join(qemu_img_args + list(args
>  return exitcode
>  
> -def ordered_kwargs(kwargs):
> -# kwargs prior to 3.6 are not ordered, so:
> -od = OrderedDict()
> -for k, v in sorted(kwargs.items()):
> -if isinstance(v, dict):
> -od[k] = ordered_kwargs(v)
> -else:
> -od[k] = v
> -return od
> +def ordered_qmp(qmsg):
> +# Dictionaries are not ordered prior to 3.6, therefore:
> +if isinstance(qmsg, list):
> +return [ordered_qmp(atom) for atom in qmsg]
> +if isinstance(qmsg, dict):
> +od = OrderedDict()
> +for k, v in sorted(qmsg.items()):
> +od[k] = ordered_qmp(v)
> +return od
> +return qmsg
>  

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] block/dirty-bitmap: Documentation and Comment fixups

2019-01-30 Thread Eric Blake
On 1/30/19 7:01 PM, John Snow wrote:
> The meaning of the states has changed subtly over time,
> this should bring the understanding more in-line with the
> current, actual usages.
> 
> Reported-by: Eric Blake 
> Signed-off-by: John Snow 
> ---
>  block/dirty-bitmap.c | 19 +--
>  qapi/block-core.json | 17 -
>  2 files changed, 25 insertions(+), 11 deletions(-)
> 
Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 18/18] Boot Linux Console Test: add a test for alpha + clipper

2019-01-30 Thread Cleber Rosa



On 1/22/19 5:52 AM, Philippe Mathieu-Daudé wrote:
> On 1/17/19 7:56 PM, Cleber Rosa wrote:
>> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
>> board and verify the serial is working.  One extra command added to
>> the QEMU command line is '-vga std', because the kernel used is
>> known to crash without it.
>>
>> If alpha is a target being built, "make check-acceptance" will
>> automatically include this test by the use of the "arch:alpha" tags.
>>
>> Alternatively, this test can be run using:
>>
>> $ avocado run -t arch:alpha tests/acceptance
>> $ avocado run -t machine:clipper tests/acceptance
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Cleber Rosa 
>> ---
>>  .travis.yml|  2 +-
>>  scripts/qemu.py|  1 -
>>  tests/acceptance/boot_linux_console.py | 22 ++
>>  3 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 0d5a4b104b..73a113af87 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -187,7 +187,7 @@ matrix:
>>  
>>  # Acceptance (Functional) tests
>>  - env:
>> -- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,ppc64-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu"
>> +- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,ppc64-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu"
>>  - TEST_CMD="make check-acceptance"
>>addons:
>>  apt:
>> diff --git a/scripts/qemu.py b/scripts/qemu.py
>> index 1531e28fc1..a704da418a 100644
>> --- a/scripts/qemu.py
>> +++ b/scripts/qemu.py
>> @@ -34,7 +34,6 @@ def kvm_available(target_arch=None):
>>  
>>  #: Maps machine types to the preferred console device types
>>  CONSOLE_DEV_TYPES = {
>> -r'^clipper$': 'isa-serial',
> 
> Why this change?
> 

Because we've come to conclusion (I believe :) that's better, whenever
possible, to let QEMU pick the default device type by machine.  The
discussion happened here:

https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg04582.html

- Cleber.



Re: [Qemu-devel] [PATCH 14/18] Boot Linux Console Test: add a test for ppc64 + pseries

2019-01-30 Thread Cleber Rosa



On 1/22/19 11:07 AM, Alex Bennée wrote:
> 
> Cleber Rosa  writes:
> 
>> Just like the previous tests, boots a Linux kernel on a ppc64 target
>> using the pseries machine.
> 
> So running this on my rather slow SynQuacer I get:
> 
>  (04/16) 
> /home/alex/lsrc/qemu.git/tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_ppc64_pseries:
>  INTERRUPTED: Test reported status but did not finish\nRunner error occurred: 
> Timeout reached\nOriginal status: ERROR\n{'name': 
> '04-/home/alex/lsrc/qemu.git/tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_ppc64_pseries',
>  'logdir': '/home/alex/lsrc/qemu.git/te... (60.93 s)
> 
> which I'm guessing is a timeout occurring.
> 

Yes, that's what's happening.  It's hard to pinpoint, and control, the
sluggishness points in such a test running on a different environment.
For this one execution, I do trust your assessment, and it's most
certainly caused by your "slow SynQuacer", spending too much running
emulation code.

But, I'd like to mention that there are other possibilities.  One is
that you're hitting a "asset fetcher bug" that I recently fixed in
Avocado[1] (fix to be available on 68.0, to be released next Monday, Feb
4th).

Even with that bug fixed, I feel like it's unfair to test code to spend
its time waiting to download a file when it's not testing *the file
download itself*.  Because of that, there are plans to add an (optional)
job pre-processing step that will make sure the needed assets are in the
cache ahead of time[2][3].

> I wonder if that means we should:
> 
>   a) set timeouts longer for when running on TCG
>   or
>   b) split tests into TCG and KVM tests and select KVM tests on appropriate HW
> 

I wonder the same, and I believe this falls into a similar scenario
we've seen with the setup of console devices in the QEMUMachine class.
I've started by setting the device types defined at the framework level,
and then reverted to the machine's default devices (using '-serial'),
because the "default" behavior of QEMU is usually what a test writer
wants when not setting something else explicitly.

> The qemu.py code has (slightly flawed) logic for detecting KVM and
> passing --enable-kvm. Maybe we should be doing that here?
> 

I'm not sure.  IMO, the common question is: should we magically (at a
framework level) configure tests based on probed host environment
characteristics?  I feel like we should attempt to minimize that for the
sake of tests being more obvious and more easily reproducible.

And because of that, I'd go, *initially*, with an approach more similar
to your option "b".

Having said that, we don't want to rewrite most tests just to be able to
test with either KVM or TCG, if the tests are not explicitly testing KVM
or TCG.  At this point, using KVM or TCG is test/framework
*configuration*, and in Avocado we hope to solve this by having the
executed tests easily identifiable and reproducible (a test ID will
contain a information about the options passed, and a replay of the job
will apply the same configuration).

For now, I think the best approach is to increase the timeout, because I
think it's much worse to have to deal with false negatives (longer
execution times that don't really mean a failure), than having a test
possibly taking some more time to finish.

And sorry for extremely the long answer!
- Cleber.

[1] - https://github.com/avocado-framework/avocado/pull/2996
[2] -
https://trello.com/c/WPd4FrIy/1479-add-support-to-specify-assets-in-test-docstring
[3] - https://trello.com/c/CKP7YS6G/1481-on-cache-check-for-asset-fetcher



[Qemu-devel] [PATCH] iotests/236: fix transaction kwarg order

2019-01-30 Thread John Snow
It's not enough to order the kwargs for consistent QMP log output,
we must also sort any sub-dictionaries in lists that appear as values.

Reported-by: Kevin Wolf 
Signed-off-by: John Snow 
---
 tests/qemu-iotests/236.out| 56 +--
 tests/qemu-iotests/iotests.py | 21 ++---
 2 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/tests/qemu-iotests/236.out b/tests/qemu-iotests/236.out
index 1dad24db0d..bb2d71ea5e 100644
--- a/tests/qemu-iotests/236.out
+++ b/tests/qemu-iotests/236.out
@@ -45,23 +45,23 @@ write -P0xcd 0x3ff 64k
 "actions": [
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapB"
+  "name": "bitmapB",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-disable"
   },
   {
 "data": {
-  "node": "drive0",
+  "granularity": 65536,
   "name": "bitmapC",
-  "granularity": 65536
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-add"
   },
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapA"
+  "name": "bitmapA",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-clear"
   },
@@ -105,30 +105,30 @@ write -P0xcd 0x3ff 64k
 "actions": [
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapB"
+  "name": "bitmapB",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-disable"
   },
   {
 "data": {
-  "node": "drive0",
+  "granularity": 65536,
   "name": "bitmapC",
-  "granularity": 65536
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-add"
   },
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapC"
+  "name": "bitmapC",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-disable"
   },
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapC"
+  "name": "bitmapC",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-enable"
   }
@@ -158,15 +158,15 @@ write -P0xea 0x3fe 64k
 "actions": [
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapA"
+  "name": "bitmapA",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-disable"
   },
   {
 "data": {
-  "node": "drive0",
-  "name": "bitmapC"
+  "name": "bitmapC",
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-disable"
   }
@@ -209,21 +209,21 @@ write -P0xea 0x3fe 64k
 "actions": [
   {
 "data": {
-  "node": "drive0",
   "disabled": true,
+  "granularity": 65536,
   "name": "bitmapD",
-  "granularity": 65536
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-add"
   },
   {
 "data": {
-  "node": "drive0",
-  "target": "bitmapD",
   "bitmaps": [
 "bitmapB",
 "bitmapC"
-  ]
+  ],
+  "node": "drive0",
+  "target": "bitmapD"
 },
 "type": "block-dirty-bitmap-merge"
   },
@@ -273,21 +273,21 @@ write -P0xea 0x3fe 64k
 "actions": [
   {
 "data": {
-  "node": "drive0",
   "disabled": true,
+  "granularity": 65536,
   "name": "bitmapD",
-  "granularity": 65536
+  "node": "drive0"
 },
 "type": "block-dirty-bitmap-add"
   },
   {
 "data": {
-  "node": "drive0",
-  "target": "bitmapD",
   "bitmaps": [
 "bitmapB",
 "bitmapC"
-  ]
+  ],
+  "node": "drive0",
+  "target": "bitmapD"
 },
 "type": "block-dirty-bitmap-merge"
   }
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index cbedfaf1df..76ad52b358 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -76,15 +76,16 @@ def qemu_img(*args):
 sys.stderr.write('qemu-img received signal %i: %s\n' % (-exitcode, ' 
'.join(qemu_img_args + list(args
 return exitcode
 
-def ordered_kwargs(kwargs):
-# kwargs prior to 3.6 are not ordered, so:
-od = OrderedDict()
-for k, v in sorted(kwargs.items()):
-if isinstance(v, dict):
-od[k] = ordered_kwargs(v)
-else:
-od[k] = v
-return od
+def ordered_qmp(qmsg):
+# Dictionaries are not ordered prior to 3.6, therefore:
+if isinstance(qmsg, list):
+return [ordered_qmp(atom) for atom in qmsg]
+if isinstance(qmsg, dict):
+od = OrderedDict()
+for k, v in sorted(qmsg.items()):
+od[k] = ordered_qmp(v)
+return od
+return qmsg
 
 def 

Re: [Qemu-devel] [PATCH V2] test-filter-mirror: pass UNIX domain socket through fd

2019-01-30 Thread Zhang Chen
On Wed, Jan 30, 2019 at 11:14 AM Jason Wang  wrote:

> The tests tries to let qemu server mode to process the connection
> which turns out to be racy after commit 8258292e18c3 ("monitor: Remove
> "x-oob", offer capability "oob" unconditionally"). This is because the
> filter may try to mirror the packets before UNIX socket object is
> ready (connected was set to true) from the view of qemu. In this case
> the packet will be dropped silently.
>
> Fixing this by passing pre-connected socket created by socketpair() to
> qemu through fd.
>
> Cc: Peter Maydell 
> Cc: Li Zhijian 
> Cc: Peter Xu 
> Cc: Dr. David Alan Gilbert 
> Cc: Zhang Chen 
> Cc: Markus Armbruster 
> Cc: Daniel P. Berrange 
> Signed-off-by: Jason Wang 
>

Looks good for me.
Reviewed-by: Zhang Chen 

By the way: Do we need add ASCII diagram to explain data flow in this file
or commit log?

Thanks
Zhang Chen


> ---
> Changes from v1:
> - close the socket pairs in the end of test
> ---
>  tests/test-filter-mirror.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/tests/test-filter-mirror.c b/tests/test-filter-mirror.c
> index 7ab2aed8a0..d942c74a3f 100644
> --- a/tests/test-filter-mirror.c
> +++ b/tests/test-filter-mirror.c
> @@ -21,10 +21,9 @@
>
>  static void test_mirror(void)
>  {
> -int send_sock[2], recv_sock;
> +int send_sock[2], recv_sock[2];
>  uint32_t ret = 0, len = 0;
>  char send_buf[] = "Hello! filter-mirror~";
> -char sock_path[] = "filter-mirror.XX";
>  char *recv_buf;
>  uint32_t size = sizeof(send_buf);
>  size = htonl(size);
> @@ -38,18 +37,15 @@ static void test_mirror(void)
>  ret = socketpair(PF_UNIX, SOCK_STREAM, 0, send_sock);
>  g_assert_cmpint(ret, !=, -1);
>
> -ret = mkstemp(sock_path);
> +ret = socketpair(PF_UNIX, SOCK_STREAM, 0, recv_sock);
>  g_assert_cmpint(ret, !=, -1);
>
>  qts = qtest_initf(
>  "-netdev socket,id=qtest-bn0,fd=%d "
>  "-device %s,netdev=qtest-bn0,id=qtest-e0 "
> -"-chardev socket,id=mirror0,path=%s,server,nowait "
> +"-chardev socket,id=mirror0,fd=%d "
>  "-object
> filter-mirror,id=qtest-f0,netdev=qtest-bn0,queue=tx,outdev=mirror0 "
> -, send_sock[1], devstr, sock_path);
> -
> -recv_sock = unix_connect(sock_path, NULL);
> -g_assert_cmpint(recv_sock, !=, -1);
> +, send_sock[1], devstr, recv_sock[1]);
>
>  struct iovec iov[] = {
>  {
> @@ -67,18 +63,20 @@ static void test_mirror(void)
>  g_assert_cmpint(ret, ==, sizeof(send_buf) + sizeof(size));
>  close(send_sock[0]);
>
> -ret = qemu_recv(recv_sock, , sizeof(len), 0);
> +ret = qemu_recv(recv_sock[0], , sizeof(len), 0);
>  g_assert_cmpint(ret, ==, sizeof(len));
>  len = ntohl(len);
>
>  g_assert_cmpint(len, ==, sizeof(send_buf));
>  recv_buf = g_malloc(len);
> -ret = qemu_recv(recv_sock, recv_buf, len, 0);
> +ret = qemu_recv(recv_sock[0], recv_buf, len, 0);
>  g_assert_cmpstr(recv_buf, ==, send_buf);
>
>  g_free(recv_buf);
> -close(recv_sock);
> -unlink(sock_path);
> +close(send_sock[0]);
> +close(send_sock[1]);
> +close(recv_sock[0]);
> +close(recv_sock[1]);
>  qtest_quit(qts);
>  }
>
> --
> 2.17.1
>
>


Re: [Qemu-devel] [Qemu-block] [PATCH] iotests: Filter second BLOCK_JOB_ERROR from 229

2019-01-30 Thread John Snow



On 1/30/19 6:52 PM, Max Reitz wrote:
> Without this filter, this test sometimes fails.
> 
> Signed-off-by: Max Reitz 
> ---
> I intended to send this as part of my iotest fixes series, but it ended
> up on the wrong branch...  Doesn't really matter, though, as there is no
> functional dependency.
> ---
>  tests/qemu-iotests/229 | 6 +-
>  tests/qemu-iotests/229.out | 1 -
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/229 b/tests/qemu-iotests/229
> index 893d098ad2..b0d4885fa6 100755
> --- a/tests/qemu-iotests/229
> +++ b/tests/qemu-iotests/229
> @@ -81,11 +81,15 @@ echo
>  echo '=== Force cancel job paused in error state  ==='
>  echo
>  
> +# Filter out BLOCK_JOB_ERROR events because they may or may not occur.
> +# Cancelling the job means resuming it for a bit before it is actually
> +# aborted, and in that time it may or may not re-encounter the error.

Oh, because the job is "paused" and cancelling it involves job_enter,
which we then allow the job to gracefully fail through it's own pathways
-- but depending on where it failed originally, it may-or-may-not wind
up trying something else that fails before it finds the "exit
gracefully" signal, is that right?

I guess there's no real way to adjust that behavior.

>  success_or_failure="y" _send_qemu_cmd $QEMU_HANDLE \
>  "{'execute': 'block-job-cancel',
>   'arguments': { 'device': 'testdisk',
>  'force': true}}" \
> - "BLOCK_JOB_CANCELLED" "Assertion"
> + "BLOCK_JOB_CANCELLED" "Assertion" \
> +| grep -v '"BLOCK_JOB_ERROR"'
>  
>  # success, all done
>  echo "*** done"
> diff --git a/tests/qemu-iotests/229.out b/tests/qemu-iotests/229.out
> index 4c4112805f..a3eb33788a 100644
> --- a/tests/qemu-iotests/229.out
> +++ b/tests/qemu-iotests/229.out
> @@ -17,7 +17,6 @@ wrote 2097152/2097152 bytes at offset 0
>  
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "testdisk"}}
>  {"return": {}}
> -{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "BLOCK_JOB_ERROR", "data": {"device": "testdisk", "operation": "write", 
> "action": "stop"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "aborting", "id": "testdisk"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "BLOCK_JOB_CANCELLED", "data": {"device": "testdisk", "len": 2097152, 
> "offset": 1048576, "speed": 0, "type": "mirror"}}
>  *** done
> 

I think this is fine, if we cannot help to make this any more
deterministic, so I'm fine with:

Reviewed-by: John Snow 

but I am curious to know if this poses any theoretical problems for
libvirt having to deal with possibly an extra hiccup before the cancel
registers.



Re: [Qemu-devel] [PULL 11/20] iotests: add iotest 236 for testing bitmap merge

2019-01-30 Thread John Snow



On 1/30/19 12:27 PM, Kevin Wolf wrote:
> Am 14.01.2019 um 17:25 hat Eric Blake geschrieben:
>> From: John Snow 
>>
>> New interface, new smoke test.
>>
>> Signed-off-by: John Snow 
>> Reviewed-by: Vladimir Sementsov-Ogievskiy 
>> Reviewed-by: Eric Blake 
>> Message-Id: <20181221093529.23855-12-js...@redhat.com>
>> [eblake: fix last-minute change to echo text]
>> Signed-off-by: Eric Blake 
> 
> This test fails for me (with Python 3) because I get a different dict
> order.
> 
> Probably related to the OrderedDict that qmp_log() uses, so log() uses
> sort_keys=False and the unordered dicts that are contained in the outer
> OrderedDict stay unordered.
> 
> Kevin
> 

OK, the problem is that ordered_kwargs() is not recursively ordering
those kwargs beneath list entries, so transactions are avoiding the sort.

Patch coming up, thank you for the report and my apologies for breaking
iotests so often this cycle.

(While I'm here, how do you configure iotests to use your python3
binary? I tried at configure time but that breaks the build for me with
some "magic number" errors. I could toy with it after by editing
common.env, but should the build work with python3?)



Re: [Qemu-devel] [PATCH 13/18] Boot Linux Console Test: add a test for mips64el + malta

2019-01-30 Thread Cleber Rosa



On 1/22/19 5:57 AM, Philippe Mathieu-Daudé wrote:
> On 1/17/19 7:56 PM, Cleber Rosa wrote:
>> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
>> board and verify the serial is working.
>>
>> If mips64el is a target being built, "make check-acceptance" will
>> automatically include this test by the use of the "arch:mips" tags.
>>
>> Alternatively, this test can be run using:
>>
>> $ avocado run -t arch:mips64el tests/acceptance
>> $ avocado run -t machine:malta tests/acceptance
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Cleber Rosa 
>> ---
>>  .travis.yml|  2 +-
>>  tests/acceptance/boot_linux_console.py | 39 ++
>>  2 files changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 49f9016e6a..28648f7a61 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -187,7 +187,7 @@ matrix:
>>  
>>  # Acceptance (Functional) tests
>>  - env:
>> -- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu"
>> +- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu"
>>  - TEST_CMD="make check-acceptance"
>>addons:
>>  apt:
>> diff --git a/tests/acceptance/boot_linux_console.py 
>> b/tests/acceptance/boot_linux_console.py
>> index 0678ec91d2..20b845fce1 100644
>> --- a/tests/acceptance/boot_linux_console.py
>> +++ b/tests/acceptance/boot_linux_console.py
>> @@ -9,8 +9,11 @@
>>  # later.  See the COPYING file in the top-level directory.
>>  
>>  import logging
>> +import os
>>  
>>  from avocado_qemu import Test
>> +from avocado.utils import process
>> +from avocado.utils import archive
>>  
>>  
>>  class BootLinuxConsole(Test):
>> @@ -80,3 +83,39 @@ class BootLinuxConsole(Test):
>>  self.vm.launch()
>>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>>  self.wait_for_console_pattern(console_pattern)
>> +
>> +def test_mips64el_malta(self):
>> +"""
>> +This test requires the ar tool to extract "data.tar.gz" from
>> +the Debian package.
>> +
>> +The kernel can be rebuilt using this Debian kernel source [1] and
>> +following the instructions on [2].
>> +
>> +[1] 
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
>> +[2] 
>> http://snapshot.debian.org/package/linux-2.6/2.6.32-48/#linux-source-2.6.32_2.6.32-48
>> +
>> +:avocado: tags=arch:mips64el
>> +:avocado: tags=machine:malta
>> +"""
>> +deb_url = 
>> ('http://snapshot.debian.org/archive/debian/20130217T032700Z/'
>> +   'pool/main/l/linux-2.6/'
>> +   'linux-image-2.6.32-5-5kc-malta_2.6.32-48_mipsel.deb')
>> +deb_hash = '1aaec92083bf22fda31e0d27fa8d9a388e5fc3d5'
>> +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
>> +
>> +cwd = os.getcwd()
>> +os.chdir(self.workdir)
>> +process.run("ar x %s data.tar.gz" % deb_path)
>> +archive.extract("data.tar.gz", self.workdir)
>> +os.chdir(cwd)
>> +kernel_path = self.workdir + '/boot/vmlinux-2.6.32-5-5kc-malta'
>> +
>> +self.vm.set_machine('malta')
>> +self.vm.set_console()
>> +kernel_command_line = 'console=ttyS0 printk.time=0'
> 
> What about having a generic KERNEL_COMMON_COMMAND_LINE='printk.time=0 '
> then using
>   kernel_command_line = KERNEL_COMMON_COMMAND_LINE + 'console=ttyS0'
> in each tests of this series?
>

Not sure... I do like the fact that it's more uniform, but I don't like
the locality aspect.  Having to refer back to something defined either
in the module or class level for something so small is a big con, IMO.

I'll keep it AS IS for now, and if more people feel like it's a good
idea, or you feel stronger that it's a good idea, I can add it in the
next version.

Thanks!
- Cleber.

>> +self.vm.add_args('-kernel', kernel_path,
>> + '-append', kernel_command_line)
>> +self.vm.launch()
>> +console_pattern = 'Kernel command line: %s' % kernel_command_line
>> +self.wait_for_console_pattern(console_pattern)
>>




Re: [Qemu-devel] [PATCH 13/18] Boot Linux Console Test: add a test for mips64el + malta

2019-01-30 Thread Cleber Rosa



On 1/22/19 5:19 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 1/17/19 7:56 PM, Cleber Rosa wrote:
>> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
>> board and verify the serial is working.
>>
>> If mips64el is a target being built, "make check-acceptance" will
>> automatically include this test by the use of the "arch:mips" tags.
>>
>> Alternatively, this test can be run using:
>>
>> $ avocado run -t arch:mips64el tests/acceptance
>> $ avocado run -t machine:malta tests/acceptance
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Cleber Rosa 
>> ---
>>  .travis.yml|  2 +-
>>  tests/acceptance/boot_linux_console.py | 39 ++
>>  2 files changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 49f9016e6a..28648f7a61 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -187,7 +187,7 @@ matrix:
>>  
>>  # Acceptance (Functional) tests
>>  - env:
>> -- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu"
>> +- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu"
>>  - TEST_CMD="make check-acceptance"
>>addons:
>>  apt:
>> diff --git a/tests/acceptance/boot_linux_console.py 
>> b/tests/acceptance/boot_linux_console.py
>> index 0678ec91d2..20b845fce1 100644
>> --- a/tests/acceptance/boot_linux_console.py
>> +++ b/tests/acceptance/boot_linux_console.py
>> @@ -9,8 +9,11 @@
>>  # later.  See the COPYING file in the top-level directory.
>>  
>>  import logging
>> +import os
>>  
>>  from avocado_qemu import Test
>> +from avocado.utils import process
>> +from avocado.utils import archive
>>  
>>  
>>  class BootLinuxConsole(Test):
>> @@ -80,3 +83,39 @@ class BootLinuxConsole(Test):
>>  self.vm.launch()
>>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>>  self.wait_for_console_pattern(console_pattern)
>> +
>> +def test_mips64el_malta(self):
>> +"""
>> +This test requires the ar tool to extract "data.tar.gz" from
>> +the Debian package.
>> +
>> +The kernel can be rebuilt using this Debian kernel source [1] and
>> +following the instructions on [2].
>> +
>> +[1] 
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
>> +[2] 
>> http://snapshot.debian.org/package/linux-2.6/2.6.32-48/#linux-source-2.6.32_2.6.32-48
>> +
>> +:avocado: tags=arch:mips64el
>> +:avocado: tags=machine:malta
>> +"""
>> +deb_url = 
>> ('http://snapshot.debian.org/archive/debian/20130217T032700Z/'
>> +   'pool/main/l/linux-2.6/'
>> +   'linux-image-2.6.32-5-5kc-malta_2.6.32-48_mipsel.deb')
>> +deb_hash = '1aaec92083bf22fda31e0d27fa8d9a388e5fc3d5'
>> +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
>> +
> 
> Can you refactor this code ...
> 
>> +cwd = os.getcwd()
>> +os.chdir(self.workdir)
>> +process.run("ar x %s data.tar.gz" % deb_path)
>> +archive.extract("data.tar.gz", self.workdir)
>> +os.chdir(cwd)
>> +kernel_path = self.workdir + '/boot/vmlinux-2.6.32-5-5kc-malta'
> 
> ... as an helper function?
> 

Yes.  In fact, because of the kernel change in the previous patch, I've
added it there.

> Can be follow-up patch, so:
> Reviewed-by: Philippe Mathieu-Daudé 
> 

In the longer term, I expect to add deb (and RPM, etc) support to the
avocado.utils.archive module:

https://trello.com/c/bQBnvkjv/1437-avocadoutilsarchive-support-rpm-deb-etc


Thanks!
- Cleber.



[Qemu-devel] [PATCH] block/dirty-bitmap: Documentation and Comment fixups

2019-01-30 Thread John Snow
The meaning of the states has changed subtly over time,
this should bring the understanding more in-line with the
current, actual usages.

Reported-by: Eric Blake 
Signed-off-by: John Snow 
---
 block/dirty-bitmap.c | 19 +--
 qapi/block-core.json | 17 -
 2 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 00ea36f554..e2adf54dd3 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -29,12 +29,19 @@
 #include "block/blockjob.h"
 
 /**
- * A BdrvDirtyBitmap can be in three possible states:
- * (1) successor is NULL and disabled is false: full r/w mode
- * (2) successor is NULL and disabled is true: read only mode ("disabled")
- * (3) successor is set: frozen mode.
- * A frozen bitmap cannot be renamed, deleted, anonymized, cleared, set,
- * or enabled. A frozen bitmap can only abdicate() or reclaim().
+ * A BdrvDirtyBitmap can be in four possible user-visible states:
+ * (1) Active:   successor is NULL, and disabled is false: full r/w mode
+ * (2) Disabled: successor is NULL, and disabled is true: qualified r/w mode,
+ *   guest writes are dropped, but monitor writes are possible,
+ *   through commands like merge and clear.
+ * (3) Frozen:   successor is not null.
+ *   A frozen bitmap cannot be renamed, deleted, cleared, set,
+ *   enabled, merged to, etc. A frozen bitmap can only abdicate()
+ *   or reclaim().
+ *   In this state, the successor bitmap is Active and will
+ *   generally be recording writes from the guest for us.
+ * (4) Locked:   Whether Active or Disabled, the user cannot modify this bitmap
+ *   in any way from the monitor.
  */
 struct BdrvDirtyBitmap {
 QemuMutex *mutex;
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 91685be6c2..eba126c76e 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -418,10 +418,12 @@
 # An enumeration of possible states that a dirty bitmap can report to the user.
 #
 # @frozen: The bitmap is currently in-use by a backup operation or block job,
-#  and is immutable.
+#  and is immutable. New writes by the guest are being recorded in a
+#  cache, and are not lost.
 #
-# @disabled: The bitmap is currently in-use by an internal operation and is
-#read-only. It can still be deleted.
+# @disabled: The bitmap is not currently recording new writes by the guest.
+#This is requested explicitly via @block-dirty-bitmap-disable.
+#It can still be cleared, deleted, or used for backup operations.
 #
 # @active: The bitmap is actively monitoring for new writes, and can be 
cleared,
 #  deleted, or used for backup operations.
@@ -1944,9 +1946,14 @@
 # @block-dirty-bitmap-merge:
 #
 # Merge dirty bitmaps listed in @bitmaps to the @target dirty bitmap.
-# The @bitmaps dirty bitmaps are unchanged.
+# Dirty bitmaps in @bitmaps will be unchanged.
+# Any bits already set in @target will still be set after the merge.
 # On error, @target is unchanged.
 #
+# The resulting bitmap will count as dirty any clusters that were dirty in any
+# of the source bitmaps. This can be used to achieve backup checkpoints, or in
+# simpler usages, to copy bitmaps.
+#
 # Returns: nothing on success
 #  If @node is not a valid block device, DeviceNotFound
 #  If any bitmap in @bitmaps or @target is not found, GenericError
@@ -1981,7 +1988,7 @@
 ##
 # @x-debug-block-dirty-bitmap-sha256:
 #
-# Get bitmap SHA256
+# Get bitmap SHA256.
 #
 # Returns: BlockDirtyBitmapSha256 on success
 #  If @node is not a valid block device, DeviceNotFound
-- 
2.17.2




[Qemu-devel] [PULL 09/13] nvme: ensure the num_queues is not zero

2019-01-30 Thread Max Reitz
From: Li Qiang 

When it is zero, it causes segv.
Using following command:

"-drive file=//home/test/test1.img,if=none,id=id0
-device nvme,drive=id0,serial=test,num_queues=0"
causes following Backtrack:

Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9735700 (LWP 30952)]
0x55a7a77c in nvme_start_ctrl (n=0x577473f0) at hw/block/nvme.c:825
825 if (unlikely(n->cq[0])) {
(gdb) bt
0  0x55a7a77c in nvme_start_ctrl (n=0x577473f0)
at hw/block/nvme.c:825
1  0x55a7af7f in nvme_write_bar (n=0x577473f0, offset=20,
data=4587521, size=4) at hw/block/nvme.c:969
2  0x55a7b81a in nvme_mmio_write (opaque=0x577473f0, addr=20,
data=4587521, size=4) at hw/block/nvme.c:1163
3  0x55869236 in memory_region_write_accessor (mr=0x57747cd0,
addr=20, value=0x7fffe97320f8, size=4, shift=0, mask=4294967295, attrs=...)
at /home/test/qemu1/qemu/memory.c:502
4  0x55869446 in access_with_adjusted_size (addr=20,
value=0x7fffe97320f8, size=4, access_size_min=2, access_size_max=8,
access_fn=0x5586914d ,
mr=0x57747cd0, attrs=...) at /home/test/qemu1/qemu/memory.c:568
5  0x5586c479 in memory_region_dispatch_write (mr=0x57747cd0,
addr=20, data=4587521, size=4, attrs=...)
at /home/test/qemu1/qemu/memory.c:1499
6  0x558030af in flatview_write_continue (fv=0x7fffe0061130,
addr=4273930260, attrs=..., buf=0x77ff0028 "\001", len=4, addr1=20,
l=4, mr=0x57747cd0) at /home/test/qemu1/qemu/exec.c:3234
7  0x558031f9 in flatview_write (fv=0x7fffe0061130, addr=4273930260,
attrs=..., buf=0x77ff0028 "\001", len=4)
at /home/test/qemu1/qemu/exec.c:3273
8  0x558034ff in address_space_write (
---Type  to continue, or q  to quit---
as=0x56758480 , addr=4273930260, attrs=...,
buf=0x77ff0028 "\001", len=4) at /home/test/qemu1/qemu/exec.c:3363
9  0x55803550 in address_space_rw (
as=0x56758480 , addr=4273930260, attrs=...,
buf=0x77ff0028 "\001", len=4, is_write=true)
at /home/test/qemu1/qemu/exec.c:3374
10 0x558884a1 in kvm_cpu_exec (cpu=0x56920e40)
at /home/test/qemu1/qemu/accel/kvm/kvm-all.c:2031
11 0x5584cd9d in qemu_kvm_cpu_thread_fn (arg=0x56920e40)
at /home/test/qemu1/qemu/cpus.c:1281
12 0x55dbaf6d in qemu_thread_start (args=0x569438a0)
at util/qemu-thread-posix.c:502
13 0x75dc86db in start_thread (arg=0x7fffe9735700)
at pthread_create.c:463
14 0x75af188f in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Signed-off-by: Li Qiang 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 2019012008.32984-3-liq...@163.com
Signed-off-by: Max Reitz 
---
 hw/block/nvme.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index f206391e8e..0b77b49b36 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1208,6 +1208,11 @@ static void nvme_realize(PCIDevice *pci_dev, Error 
**errp)
 int64_t bs_size;
 uint8_t *pci_conf;
 
+if (!n->num_queues) {
+error_setg(errp, "num_queues can't be zero");
+return;
+}
+
 if (!n->conf.blk) {
 error_setg(errp, "drive property not set");
 return;
-- 
2.20.1




[Qemu-devel] [PULL 12/13] iotests: Bind qemu-nbd to localhost in 147

2019-01-30 Thread Max Reitz
By default, qemu-nbd binds to 0.0.0.0.  However, we then proceed to
connect to "localhost".  Usually, this works out fine; but if this test
is run concurrently, some other test function may have bound a different
server to ::1 (on the same port -- you can bind different serves to the
same port, as long as one is on IPv4 and the other on IPv6).

So running qemu-nbd works, it can bind to 0.0.0.0:NBD_PORT.  But
potentially a concurrent test has successfully taken [::1]:NBD_PORT.  In
this case, trying to connect to "localhost" will lead us to the IPv6
instance, where we do not want to end up.

Fix this by just binding to "localhost".  This will make qemu-nbd error
out immediately and not give us cryptic errors later.

(Also, it will allow us to just try a different port as of a future
patch.)

Signed-off-by: Max Reitz 
Message-id: 20181221234750.23577-3-mre...@redhat.com
Reviewed-by: John Snow 
Reviewed-by: Eric Blake 
Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/147 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/147 b/tests/qemu-iotests/147
index 05b374b7d3..3e10a9969e 100755
--- a/tests/qemu-iotests/147
+++ b/tests/qemu-iotests/147
@@ -92,7 +92,7 @@ class QemuNBD(NBDBlockdevAddBase):
 self.assertEqual(qemu_nbd('-f', imgfmt, test_img, *args), 0)
 
 def test_inet(self):
-self._server_up('-p', str(NBD_PORT))
+self._server_up('-b', 'localhost', '-p', str(NBD_PORT))
 address = { 'type': 'inet',
 'data': {
 'host': 'localhost',
-- 
2.20.1




[Qemu-devel] [PULL 08/13] nvme: use TYPE_NVME instead of constant string

2019-01-30 Thread Max Reitz
From: Li Qiang 

Signed-off-by: Li Qiang 
Reviewed-by: Max Reitz 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 2019012008.32984-2-liq...@163.com
Signed-off-by: Max Reitz 
---
 hw/block/nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 7c8c63e8f5..f206391e8e 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1381,7 +1381,7 @@ static void nvme_instance_init(Object *obj)
 }
 
 static const TypeInfo nvme_info = {
-.name  = "nvme",
+.name  = TYPE_NVME,
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(NvmeCtrl),
 .class_init= nvme_class_init,
-- 
2.20.1




Re: [Qemu-devel] [PATCH 0/3] iotests: Allow 147 to be run concurrently

2019-01-30 Thread Max Reitz
On 22.12.18 00:47, Max Reitz wrote:
> 147 currently cannot be run concurrently for two reasons:
> 
> (1) It creates TCP/IP NBD servers on a fixed port.
> 
> (2) It uses a mix of "0.0.0.0", "localhost", and "::1" as host addresses
> to bind to.  As explained in the commit messages of patches 2 and 3,
> this results in it potentially actually being able to set up two
> servers on the same port at the same time -- but connecting to one
> will always lead to the IPv6 server (regardless of whether you use
> "localhost" or "::1").  Therefore, even if you get two servers
> running concurrently, one of the tests will still break because it
> connects to the wrong one.
> 
> This series fixes these issues.
> 
> 
> Note that even if you do not care about concurrency, it still is a good
> idea to make 147 not use a fixed port to create NBD servers on, as it
> may always be already in use by a totally different application.
> 
> 
> Max Reitz (3):
>   iotests.py: Add qemu_nbd_pipe()
>   iotests: Bind qemu-nbd to localhost in 147
>   iotests: Allow 147 to be run concurrently
> 
>  tests/qemu-iotests/147| 98 ---
>  tests/qemu-iotests/iotests.py | 14 +
>  2 files changed, 82 insertions(+), 30 deletions(-)

Applied to my block branch.

Max



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PULL 13/13] iotests: Allow 147 to be run concurrently

2019-01-30 Thread Max Reitz
To do this, we need to allow creating the NBD server on various ports
instead of a single one (which may not even work if you run just one
instance, because something entirely else might be using that port).

So we just pick a random port in [32768, 32768 + 1024) and try to create
a server there.  If that fails, we just retry until something sticks.

For the IPv6 test, we need a different range, though (just above that
one).  This is because "localhost" resolves to both 127.0.0.1 and ::1.
This means that if you bind to it, it will bind to both, if possible, or
just one if the other is already in use.  Therefore, if the IPv6 test
has already taken [::1]:some_port and we then try to take
localhost:some_port, that will work -- only the second server will be
bound to 127.0.0.1:some_port alone and not [::1]:some_port in addition.
So we have two different servers on the same port, one for IPv4 and one
for IPv6.

But when we then try to connect to the server through
localhost:some_port, we will always end up at the IPv6 one (as long as
it is up), and this may not be the one we want.

Thus, we must make sure not to create an IPv6-only NBD server on the
same port as a normal "dual-stack" NBD server -- which is done by using
distinct port ranges, as explained above.

Signed-off-by: Max Reitz 
Message-id: 20181221234750.23577-4-mre...@redhat.com
Reviewed-by: John Snow 
Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/147 | 98 +-
 1 file changed, 68 insertions(+), 30 deletions(-)

diff --git a/tests/qemu-iotests/147 b/tests/qemu-iotests/147
index 3e10a9969e..82513279b0 100755
--- a/tests/qemu-iotests/147
+++ b/tests/qemu-iotests/147
@@ -19,13 +19,17 @@
 #
 
 import os
+import random
 import socket
 import stat
 import time
 import iotests
-from iotests import cachemode, imgfmt, qemu_img, qemu_nbd
+from iotests import cachemode, imgfmt, qemu_img, qemu_nbd, qemu_nbd_pipe
 
-NBD_PORT = 10811
+NBD_PORT_START  = 32768
+NBD_PORT_END= NBD_PORT_START + 1024
+NBD_IPV6_PORT_START = NBD_PORT_END
+NBD_IPV6_PORT_END   = NBD_IPV6_PORT_START + 1024
 
 test_img = os.path.join(iotests.test_dir, 'test.img')
 unix_socket = os.path.join(iotests.test_dir, 'nbd.socket')
@@ -88,17 +92,29 @@ class QemuNBD(NBDBlockdevAddBase):
 except OSError:
 pass
 
+def _try_server_up(self, *args):
+status, msg = qemu_nbd_pipe('-f', imgfmt, test_img, *args)
+if status == 0:
+return True
+if 'Address already in use' in msg:
+return False
+self.fail(msg)
+
 def _server_up(self, *args):
-self.assertEqual(qemu_nbd('-f', imgfmt, test_img, *args), 0)
+self.assertTrue(self._try_server_up(*args))
 
 def test_inet(self):
-self._server_up('-b', 'localhost', '-p', str(NBD_PORT))
+while True:
+nbd_port = random.randrange(NBD_PORT_START, NBD_PORT_END)
+if self._try_server_up('-b', 'localhost', '-p', str(nbd_port)):
+break
+
 address = { 'type': 'inet',
 'data': {
 'host': 'localhost',
-'port': str(NBD_PORT)
+'port': str(nbd_port)
 } }
-self.client_test('nbd://localhost:%i' % NBD_PORT,
+self.client_test('nbd://localhost:%i' % nbd_port,
  flatten_sock_addr(address))
 
 def test_unix(self):
@@ -130,8 +146,13 @@ class BuiltinNBD(NBDBlockdevAddBase):
 except OSError:
 pass
 
-def _server_up(self, address, export_name=None, export_name2=None):
+# Returns False on EADDRINUSE; fails an assertion on other errors.
+# Returns True on success.
+def _try_server_up(self, address, export_name=None, export_name2=None):
 result = self.server.qmp('nbd-server-start', addr=address)
+if 'error' in result and \
+   'Address already in use' in result['error']['desc']:
+return False
 self.assert_qmp(result, 'return', {})
 
 if export_name is None:
@@ -146,20 +167,28 @@ class BuiltinNBD(NBDBlockdevAddBase):
  name=export_name2)
 self.assert_qmp(result, 'return', {})
 
+return True
+
+def _server_up(self, address, export_name=None, export_name2=None):
+self.assertTrue(self._try_server_up(address, export_name, 
export_name2))
 
 def _server_down(self):
 result = self.server.qmp('nbd-server-stop')
 self.assert_qmp(result, 'return', {})
 
 def do_test_inet(self, export_name=None):
-address = { 'type': 'inet',
-'data': {
-'host': 'localhost',
-'port': str(NBD_PORT)
-} }
-self._server_up(address, export_name)
+while True:
+nbd_port = random.randrange(NBD_PORT_START, NBD_PORT_END)
+address = { 'type': 'inet',
+  

[Qemu-devel] [PULL 11/13] iotests.py: Add qemu_nbd_pipe()

2019-01-30 Thread Max Reitz
In some cases, we may want to deal with qemu-nbd errors (e.g. by
launching it in a different configuration until it no longer throws
any).  In that case, we do not want its output ending up in the test
output.

It may still be useful for handling the error, though, so add a new
function that works basically like qemu_nbd(), only that it returns the
qemu-nbd output instead of making it end up in the log.  In contrast to
qemu_img_pipe(), it does still return the exit code as well, though,
because that is even more important for error handling.

Signed-off-by: Max Reitz 
Message-id: 20181221234750.23577-2-mre...@redhat.com
Reviewed-by: John Snow 
Reviewed-by: Eric Blake 
Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/iotests.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index cbedfaf1df..009c614ef7 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -201,6 +201,20 @@ def qemu_nbd(*args):
 '''Run qemu-nbd in daemon mode and return the parent's exit code'''
 return subprocess.call(qemu_nbd_args + ['--fork'] + list(args))
 
+def qemu_nbd_pipe(*args):
+'''Run qemu-nbd in daemon mode and return both the parent's exit code
+   and its output'''
+subp = subprocess.Popen(qemu_nbd_args + ['--fork'] + list(args),
+stdout=subprocess.PIPE,
+stderr=subprocess.STDOUT,
+universal_newlines=True)
+exitcode = subp.wait()
+if exitcode < 0:
+sys.stderr.write('qemu-nbd received signal %i: %s\n' %
+ (-exitcode,
+  ' '.join(qemu_nbd_args + ['--fork'] + list(args
+return exitcode, subp.communicate()[0]
+
 def compare_images(img1, img2, fmt1=imgfmt, fmt2=imgfmt):
 '''Return True if two image files are identical'''
 return qemu_img('compare', '-f', fmt1,
-- 
2.20.1




[Qemu-devel] [PULL 05/13] block/file-posix: Convert from DPRINTF() macro to trace events

2019-01-30 Thread Max Reitz
From: Laurent Vivier 

Signed-off-by: Laurent Vivier 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20181213162727.17438-4-lviv...@redhat.com
Signed-off-by: Max Reitz 
---
 block/file-posix.c | 25 ++---
 block/trace-events |  7 +++
 2 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 8aee7a3fb8..ba6ab62a38 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -102,19 +102,7 @@
 #include 
 #endif
 
-//#define DEBUG_BLOCK
-
-#ifdef DEBUG_BLOCK
-# define DEBUG_BLOCK_PRINT 1
-#else
-# define DEBUG_BLOCK_PRINT 0
-#endif
-#define DPRINTF(fmt, ...) \
-do { \
-if (DEBUG_BLOCK_PRINT) { \
-printf(fmt, ## __VA_ARGS__); \
-} \
-} while (0)
+#include "trace.h"
 
 /* OS X does not have O_DSYNC */
 #ifndef O_DSYNC
@@ -1411,7 +1399,7 @@ static int xfs_write_zeroes(BDRVRawState *s, int64_t 
offset, uint64_t bytes)
 
 if (xfsctl(NULL, s->fd, XFS_IOC_ZERO_RANGE, ) < 0) {
 err = errno;
-DPRINTF("cannot write zero range (%s)\n", strerror(errno));
+trace_file_xfs_write_zeroes(strerror(errno));
 return -err;
 }
 
@@ -1430,7 +1418,7 @@ static int xfs_discard(BDRVRawState *s, int64_t offset, 
uint64_t bytes)
 
 if (xfsctl(NULL, s->fd, XFS_IOC_UNRESVSP64, ) < 0) {
 err = errno;
-DPRINTF("cannot punch hole (%s)\n", strerror(errno));
+trace_file_xfs_discard(strerror(errno));
 return -err;
 }
 
@@ -2819,7 +2807,7 @@ static char *FindEjectableOpticalMedia(io_iterator_t 
*mediaIterator)
 
 /* If a match was found, leave the loop */
 if (*mediaIterator != 0) {
-DPRINTF("Matching using %s\n", matching_array[index]);
+trace_file_FindEjectableOpticalMedia(matching_array[index]);
 mediaType = g_strdup(matching_array[index]);
 break;
 }
@@ -2879,7 +2867,7 @@ static bool setup_cdrom(char *bsd_path, Error **errp)
 if (partition_found == false) {
 error_setg(errp, "Failed to find a working partition on disc");
 } else {
-DPRINTF("Using %s as optical disc\n", test_partition);
+trace_file_setup_cdrom(test_partition);
 pstrcpy(bsd_path, MAXPATHLEN, test_partition);
 }
 return partition_found;
@@ -2974,8 +2962,7 @@ static bool hdev_is_sg(BlockDriverState *bs)
 
 ret = ioctl(s->fd, SG_GET_SCSI_ID, );
 if (ret >= 0) {
-DPRINTF("SG device found: type=%d, version=%d\n",
-scsiid.scsi_type, sg_version);
+trace_file_hdev_is_sg(scsiid.scsi_type, sg_version);
 return true;
 }
 
diff --git a/block/trace-events b/block/trace-events
index 8ea8d1eaeb..41b998b7eb 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -186,3 +186,10 @@ curl_open(const char *file) "opening %s"
 curl_open_size(uint64_t size) "size = %" PRIu64
 curl_setup_preadv(uint64_t bytes, uint64_t start, const char *range) "reading 
%" PRIu64 " at %" PRIu64 " (%s)"
 curl_close(void) "close"
+
+# block/file-posix.c
+file_xfs_write_zeroes(const char *error) "cannot write zero range (%s)"
+file_xfs_discard(const char *error) "cannot punch hole (%s)"
+file_FindEjectableOpticalMedia(const char *media) "Matching using %s"
+file_setup_cdrom(const char *partition) "Using %s as optical disc"
+file_hdev_is_sg(int type, int version) "SG device found: type=%d, version=%d"
-- 
2.20.1




[Qemu-devel] [PULL 10/13] nvme: use pci_dev directly in nvme_realize

2019-01-30 Thread Max Reitz
From: Li Qiang 

There is no need to make another reference.

Signed-off-by: Li Qiang 
Reviewed-by: Max Reitz 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 2019012008.32984-4-liq...@163.com
Signed-off-by: Max Reitz 
---
 hw/block/nvme.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 0b77b49b36..8325b5e88a 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1238,7 +1238,7 @@ static void nvme_realize(PCIDevice *pci_dev, Error **errp)
 pci_conf[PCI_INTERRUPT_PIN] = 1;
 pci_config_set_prog_interface(pci_dev->config, 0x2);
 pci_config_set_class(pci_dev->config, PCI_CLASS_STORAGE_EXPRESS);
-pcie_endpoint_cap_init(>parent_obj, 0x80);
+pcie_endpoint_cap_init(pci_dev, 0x80);
 
 n->num_namespaces = 1;
 n->reg_size = pow2ceil(0x1004 + 2 * (n->num_queues + 1) * 4);
@@ -1250,10 +1250,10 @@ static void nvme_realize(PCIDevice *pci_dev, Error 
**errp)
 
 memory_region_init_io(>iomem, OBJECT(n), _mmio_ops, n,
   "nvme", n->reg_size);
-pci_register_bar(>parent_obj, 0,
+pci_register_bar(pci_dev, 0,
 PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64,
 >iomem);
-msix_init_exclusive_bar(>parent_obj, n->num_queues, 4, NULL);
+msix_init_exclusive_bar(pci_dev, n->num_queues, 4, NULL);
 
 id->vid = cpu_to_le16(pci_get_word(pci_conf + PCI_VENDOR_ID));
 id->ssvid = cpu_to_le16(pci_get_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID));
@@ -1308,7 +1308,7 @@ static void nvme_realize(PCIDevice *pci_dev, Error **errp)
 n->cmbuf = g_malloc0(NVME_CMBSZ_GETSIZE(n->bar.cmbsz));
 memory_region_init_io(>ctrl_mem, OBJECT(n), _cmb_ops, n,
   "nvme-cmb", NVME_CMBSZ_GETSIZE(n->bar.cmbsz));
-pci_register_bar(>parent_obj, NVME_CMBLOC_BIR(n->bar.cmbloc),
+pci_register_bar(pci_dev, NVME_CMBLOC_BIR(n->bar.cmbloc),
 PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64 |
 PCI_BASE_ADDRESS_MEM_PREFETCH, >ctrl_mem);
 
-- 
2.20.1




[Qemu-devel] [PULL 07/13] qemu-io: Add generic function for reinitializing optind.

2019-01-30 Thread Max Reitz
From: "Richard W.M. Jones" 

On FreeBSD 11.2:

  $ nbdkit memory size=1M --run './qemu-io -f raw -c "aio_write 0 512" $nbd'
  Parsing error: non-numeric argument, or extraneous/unrecognized suffix -- 
aio_write

After main option parsing, we reinitialize optind so we can parse each
command.  However reinitializing optind to 0 does not work on FreeBSD.
What happens when you do this is optind remains 0 after the option
parsing loop, and the result is we try to parse argv[optind] ==
argv[0] == "aio_write" as if it was the first parameter.

The FreeBSD manual page says:

  In order to use getopt() to evaluate multiple sets of arguments, or to
  evaluate a single set of arguments multiple times, the variable optreset
  must be set to 1 before the second and each additional set of calls to
  getopt(), and the variable optind must be reinitialized.

(From the rest of the man page it is clear that optind must be
reinitialized to 1).

The glibc man page says:

  A program that scans multiple argument vectors,  or  rescans  the  same
  vector  more than once, and wants to make use of GNU extensions such as
  '+' and '-' at  the  start  of  optstring,  or  changes  the  value  of
  POSIXLY_CORRECT  between scans, must reinitialize getopt() by resetting
  optind to 0, rather than the traditional value of 1.  (Resetting  to  0
  forces  the  invocation  of  an  internal  initialization  routine that
  rechecks POSIXLY_CORRECT and checks for GNU extensions in optstring.)

This commit introduces an OS-portability function called
qemu_reset_optind which provides a way of resetting optind that works
on FreeBSD and platforms that use optreset, while keeping it the same
as now on other platforms.

Note that the qemu codebase sets optind in many other places, but in
those other places it's setting a local variable and not using getopt.
This change is only needed in places where we are using getopt and the
associated global variable optind.

Signed-off-by: Richard W.M. Jones 
Message-id: 20190118101114.11759-2-rjo...@redhat.com
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Eric Blake 
Signed-off-by: Max Reitz 
---
 configure| 14 ++
 include/qemu/osdep.h | 16 
 qemu-img.c   |  2 +-
 qemu-io-cmds.c   |  2 +-
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index b18281c61f..831d26d4ae 100755
--- a/configure
+++ b/configure
@@ -4269,6 +4269,17 @@ if compile_prog "" "" ; then
   signalfd=yes
 fi
 
+# check if optreset global is declared by 
+optreset="no"
+cat > $TMPC << EOF
+#include 
+int main(void) { return optreset; }
+EOF
+
+if compile_prog "" "" ; then
+  optreset=yes
+fi
+
 # check if eventfd is supported
 eventfd=no
 cat > $TMPC << EOF
@@ -6643,6 +6654,9 @@ fi
 if test "$signalfd" = "yes" ; then
   echo "CONFIG_SIGNALFD=y" >> $config_host_mak
 fi
+if test "$optreset" = "yes" ; then
+  echo "HAVE_OPTRESET=y" >> $config_host_mak
+fi
 if test "$tcg" = "yes"; then
   echo "CONFIG_TCG=y" >> $config_host_mak
   if test "$tcg_interpreter" = "yes" ; then
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 80df7253db..840af09cb0 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -109,6 +109,7 @@ extern int daemon(int, int);
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -604,4 +605,19 @@ extern int qemu_icache_linesize_log;
 extern int qemu_dcache_linesize;
 extern int qemu_dcache_linesize_log;
 
+/*
+ * After using getopt or getopt_long, if you need to parse another set
+ * of options, then you must reset optind.  Unfortunately the way to
+ * do this varies between implementations of getopt.
+ */
+static inline void qemu_reset_optind(void)
+{
+#ifdef HAVE_OPTRESET
+optind = 1;
+optreset = 1;
+#else
+optind = 0;
+#endif
+}
+
 #endif
diff --git a/qemu-img.c b/qemu-img.c
index ad04f59565..25288c4d18 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -4962,7 +4962,7 @@ int main(int argc, char **argv)
 return 0;
 }
 argv += optind;
-optind = 0;
+qemu_reset_optind();
 
 if (!trace_init_backends()) {
 exit(1);
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 2c39124036..ee8f56e46a 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -114,7 +114,7 @@ static int command(BlockBackend *blk, const cmdinfo_t *ct, 
int argc,
 }
 }
 
-optind = 0;
+qemu_reset_optind();
 return ct->cfunc(blk, argc, argv);
 }
 
-- 
2.20.1




[Qemu-devel] [PULL 06/13] block/sheepdog: Convert from DPRINTF() macro to trace events

2019-01-30 Thread Max Reitz
From: Laurent Vivier 

Signed-off-by: Laurent Vivier 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20181213162727.17438-5-lviv...@redhat.com
[mreitz: Fixed sheepdog_snapshot_create_inode's format string to use
 PRIx32 for uint32_ts]
Signed-off-by: Max Reitz 
---
 block/sheepdog.c   | 47 +-
 block/trace-events | 14 ++
 2 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/block/sheepdog.c b/block/sheepdog.c
index ed14f7afbe..b916ba07bf 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -28,6 +28,7 @@
 #include "sysemu/block-backend.h"
 #include "qemu/bitops.h"
 #include "qemu/cutils.h"
+#include "trace.h"
 
 #define SD_PROTO_VER 0x01
 
@@ -299,19 +300,6 @@ static inline size_t count_data_objs(const struct 
SheepdogInode *inode)
 (1UL << inode->block_size_shift));
 }
 
-#undef DPRINTF
-#ifdef DEBUG_SDOG
-#define DEBUG_SDOG_PRINT 1
-#else
-#define DEBUG_SDOG_PRINT 0
-#endif
-#define DPRINTF(fmt, args...)   \
-do {\
-if (DEBUG_SDOG_PRINT) { \
-fprintf(stderr, "%s %d: " fmt, __func__, __LINE__, ##args); \
-}   \
-} while (0)
-
 typedef struct SheepdogAIOCB SheepdogAIOCB;
 typedef struct BDRVSheepdogState BDRVSheepdogState;
 
@@ -750,7 +738,7 @@ static coroutine_fn void reconnect_to_sdog(void *opaque)
 Error *local_err = NULL;
 s->fd = get_sheep_fd(s, _err);
 if (s->fd < 0) {
-DPRINTF("Wait for connection to be established\n");
+trace_sheepdog_reconnect_to_sdog();
 error_report_err(local_err);
 qemu_co_sleep_ns(QEMU_CLOCK_REALTIME, 10ULL);
 }
@@ -847,7 +835,7 @@ static void coroutine_fn aio_read_response(void *opaque)
 break;
 case AIOCB_FLUSH_CACHE:
 if (rsp.result == SD_RES_INVALID_PARMS) {
-DPRINTF("disable cache since the server doesn't support it\n");
+trace_sheepdog_aio_read_response();
 s->cache_flags = SD_FLAG_CMD_DIRECT;
 rsp.result = SD_RES_SUCCESS;
 }
@@ -1639,7 +1627,7 @@ static int sd_open(BlockDriverState *bs, QDict *options, 
int flags,
 s->discard_supported = true;
 
 if (snap_id || tag[0]) {
-DPRINTF("%" PRIx32 " snapshot inode was open.\n", vid);
+trace_sheepdog_open(vid);
 s->is_snapshot = true;
 }
 
@@ -2252,7 +2240,7 @@ static void sd_close(BlockDriverState *bs)
 unsigned int wlen, rlen = 0;
 int fd, ret;
 
-DPRINTF("%s\n", s->name);
+trace_sheepdog_close(s->name);
 
 fd = connect_to_sdog(s, _err);
 if (fd < 0) {
@@ -2429,7 +2417,7 @@ static int sd_create_branch(BDRVSheepdogState *s)
 char *buf;
 bool deleted;
 
-DPRINTF("%" PRIx32 " is snapshot.\n", s->inode.vdi_id);
+trace_sheepdog_create_branch_snapshot(s->inode.vdi_id);
 
 buf = g_malloc(SD_INODE_SIZE);
 
@@ -2445,7 +2433,7 @@ static int sd_create_branch(BDRVSheepdogState *s)
 goto out;
 }
 
-DPRINTF("%" PRIx32 " is created.\n", vid);
+trace_sheepdog_create_branch_created(vid);
 
 fd = connect_to_sdog(s, _err);
 if (fd < 0) {
@@ -2467,7 +2455,7 @@ static int sd_create_branch(BDRVSheepdogState *s)
 
 s->is_snapshot = false;
 ret = 0;
-DPRINTF("%" PRIx32 " was newly created.\n", s->inode.vdi_id);
+trace_sheepdog_create_branch_new(s->inode.vdi_id);
 
 out:
 g_free(buf);
@@ -2561,11 +2549,11 @@ static void coroutine_fn sd_co_rw_vector(SheepdogAIOCB 
*acb)
 }
 
 if (create) {
-DPRINTF("update ino (%" PRIu32 ") %" PRIu64 " %" PRIu64 " %ld\n",
-inode->vdi_id, oid,
-vid_to_data_oid(inode->data_vdi_id[idx], idx), idx);
+trace_sheepdog_co_rw_vector_update(inode->vdi_id, oid,
+  vid_to_data_oid(inode->data_vdi_id[idx], 
idx),
+  idx);
 oid = vid_to_data_oid(inode->vdi_id, idx);
-DPRINTF("new oid %" PRIx64 "\n", oid);
+trace_sheepdog_co_rw_vector_new(oid);
 }
 
 aio_req = alloc_aio_req(s, acb, oid, len, offset, flags, create,
@@ -2670,9 +2658,8 @@ static int sd_snapshot_create(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info)
 SheepdogInode *inode;
 unsigned int datalen;
 
-DPRINTF("sn_info: name %s id_str %s s: name %s vm_state_size %" PRId64 " "
-"is_snapshot %d\n", sn_info->name, sn_info->id_str,
-s->name, sn_info->vm_state_size, s->is_snapshot);
+trace_sheepdog_snapshot_create_info(sn_info->name, sn_info->id_str, 
s->name,
+sn_info->vm_state_size, 
s->is_snapshot);
 
 if (s->is_snapshot) {
 error_report("You can't create a snapshot of 

[Qemu-devel] [PULL 03/13] block/ssh: Convert from DPRINTF() macro to trace events

2019-01-30 Thread Max Reitz
From: Laurent Vivier 

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20181213162727.17438-2-lviv...@redhat.com
[mreitz: Fixed type of ssh_{read,write}_return's parameter to be ssize_t
 instead of size_t]
Signed-off-by: Max Reitz 
---
 block/ssh.c| 46 +-
 block/trace-events | 17 +
 2 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/block/ssh.c b/block/ssh.c
index 7fbc27abdf..bbc513e095 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -41,27 +41,17 @@
 #include "qapi/qmp/qstring.h"
 #include "qapi/qobject-input-visitor.h"
 #include "qapi/qobject-output-visitor.h"
+#include "trace.h"
 
-/* DEBUG_SSH=1 enables the DPRINTF (debugging printf) statements in
- * this block driver code.
- *
+/*
  * TRACE_LIBSSH2= enables tracing in libssh2 itself.  Note
  * that this requires that libssh2 was specially compiled with the
  * `./configure --enable-debug' option, so most likely you will have
  * to compile it yourself.  The meaning of  is described
  * here: http://www.libssh2.org/libssh2_trace.html
  */
-#define DEBUG_SSH 0
 #define TRACE_LIBSSH2 0 /* or try: LIBSSH2_TRACE_SFTP */
 
-#define DPRINTF(fmt, ...)   \
-do {\
-if (DEBUG_SSH) {\
-fprintf(stderr, "ssh: %-15s " fmt "\n", \
-__func__, ##__VA_ARGS__);   \
-}   \
-} while (0)
-
 typedef struct BDRVSSHState {
 /* Coroutine. */
 CoMutex lock;
@@ -336,7 +326,7 @@ static int check_host_key_knownhosts(BDRVSSHState *s,
 switch (r) {
 case LIBSSH2_KNOWNHOST_CHECK_MATCH:
 /* OK */
-DPRINTF("host key OK: %s", found->key);
+trace_ssh_check_host_key_knownhosts(found->key);
 break;
 case LIBSSH2_KNOWNHOST_CHECK_MISMATCH:
 ret = -EINVAL;
@@ -721,8 +711,7 @@ static int connect_to_ssh(BDRVSSHState *s, 
BlockdevOptionsSsh *opts,
 }
 
 /* Open the remote file. */
-DPRINTF("opening file %s flags=0x%x creat_mode=0%o",
-opts->path, ssh_flags, creat_mode);
+trace_ssh_connect_to_ssh(opts->path, ssh_flags, creat_mode);
 s->sftp_handle = libssh2_sftp_open(s->sftp, opts->path, ssh_flags,
creat_mode);
 if (!s->sftp_handle) {
@@ -890,7 +879,7 @@ static int coroutine_fn ssh_co_create_opts(const char 
*filename, QemuOpts *opts,
 /* Get desired file size. */
 ssh_opts->size = ROUND_UP(qemu_opt_get_size_del(opts, BLOCK_OPT_SIZE, 0),
   BDRV_SECTOR_SIZE);
-DPRINTF("total_size=%" PRIi64, ssh_opts->size);
+trace_ssh_co_create_opts(ssh_opts->size);
 
 uri_options = qdict_new();
 ret = parse_uri(filename, uri_options, errp);
@@ -946,7 +935,7 @@ static void restart_coroutine(void *opaque)
 BDRVSSHState *s = bs->opaque;
 AioContext *ctx = bdrv_get_aio_context(bs);
 
-DPRINTF("co=%p", restart->co);
+trace_ssh_restart_coroutine(restart->co);
 aio_set_fd_handler(ctx, s->sock, false, NULL, NULL, NULL, NULL);
 
 aio_co_wake(restart->co);
@@ -974,13 +963,12 @@ static coroutine_fn void co_yield(BDRVSSHState *s, 
BlockDriverState *bs)
 wr_handler = restart_coroutine;
 }
 
-DPRINTF("s->sock=%d rd_handler=%p wr_handler=%p", s->sock,
-rd_handler, wr_handler);
+trace_ssh_co_yield(s->sock, rd_handler, wr_handler);
 
 aio_set_fd_handler(bdrv_get_aio_context(bs), s->sock,
false, rd_handler, wr_handler, NULL, );
 qemu_coroutine_yield();
-DPRINTF("s->sock=%d - back", s->sock);
+trace_ssh_co_yield_back(s->sock);
 }
 
 /* SFTP has a function `libssh2_sftp_seek64' which seeks to a position
@@ -1003,7 +991,7 @@ static void ssh_seek(BDRVSSHState *s, int64_t offset, int 
flags)
 bool force = (flags & SSH_SEEK_FORCE) != 0;
 
 if (force || op_read != s->offset_op_read || offset != s->offset) {
-DPRINTF("seeking to offset=%" PRIi64, offset);
+trace_ssh_seek(offset);
 libssh2_sftp_seek64(s->sftp_handle, offset);
 s->offset = offset;
 s->offset_op_read = op_read;
@@ -1019,7 +1007,7 @@ static coroutine_fn int ssh_read(BDRVSSHState *s, 
BlockDriverState *bs,
 char *buf, *end_of_vec;
 struct iovec *i;
 
-DPRINTF("offset=%" PRIi64 " size=%zu", offset, size);
+trace_ssh_read(offset, size);
 
 ssh_seek(s, offset, SSH_SEEK_READ);
 
@@ -1038,9 +1026,9 @@ static coroutine_fn int ssh_read(BDRVSSHState *s, 
BlockDriverState *bs,
  */
 for (got = 0; got < size; ) {
 again:
-DPRINTF("sftp_read buf=%p size=%zu", buf, end_of_vec - buf);
+trace_ssh_read_buf(buf, end_of_vec - buf);
 r = libssh2_sftp_read(s->sftp_handle, buf, end_of_vec - buf);
-DPRINTF("sftp_read returned %zd", r);
+

[Qemu-devel] [PULL 04/13] block/curl: Convert from DPRINTF() macro to trace events

2019-01-30 Thread Max Reitz
From: Laurent Vivier 

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20181213162727.17438-3-lviv...@redhat.com
Signed-off-by: Max Reitz 
---
 block/curl.c   | 29 -
 block/trace-events |  9 +
 2 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/block/curl.c b/block/curl.c
index db5d2bd8ef..b7ac265d3a 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -32,22 +32,10 @@
 #include "crypto/secret.h"
 #include 
 #include "qemu/cutils.h"
+#include "trace.h"
 
-// #define DEBUG_CURL
 // #define DEBUG_VERBOSE
 
-#ifdef DEBUG_CURL
-#define DEBUG_CURL_PRINT 1
-#else
-#define DEBUG_CURL_PRINT 0
-#endif
-#define DPRINTF(fmt, ...)\
-do { \
-if (DEBUG_CURL_PRINT) {  \
-fprintf(stderr, fmt, ## __VA_ARGS__);\
-}\
-} while (0)
-
 #if LIBCURL_VERSION_NUM >= 0x071000
 /* The multi interface timer callback was introduced in 7.16.0 */
 #define NEED_CURL_TIMER_CALLBACK
@@ -154,7 +142,7 @@ static int curl_timer_cb(CURLM *multi, long timeout_ms, 
void *opaque)
 {
 BDRVCURLState *s = opaque;
 
-DPRINTF("CURL: timer callback timeout_ms %ld\n", timeout_ms);
+trace_curl_timer_cb(timeout_ms);
 if (timeout_ms == -1) {
 timer_del(>timer);
 } else {
@@ -193,7 +181,7 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, int 
action,
 }
 socket = NULL;
 
-DPRINTF("CURL (AIO): Sock action %d on fd %d\n", action, (int)fd);
+trace_curl_sock_cb(action, (int)fd);
 switch (action) {
 case CURL_POLL_IN:
 aio_set_fd_handler(s->aio_context, fd, false,
@@ -238,7 +226,7 @@ static size_t curl_read_cb(void *ptr, size_t size, size_t 
nmemb, void *opaque)
 size_t realsize = size * nmemb;
 int i;
 
-DPRINTF("CURL: Just reading %zd bytes\n", realsize);
+trace_curl_read_cb(realsize);
 
 if (!s || !s->orig_buf) {
 goto read_end;
@@ -777,7 +765,7 @@ static int curl_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 }
 
-DPRINTF("CURL: Opening %s\n", file);
+trace_curl_open(file);
 qemu_co_queue_init(>free_state_waitq);
 s->aio_context = bdrv_get_aio_context(bs);
 s->url = g_strdup(file);
@@ -830,7 +818,7 @@ static int curl_open(BlockDriverState *bs, QDict *options, 
int flags,
 "Server does not support 'range' (byte ranges).");
 goto out;
 }
-DPRINTF("CURL: Size = %" PRIu64 "\n", s->len);
+trace_curl_open_size(s->len);
 
 qemu_mutex_lock(>mutex);
 curl_clean_state(state);
@@ -908,8 +896,7 @@ static void curl_setup_preadv(BlockDriverState *bs, 
CURLAIOCB *acb)
 state->acb[0] = acb;
 
 snprintf(state->range, 127, "%" PRIu64 "-%" PRIu64, start, end);
-DPRINTF("CURL (AIO): Reading %" PRIu64 " at %" PRIu64 " (%s)\n",
-acb->bytes, start, state->range);
+trace_curl_setup_preadv(acb->bytes, start, state->range);
 curl_easy_setopt(state->curl, CURLOPT_RANGE, state->range);
 
 curl_multi_add_handle(s->multi, state->curl);
@@ -943,7 +930,7 @@ static void curl_close(BlockDriverState *bs)
 {
 BDRVCURLState *s = bs->opaque;
 
-DPRINTF("CURL: Close\n");
+trace_curl_close();
 curl_detach_aio_context(bs);
 qemu_mutex_destroy(>mutex);
 
diff --git a/block/trace-events b/block/trace-events
index bdd58f6226..8ea8d1eaeb 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -177,3 +177,12 @@ ssh_write(int64_t offset, size_t size) "offset=%" PRIi64 " 
size=%zu"
 ssh_write_buf(void *buf, size_t size) "sftp_write buf=%p size=%zu"
 ssh_write_return(ssize_t ret) "sftp_write returned %zd"
 ssh_seek(int64_t offset) "seeking to offset=%" PRIi64
+
+# block/curl.c
+curl_timer_cb(long timeout_ms) "timer callback timeout_ms %ld"
+curl_sock_cb(int action, int fd) "sock action %d on fd %d"
+curl_read_cb(size_t realsize) "just reading %zu bytes"
+curl_open(const char *file) "opening %s"
+curl_open_size(uint64_t size) "size = %" PRIu64
+curl_setup_preadv(uint64_t bytes, uint64_t start, const char *range) "reading 
%" PRIu64 " at %" PRIu64 " (%s)"
+curl_close(void) "close"
-- 
2.20.1




[Qemu-devel] [PULL 01/13] qapi: add x-debug-query-block-graph

2019-01-30 Thread Max Reitz
From: Vladimir Sementsov-Ogievskiy 

Add a new command, returning block nodes (and their users) graph.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Message-id: 20181221170909.25584-2-vsement...@virtuozzo.com
Signed-off-by: Max Reitz 
---
 qapi/block-core.json   | 108 
 include/block/block.h  |   1 +
 include/sysemu/block-backend.h |   2 +
 block.c| 148 +
 block/block-backend.c  |   5 ++
 blockdev.c |   5 ++
 6 files changed, 269 insertions(+)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 91685be6c2..cde1b53708 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1665,6 +1665,114 @@
 ##
 { 'command': 'query-named-block-nodes', 'returns': [ 'BlockDeviceInfo' ] }
 
+##
+# @XDbgBlockGraphNodeType:
+#
+# @block-backend: corresponds to BlockBackend
+#
+# @block-job: corresonds to BlockJob
+#
+# @block-driver: corresponds to BlockDriverState
+#
+# Since: 4.0
+##
+{ 'enum': 'XDbgBlockGraphNodeType',
+  'data': [ 'block-backend', 'block-job', 'block-driver' ] }
+
+##
+# @XDbgBlockGraphNode:
+#
+# @id: Block graph node identifier. This @id is generated only for
+#  x-debug-query-block-graph and does not relate to any other identifiers 
in
+#  Qemu.
+#
+# @type: Type of graph node. Can be one of block-backend, block-job or
+#block-driver-state.
+#
+# @name: Human readable name of the node. Corresponds to node-name for
+#block-driver-state nodes; is not guaranteed to be unique in the whole
+#graph (with block-jobs and block-backends).
+#
+# Since: 4.0
+##
+{ 'struct': 'XDbgBlockGraphNode',
+  'data': { 'id': 'uint64', 'type': 'XDbgBlockGraphNodeType', 'name': 'str' } }
+
+##
+# @BlockPermission:
+#
+# Enum of base block permissions.
+#
+# @consistent-read: A user that has the "permission" of consistent reads is
+#   guaranteed that their view of the contents of the block
+#   device is complete and self-consistent, representing the
+#   contents of a disk at a specific point.
+#   For most block devices (including their backing files) this
+#   is true, but the property cannot be maintained in a few
+#   situations like for intermediate nodes of a commit block
+#   job.
+#
+# @write: This permission is required to change the visible disk contents.
+#
+# @write-unchanged: This permission (which is weaker than BLK_PERM_WRITE) is
+#   both enough and required for writes to the block node when
+#   the caller promises that the visible disk content doesn't
+#   change.
+#   As the BLK_PERM_WRITE permission is strictly stronger,
+#   either is sufficient to perform an unchanging write.
+#
+# @resize: This permission is required to change the size of a block node.
+#
+# @graph-mod: This permission is required to change the node that this
+# BdrvChild points to.
+#
+# Since: 4.0
+##
+  { 'enum': 'BlockPermission',
+'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize',
+  'graph-mod' ] }
+##
+# @XDbgBlockGraphEdge:
+#
+# Block Graph edge description for x-debug-query-block-graph.
+#
+# @parent: parent id
+#
+# @child: child id
+#
+# @name: name of the relation (examples are 'file' and 'backing')
+#
+# @perm: granted permissions for the parent operating on the child
+#
+# @shared-perm: permissions that can still be granted to other users of the
+#   child while it is still attached to this parent
+#
+# Since: 4.0
+##
+{ 'struct': 'XDbgBlockGraphEdge',
+  'data': { 'parent': 'uint64', 'child': 'uint64',
+'name': 'str', 'perm': [ 'BlockPermission' ],
+'shared-perm': [ 'BlockPermission' ] } }
+
+##
+# @XDbgBlockGraph:
+#
+# Block Graph - list of nodes and list of edges.
+#
+# Since: 4.0
+##
+{ 'struct': 'XDbgBlockGraph',
+  'data': { 'nodes': ['XDbgBlockGraphNode'], 'edges': ['XDbgBlockGraphEdge'] } 
}
+
+##
+# @x-debug-query-block-graph:
+#
+# Get the block graph.
+#
+# Since: 4.0
+##
+{ 'command': 'x-debug-query-block-graph', 'returns': 'XDbgBlockGraph' }
+
 ##
 # @drive-mirror:
 #
diff --git a/include/block/block.h b/include/block/block.h
index f70a843b72..57233cf2c0 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -448,6 +448,7 @@ void bdrv_eject(BlockDriverState *bs, bool eject_flag);
 const char *bdrv_get_format_name(BlockDriverState *bs);
 BlockDriverState *bdrv_find_node(const char *node_name);
 BlockDeviceInfoList *bdrv_named_nodes_list(Error **errp);
+XDbgBlockGraph *bdrv_get_xdbg_block_graph(Error **errp);
 BlockDriverState *bdrv_lookup_bs(const char *device,
  const char *node_name,
  Error **errp);
diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h
index 

[Qemu-devel] [PULL 02/13] scripts: add render_block_graph function for QEMUMachine

2019-01-30 Thread Max Reitz
From: Vladimir Sementsov-Ogievskiy 

Render block nodes graph with help of graphviz. This new function is
for debugging, so there is no sense to put it into qemu.py as a method
of QEMUMachine. Let's instead put it separately.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Acked-by: Eduardo Habkost 
Reviewed-by: Max Reitz 
Message-id: 20181221170909.25584-3-vsement...@virtuozzo.com
Signed-off-by: Max Reitz 
---
 scripts/render_block_graph.py | 120 ++
 1 file changed, 120 insertions(+)
 create mode 100755 scripts/render_block_graph.py

diff --git a/scripts/render_block_graph.py b/scripts/render_block_graph.py
new file mode 100755
index 00..ed7e581b4f
--- /dev/null
+++ b/scripts/render_block_graph.py
@@ -0,0 +1,120 @@
+#!/usr/bin/env python
+#
+# Render Qemu Block Graph
+#
+# Copyright (c) 2018 Virtuozzo International GmbH. All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import os
+import sys
+import subprocess
+import json
+from graphviz import Digraph
+from qemu import MonitorResponseError
+
+
+def perm(arr):
+s = 'w' if 'write' in arr else '_'
+s += 'r' if 'consistent-read' in arr else '_'
+s += 'u' if 'write-unchanged' in arr else '_'
+s += 'g' if 'graph-mod' in arr else '_'
+s += 's' if 'resize' in arr else '_'
+return s
+
+
+def render_block_graph(qmp, filename, format='png'):
+'''
+Render graph in text (dot) representation into "@filename" and
+representation in @format into "@filename.@format"
+'''
+
+bds_nodes = qmp.command('query-named-block-nodes')
+bds_nodes = {n['node-name']: n for n in bds_nodes}
+
+job_nodes = qmp.command('query-block-jobs')
+job_nodes = {n['device']: n for n in job_nodes}
+
+block_graph = qmp.command('x-debug-query-block-graph')
+
+graph = Digraph(comment='Block Nodes Graph')
+graph.format = format
+graph.node('permission symbols:\l'
+   '  w - Write\l'
+   '  r - consistent-Read\l'
+   '  u - write - Unchanged\l'
+   '  g - Graph-mod\l'
+   '  s - reSize\l'
+   'edge label scheme:\l'
+   '  \l'
+   '  \l'
+   '  \l', shape='none')
+
+for n in block_graph['nodes']:
+if n['type'] == 'block-driver':
+info = bds_nodes[n['name']]
+label = n['name'] + ' [' + info['drv'] + ']'
+if info['drv'] == 'file':
+label += '\n' + os.path.basename(info['file'])
+shape = 'ellipse'
+elif n['type'] == 'block-job':
+info = job_nodes[n['name']]
+label = info['type'] + ' job (' + n['name'] + ')'
+shape = 'box'
+else:
+assert n['type'] == 'block-backend'
+label = n['name'] if n['name'] else 'unnamed blk'
+shape = 'box'
+
+graph.node(str(n['id']), label, shape=shape)
+
+for e in block_graph['edges']:
+label = '%s\l%s\l%s\l' % (e['name'], perm(e['perm']),
+  perm(e['shared-perm']))
+graph.edge(str(e['parent']), str(e['child']), label=label)
+
+graph.render(filename)
+
+
+class LibvirtGuest():
+def __init__(self, name):
+self.name = name
+
+def command(self, cmd):
+# only supports qmp commands without parameters
+m = {'execute': cmd}
+ar = ['virsh', 'qemu-monitor-command', self.name, json.dumps(m)]
+
+reply = json.loads(subprocess.check_output(ar))
+
+if 'error' in reply:
+raise MonitorResponseError(reply)
+
+return reply['return']
+
+
+if __name__ == '__main__':
+obj = sys.argv[1]
+out = sys.argv[2]
+
+if os.path.exists(obj):
+# assume unix socket
+qmp = QEMUMonitorProtocol(obj)
+qmp.connect()
+else:
+# assume libvirt guest name
+qmp = LibvirtGuest(obj)
+
+render_block_graph(qmp, out)
-- 
2.20.1




[Qemu-devel] [PULL 00/13] Block patches

2019-01-30 Thread Max Reitz
The following changes since commit b4fbe1f65a4769c09e6bf2d79fc84360f840f40e:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190129' 
into staging (2019-01-29 12:00:19 +)

are available in the Git repository at:

  https://git.xanclic.moe/XanClic/qemu.git tags/pull-block-2019-01-31

for you to fetch changes up to 908b30164bbffad7430d551b2a03a8fbcaa631ef:

  iotests: Allow 147 to be run concurrently (2019-01-31 00:44:55 +0100)


Block patches:
- New debugging QMP command to explore block graphs
- Converted DPRINTF()s to trace events
- Fixed qemu-io's use of getopt() for systems with optreset
- Minor NVMe emulation fixes
- An iotest fix


Laurent Vivier (4):
  block/ssh: Convert from DPRINTF() macro to trace events
  block/curl: Convert from DPRINTF() macro to trace events
  block/file-posix: Convert from DPRINTF() macro to trace events
  block/sheepdog: Convert from DPRINTF() macro to trace events

Li Qiang (3):
  nvme: use TYPE_NVME instead of constant string
  nvme: ensure the num_queues is not zero
  nvme: use pci_dev directly in nvme_realize

Max Reitz (3):
  iotests.py: Add qemu_nbd_pipe()
  iotests: Bind qemu-nbd to localhost in 147
  iotests: Allow 147 to be run concurrently

Richard W.M. Jones (1):
  qemu-io: Add generic function for reinitializing optind.

Vladimir Sementsov-Ogievskiy (2):
  qapi: add x-debug-query-block-graph
  scripts: add render_block_graph function for QEMUMachine

 configure  |  14 
 qapi/block-core.json   | 108 
 include/block/block.h  |   1 +
 include/qemu/osdep.h   |  16 
 include/sysemu/block-backend.h |   2 +
 block.c| 148 +
 block/block-backend.c  |   5 ++
 block/curl.c   |  29 ++-
 block/file-posix.c |  25 ++
 block/sheepdog.c   |  47 ---
 block/ssh.c|  46 --
 blockdev.c |   5 ++
 hw/block/nvme.c|  15 ++--
 qemu-img.c |   2 +-
 qemu-io-cmds.c |   2 +-
 block/trace-events |  47 +++
 scripts/render_block_graph.py  | 120 ++
 tests/qemu-iotests/147 |  98 +++---
 tests/qemu-iotests/iotests.py  |  14 
 19 files changed, 608 insertions(+), 136 deletions(-)
 create mode 100755 scripts/render_block_graph.py

-- 
2.20.1




[Qemu-devel] [PATCH] Fix for RSP vCont packet

2019-01-30 Thread Lucien Anti-Spam via Qemu-devel
This fixes a regression in rsp packet vCont due to recently added multiprocess 
support. (Short commit hash: e40e520).

The result is that vCont now does not recognise the case where no 
process/thread is provided after the action.
This may not show up with GDB, but using Lauterbach Trace32, and Hexrays IDA 
Pro this issue is immediately seen.The response is a "$#00" empty packet, 
showing it is unsupported packet.
This is defined in the RSP document as "An action with no thread-id matches all 
threads."(https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html#vCont-packet
 )
Thus the valid vCont packets now are as below, however parsing is still not 
very strict.  vCont;c/s                 - Step/Continue all threads  
vCont;c/s:[pX.]Y          - Step/Continue optional process X, thread Y  
vCont;C##/S##:[pX.]Y      - Step/Continue with signal ## on optional process X, 
thread Y  * If X or Y are -1 then it applies the action to all 
processes/threads.
Signed-off-by: Lucien Murray-Pitts --- gdbstub.c | 
16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/gdbstub.c b/gdbstub.cindex bfc7afb509..ce0dde2e24 100644--- 
a/gdbstub.c+++ b/gdbstub.c@@ -1169,6 +1169,7 @@ static int 
is_query_packet(const char *p, const char *query, char separator)  */ static 
int gdb_handle_vcont(GDBState *s, const char *p) {+    GDBThreadIdKind 
vcontThreadType ;     int res, signal = 0;     char cur_action;     char 
*newstates;@@ -1218,12 +1219,23 @@ static int gdb_handle_vcont(GDBState *s, 
const char *p)             goto out;         } -        if (*p++ != ':') {+     
   /*+         * In the case we have vCont;c or vCont;s - action is on all 
threads+         * Alternatively vCont;c;s:p1.1 is a possible, but meaningless 
format,+         * And in the else the "vCont;c:p1.1;... format is supported.+  
       */+        if (*p == '\0' || *p == ';') {+            vcontThreadType = 
GDB_ALL_THREADS ;+            pid = 1 ;+            tid = 1 ;+        } else if 
(*p++ == ':') {+            vcontThreadType = read_thread_id(p, , , ) 
;+        } else {             res = -ENOTSUP;             goto out;         } 
-        switch (read_thread_id(p, , , )) {+        switch 
(vcontThreadType) {         case GDB_READ_THREAD_ERR:             res = 
-EINVAL;             goto out;-- 2.17.2


Re: [Qemu-devel] [PATCH 12/18] Boot Linux Console Test: add a test for mips + malta

2019-01-30 Thread Cleber Rosa



On 1/22/19 5:16 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 1/17/19 7:56 PM, Cleber Rosa wrote:
>> From: Philippe Mathieu-Daudé 
>>
>> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
>> board and verify the serial is working.  Also, it relies on the serial
>> device set by the machine itself.
>>
>> If mips is a target being built, "make check-acceptance" will
>> automatically include this test by the use of the "arch:mips" tags.
>>
>> Alternatively, this test can be run using:
>>
>> $ avocado run -t arch:mips tests/acceptance
>> $ avocado run -t machine:malta tests/acceptance
>> $ avocado run -t endian:big tests/acceptance
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Cleber Rosa 
>> ---
>>  .travis.yml|  2 +-
>>  scripts/qemu.py|  1 -
>>  tests/acceptance/boot_linux_console.py | 20 
>>  3 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 844d514afa..49f9016e6a 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -187,7 +187,7 @@ matrix:
>>  
>>  # Acceptance (Functional) tests
>>  - env:
>> -- CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu"
>> +- CONFIG="--python=/usr/bin/python3 
>> --target-list=x86_64-softmmu,mips-softmmu"
>>  - TEST_CMD="make check-acceptance"
>>addons:
>>  apt:
>> diff --git a/scripts/qemu.py b/scripts/qemu.py
>> index 88e1608b42..ef84b0f843 100644
>> --- a/scripts/qemu.py
>> +++ b/scripts/qemu.py
>> @@ -35,7 +35,6 @@ def kvm_available(target_arch=None):
>>  #: Maps machine types to the preferred console device types
>>  CONSOLE_DEV_TYPES = {
>>  r'^clipper$': 'isa-serial',
>> -r'^malta': 'isa-serial',
>>  r'^(pc.*|q35.*|isapc)$': 'isa-serial',
>>  r'^(40p|powernv|prep)$': 'isa-serial',
>>  r'^pseries.*': 'spapr-vty',
>> diff --git a/tests/acceptance/boot_linux_console.py 
>> b/tests/acceptance/boot_linux_console.py
>> index 278bb2be3d..0678ec91d2 100644
>> --- a/tests/acceptance/boot_linux_console.py
>> +++ b/tests/acceptance/boot_linux_console.py
>> @@ -60,3 +60,23 @@ class BootLinuxConsole(Test):
>>  self.vm.launch()
>>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>>  self.wait_for_console_pattern(console_pattern)
>> +
>> +def test_mips_malta(self):
>> +"""
>> +:avocado: tags=arch:mips
>> +:avocado: tags=machine:malta
>> +:avocado: tags=endian:big
>> +"""
>> +kernel_url = ('http://people.debian.org/~aurel32/qemu/mips/'
>> +  'vmlinux-3.2.0-4-4kc-malta')
>> +kernel_hash = '592e384a4edc16dade52a6cd5c785c637bcbc9ad'
>> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> 
> Alex was concerned about using this "not-so-easily-reproducible" binary:
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08441.html
>

I clearly missed that.

> So I sent another patch using a reproducible one, which you reviewed:
> https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02747.html
> 

And I clearly forgot about that :)

> Do you mind base this series on it?
> 
> Thanks,
> 
> Phil.

Of course!  Thanks for pointing that out.

- Cleber.



Re: [Qemu-devel] [PATCH 10/18] Boot Linux Console Test: refactor the console watcher into utility method

2019-01-30 Thread Cleber Rosa



On 1/22/19 5:06 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 1/17/19 7:56 PM, Cleber Rosa wrote:
>> This introduces a utility method that monitors the console device and
>> looks for either a message that signals the test success or failure.
>>
>> Signed-off-by: Cleber Rosa 
>> ---
>>  tests/acceptance/boot_linux_console.py | 30 ++
>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/tests/acceptance/boot_linux_console.py 
>> b/tests/acceptance/boot_linux_console.py
>> index 35b31162d4..278bb2be3d 100644
>> --- a/tests/acceptance/boot_linux_console.py
>> +++ b/tests/acceptance/boot_linux_console.py
>> @@ -23,6 +23,25 @@ class BootLinuxConsole(Test):
>>  
>>  timeout = 60
>>  
>> +def wait_for_console_pattern(self, success_message,
>> + failure_message='Kernel panic - not 
>> syncing'):
>> +"""
>> +Waits for messages to appear on the console, while logging the 
>> content
>> +
>> +:param success_message: if this message appears, test succeeds
>> +:param failure_message: if this message appears, test fails
>> +"""
>> +console = self.vm.console_socket.makefile()
>> +console_logger = logging.getLogger('console')
>> +while True:
>> +msg = console.readline()
>> +console_logger.debug(msg.strip())
>> +if success_message in msg:
>> +break
>> +if failure_message in msg:
>> +fail = 'Failure message found in console: %s' % 
>> failure_message
>> +self.fail(fail)
>> +
> 
> This helper is more generic than the BootLinuxConsole class, can you
> move it out? I'd like to use it in test_uefi_ovmf_x86_64_pc and
> test_uefi_armvirtqemu_aarch64_virt.
> 
> Anyway this can be a follow-up patch, so regardless:
> Reviewed-by: Philippe Mathieu-Daudé 
> 

Sure thing, I'll work on something on top of this.  Tracking it here in
the mean time:

https://trello.com/c/oJtL1nRJ/78-create-utility-out-of-waitforconsolepattern

- Cleber.



[Qemu-devel] [PATCH 2/3] target/xtensa: add generic instruction post-processing

2019-01-30 Thread Max Filippov
Some opcodes may need additional actions at every exit from the
translated instruction or may need to amend TB exit slots available to
jumps generated for the instruction. Add gen_postprocess function and
call it from the gen_jump_slot and from the disas_xtensa_insn.

Signed-off-by: Max Filippov 
---
 target/xtensa/cpu.h   |  4 
 target/xtensa/translate.c | 33 +
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index b665bfc0068a..e1002c626954 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -368,9 +368,13 @@ enum {
 
 XTENSA_OP_DIVIDE_BY_ZERO = 0x100,
 
+/* Postprocessing flags */
 XTENSA_OP_CHECK_INTERRUPTS = 0x200,
 XTENSA_OP_EXIT_TB_M1 = 0x400,
 XTENSA_OP_EXIT_TB_0 = 0x800,
+XTENSA_OP_SYNC_REGISTER_WINDOW = 0x1000,
+
+XTENSA_OP_POSTPROCESS = 0x1e00,
 };
 
 typedef struct XtensaOpcodeOps {
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index b3718d33eec8..f5f5bcfb179a 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -71,6 +71,7 @@ struct DisasContext {
 
 unsigned cpenable;
 
+uint32_t op_flags;
 uint32_t *raw_arg;
 xtensa_insnbuf insnbuf;
 xtensa_insnbuf slotbuf;
@@ -363,6 +364,8 @@ static bool gen_check_cpenable(DisasContext *dc, uint32_t 
cp_mask)
 return true;
 }
 
+static int gen_postprocess(DisasContext *dc, int slot);
+
 static void gen_jump_slot(DisasContext *dc, TCGv dest, int slot)
 {
 tcg_gen_mov_i32(cpu_pc, dest);
@@ -372,6 +375,9 @@ static void gen_jump_slot(DisasContext *dc, TCGv dest, int 
slot)
 if (dc->base.singlestep_enabled) {
 gen_exception(dc, EXCP_DEBUG);
 } else {
+if (dc->op_flags & XTENSA_OP_POSTPROCESS) {
+slot = gen_postprocess(dc, slot);
+}
 if (slot >= 0) {
 tcg_gen_goto_tb(slot);
 tcg_gen_exit_tb(dc->base.tb, slot);
@@ -855,6 +861,19 @@ static inline unsigned xtensa_op0_insn_len(DisasContext 
*dc, uint8_t op0)
 return xtensa_isa_length_from_chars(dc->config->isa, );
 }
 
+static int gen_postprocess(DisasContext *dc, int slot)
+{
+uint32_t op_flags = dc->op_flags;
+
+if (op_flags & XTENSA_OP_CHECK_INTERRUPTS) {
+gen_check_interrupts(dc);
+}
+if (op_flags & XTENSA_OP_EXIT_TB_M1) {
+slot = -1;
+}
+return slot;
+}
+
 struct slot_prop {
 XtensaOpcodeOps *ops;
 uint32_t arg[MAX_OPCODE_ARGS];
@@ -1195,6 +1214,8 @@ static void disas_xtensa_insn(CPUXtensaState *env, 
DisasContext *dc)
 }
 }
 
+dc->op_flags = op_flags;
+
 for (slot = 0; slot < slots; ++slot) {
 struct slot_prop *pslot = ordered[slot];
 XtensaOpcodeOps *ops = pslot->ops;
@@ -1204,21 +1225,17 @@ static void disas_xtensa_insn(CPUXtensaState *env, 
DisasContext *dc)
 }
 
 if (dc->base.is_jmp == DISAS_NEXT) {
-if (op_flags & XTENSA_OP_CHECK_INTERRUPTS) {
-gen_check_interrupts(dc);
-}
-
+gen_postprocess(dc, 0);
+dc->op_flags = 0;
 if (op_flags & XTENSA_OP_EXIT_TB_M1) {
 /* Change in mmu index, memory mapping or tb->flags; exit tb */
 gen_jumpi_check_loop_end(dc, -1);
 } else if (op_flags & XTENSA_OP_EXIT_TB_0) {
 gen_jumpi_check_loop_end(dc, 0);
+} else {
+gen_check_loop_end(dc, 0);
 }
 }
-
-if (dc->base.is_jmp == DISAS_NEXT) {
-gen_check_loop_end(dc, 0);
-}
 dc->pc = dc->base.pc_next;
 }
 
-- 
2.11.0




[Qemu-devel] [PATCH 1/3] target/xtensa: sort FLIX instruction opcodes

2019-01-30 Thread Max Filippov
Opcodes in different slots may read and write same resources (registers,
states). In the absence of resource dependency loops it must be possible
to sort opcodes to avoid interference.

Record resources used by each opcode in the bundle. Build opcode
dependency graph and use topological sort to order its nodes. In case of
success translate opcodes in sort order. In case of failure report and
raise invalid opcode exception for now.

Signed-off-by: Max Filippov 
---
 target/xtensa/translate.c | 202 --
 1 file changed, 194 insertions(+), 8 deletions(-)

diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index a068b6e8335d..b3718d33eec8 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -855,6 +855,138 @@ static inline unsigned xtensa_op0_insn_len(DisasContext 
*dc, uint8_t op0)
 return xtensa_isa_length_from_chars(dc->config->isa, );
 }
 
+struct slot_prop {
+XtensaOpcodeOps *ops;
+uint32_t arg[MAX_OPCODE_ARGS];
+uint32_t raw_arg[MAX_OPCODE_ARGS];
+uint32_t in[MAX_OPCODE_ARGS];
+uint32_t out[MAX_OPCODE_ARGS];
+unsigned n_in;
+unsigned n_out;
+};
+
+enum resource_type {
+XTENSA_CONTROL_FLOW, /* must be first, see op_depends_on */
+XTENSA_REGFILE,
+XTENSA_STATE,
+};
+
+static uint32_t encode_resource(enum resource_type r, unsigned g, unsigned n)
+{
+assert(r < 256 && g < 256 && n < 65536);
+return (r << 24) | (g << 16) | n;
+}
+
+static bool op_depends_on(const struct slot_prop *a,
+  const struct slot_prop *b)
+{
+unsigned i = 0;
+unsigned j = 0;
+
+if (a->n_out && a->out[0] == encode_resource(XTENSA_CONTROL_FLOW, 0, 0)) {
+return true;
+}
+while (i < a->n_out && j < b->n_in) {
+if (a->out[i] < b->in[j]) {
+++i;
+} else if (a->out[i] > b->in[j]) {
+++j;
+} else {
+return true;
+}
+}
+return false;
+}
+
+static bool tsort(struct slot_prop *slot,
+  struct slot_prop *sorted[],
+  unsigned n)
+{
+struct {
+unsigned n_in_edge;
+unsigned n_out_edge;
+unsigned out_edge[MAX_INSN_SLOTS];
+} node[MAX_INSN_SLOTS];
+
+unsigned in[MAX_INSN_SLOTS];
+unsigned i, j;
+unsigned n_in = 0;
+unsigned n_out = 0;
+unsigned n_edge = 0;
+
+for (i = 0; i < n; ++i) {
+node[i].n_in_edge = 0;
+node[i].n_out_edge = 0;
+}
+
+for (i = 0; i < n; ++i) {
+unsigned n_out_edge = 0;
+
+for (j = 0; j < n; ++j) {
+if (i != j && op_depends_on(slot + j, slot + i)) {
+node[i].out_edge[n_out_edge] = j;
+++node[j].n_in_edge;
+++n_out_edge;
+++n_edge;
+}
+}
+node[i].n_out_edge = n_out_edge;
+}
+
+for (i = 0; i < n; ++i) {
+if (!node[i].n_in_edge) {
+in[n_in] = i;
+++n_in;
+}
+}
+
+for (i = 0; i < n_in; ++i) {
+unsigned k = in[i];
+
+sorted[n_out] = slot + k;
+++n_out;
+for (j = 0; j < node[k].n_out_edge; ++j) {
+--n_edge;
+if (--node[node[k].out_edge[j]].n_in_edge == 0) {
+in[n_in] = node[k].out_edge[j];
+++n_in;
+}
+}
+}
+return n_edge == 0;
+}
+
+static void opcode_add_resource(struct slot_prop *op,
+uint32_t resource, char direction)
+{
+switch (direction) {
+case 'i':
+assert(op->n_in < ARRAY_SIZE(op->in));
+op->in[op->n_in++] = resource;
+break;
+case 'o':
+assert(op->n_out < ARRAY_SIZE(op->out));
+op->out[op->n_out++] = resource;
+break;
+case 'm':
+assert(op->n_in < ARRAY_SIZE(op->in));
+assert(op->n_out < ARRAY_SIZE(op->out));
+op->in[op->n_in++] = resource;
+op->out[op->n_out++] = resource;
+break;
+default:
+g_assert_not_reached();
+}
+}
+
+static int resource_compare(const void *a, const void *b)
+{
+const uint32_t *pa = a;
+const uint32_t *pb = b;
+
+return *pa < *pb ? -1 : (*pa > *pb ? 1 : 0);
+}
+
 static void disas_xtensa_insn(CPUXtensaState *env, DisasContext *dc)
 {
 xtensa_isa isa = dc->config->isa;
@@ -864,11 +996,8 @@ static void disas_xtensa_insn(CPUXtensaState *env, 
DisasContext *dc)
 int slot, slots;
 unsigned i;
 uint32_t op_flags = 0;
-struct {
-XtensaOpcodeOps *ops;
-uint32_t arg[MAX_OPCODE_ARGS];
-uint32_t raw_arg[MAX_OPCODE_ARGS];
-} slot_prop[MAX_INSN_SLOTS];
+struct slot_prop slot_prop[MAX_INSN_SLOTS];
+struct slot_prop *ordered[MAX_INSN_SLOTS];
 uint32_t debug_cause = 0;
 uint32_t windowed_register = 0;
 uint32_t coprocessor = 0;
@@ -963,6 +1092,62 @@ static void disas_xtensa_insn(CPUXtensaState *env, 
DisasContext *dc)
 }
  

[Qemu-devel] [PATCH 3/3] target/xtensa: move WINDOW_BASE SR update to postprocessing

2019-01-30 Thread Max Filippov
Opcodes that modify WINDOW_BASE SR don't have dependency on opcodes that
use windowed registers. If such opcodes are combined in a single
instruction they may not be correctly ordered. Instead of adding said
dependency use temporary register to store changed WINDOW_BASE value and
do actual register window rotation as a postprocessing step.
Not all opcodes that change WINDOW_BASE need this: retw, rfwo and rfwu
are also jump opcodes, so they are guaranteed to be translated last and
thus will not affect other opcodes in the same instruction.

Signed-off-by: Max Filippov 
---
 target/xtensa/cpu.h|  1 +
 target/xtensa/helper.h |  3 +--
 target/xtensa/translate.c  | 30 ++
 target/xtensa/win_helper.c | 14 --
 4 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index e1002c626954..c2b492e175bd 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -478,6 +478,7 @@ typedef struct CPUXtensaState {
 float64 f64;
 } fregs[16];
 float_status fp_status;
+uint32_t windowbase_next;
 
 #ifndef CONFIG_USER_ONLY
 xtensa_tlb_entry itlb[7][MAX_TLB_WAY_SIZE];
diff --git a/target/xtensa/helper.h b/target/xtensa/helper.h
index 2a7db35874fe..b6529a8925f3 100644
--- a/target/xtensa/helper.h
+++ b/target/xtensa/helper.h
@@ -3,12 +3,11 @@ DEF_HELPER_3(exception_cause, noreturn, env, i32, i32)
 DEF_HELPER_4(exception_cause_vaddr, noreturn, env, i32, i32, i32)
 DEF_HELPER_3(debug_exception, noreturn, env, i32, i32)
 
-DEF_HELPER_2(wsr_windowbase, void, env, i32)
+DEF_HELPER_1(sync_windowbase, void, env)
 DEF_HELPER_4(entry, void, env, i32, i32, i32)
 DEF_HELPER_2(test_ill_retw, void, env, i32)
 DEF_HELPER_2(test_underflow_retw, void, env, i32)
 DEF_HELPER_2(retw, i32, env, i32)
-DEF_HELPER_2(rotw, void, env, i32)
 DEF_HELPER_3(window_check, noreturn, env, i32, i32)
 DEF_HELPER_1(restore_owb, void, env)
 DEF_HELPER_2(movsp, void, env, i32)
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index f5f5bcfb179a..a61598030dee 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -82,6 +82,7 @@ static TCGv_i32 cpu_R[16];
 static TCGv_i32 cpu_FR[16];
 static TCGv_i32 cpu_SR[256];
 static TCGv_i32 cpu_UR[256];
+static TCGv_i32 cpu_windowbase_next;
 
 #include "exec/gen-icount.h"
 
@@ -253,6 +254,11 @@ void xtensa_translate_init(void)
 uregnames[i].name);
 }
 }
+
+cpu_windowbase_next =
+tcg_global_mem_new_i32(cpu_env,
+   offsetof(CPUXtensaState, windowbase_next),
+   "windowbase_next");
 }
 
 static inline bool option_enabled(DisasContext *dc, int opt)
@@ -566,7 +572,7 @@ static void gen_wsr_acchi(DisasContext *dc, uint32_t sr, 
TCGv_i32 s)
 #ifndef CONFIG_USER_ONLY
 static void gen_wsr_windowbase(DisasContext *dc, uint32_t sr, TCGv_i32 v)
 {
-gen_helper_wsr_windowbase(cpu_env, v);
+tcg_gen_mov_i32(cpu_windowbase_next, v);
 }
 
 static void gen_wsr_windowstart(DisasContext *dc, uint32_t sr, TCGv_i32 v)
@@ -868,6 +874,9 @@ static int gen_postprocess(DisasContext *dc, int slot)
 if (op_flags & XTENSA_OP_CHECK_INTERRUPTS) {
 gen_check_interrupts(dc);
 }
+if (op_flags & XTENSA_OP_SYNC_REGISTER_WINDOW) {
+gen_helper_sync_windowbase(cpu_env);
+}
 if (op_flags & XTENSA_OP_EXIT_TB_M1) {
 slot = -1;
 }
@@ -2270,9 +2279,7 @@ static void translate_rfw(DisasContext *dc, const 
uint32_t arg[],
 static void translate_rotw(DisasContext *dc, const uint32_t arg[],
const uint32_t par[])
 {
-TCGv_i32 tmp = tcg_const_i32(arg[0]);
-gen_helper_rotw(cpu_env, tmp);
-tcg_temp_free(tmp);
+tcg_gen_addi_i32(cpu_windowbase_next, cpu_SR[WINDOW_BASE], arg[0]);
 }
 
 static void translate_rsil(DisasContext *dc, const uint32_t arg[],
@@ -3092,7 +3099,8 @@ static const XtensaOpcodeOps core_ops[] = {
 .translate = translate_entry,
 .test_ill = test_ill_entry,
 .test_overflow = test_overflow_entry,
-.op_flags = XTENSA_OP_EXIT_TB_M1,
+.op_flags = XTENSA_OP_EXIT_TB_M1 |
+XTENSA_OP_SYNC_REGISTER_WINDOW,
 }, {
 .name = "esync",
 .translate = translate_nop,
@@ -3781,7 +3789,9 @@ static const XtensaOpcodeOps core_ops[] = {
 }, {
 .name = "rotw",
 .translate = translate_rotw,
-.op_flags = XTENSA_OP_PRIVILEGED | XTENSA_OP_EXIT_TB_M1,
+.op_flags = XTENSA_OP_PRIVILEGED |
+XTENSA_OP_EXIT_TB_M1 |
+XTENSA_OP_SYNC_REGISTER_WINDOW,
 }, {
 .name = "rsil",
 .translate = translate_rsil,
@@ -5044,7 +5054,9 @@ static const XtensaOpcodeOps core_ops[] = {
 .translate = translate_wsr,
 .test_ill = test_ill_wsr,
 .par = (const uint32_t[]){WINDOW_BASE},
-.op_flags = XTENSA_OP_PRIVILEGED | XTENSA_OP_EXIT_TB_M1,
+.op_flags = XTENSA_OP_PRIVILEGED |
+ 

[Qemu-devel] [PATCH 0/3] target/xtensa: add basic FLIX support

2019-01-30 Thread Max Filippov
Hello,

this series adds limited support for FLIX instructions.
FLIX (flexible length instruction extensions) allows bundling multiple
opcodes in a single instruction. Each opcode is executed as if it was
the only opcode in the instruction. Opcodes may not simultaneously
modify same resource (register or state). Multiple branches, even
non-taken, are also not allowed in one instruction. 
Instructions with opcodes that have circular dependencies between used
resources (e.g. opcode A uses resource U and modifies resource M, while
opcode B uses resource M and modifies resource U) are not supported in
this series.

Max Filippov (3):
  target/xtensa: sort FLIX instruction opcodes
  target/xtensa: add generic instruction post-processing
  target/xtensa: move WINDOW_BASE SR update to postprocessing

 target/xtensa/cpu.h|   5 +
 target/xtensa/helper.h |   3 +-
 target/xtensa/translate.c  | 265 +
 target/xtensa/win_helper.c |  14 +--
 4 files changed, 251 insertions(+), 36 deletions(-)

-- 
2.11.0




[Qemu-devel] [PATCH] iotests: Filter second BLOCK_JOB_ERROR from 229

2019-01-30 Thread Max Reitz
Without this filter, this test sometimes fails.

Signed-off-by: Max Reitz 
---
I intended to send this as part of my iotest fixes series, but it ended
up on the wrong branch...  Doesn't really matter, though, as there is no
functional dependency.
---
 tests/qemu-iotests/229 | 6 +-
 tests/qemu-iotests/229.out | 1 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/229 b/tests/qemu-iotests/229
index 893d098ad2..b0d4885fa6 100755
--- a/tests/qemu-iotests/229
+++ b/tests/qemu-iotests/229
@@ -81,11 +81,15 @@ echo
 echo '=== Force cancel job paused in error state  ==='
 echo
 
+# Filter out BLOCK_JOB_ERROR events because they may or may not occur.
+# Cancelling the job means resuming it for a bit before it is actually
+# aborted, and in that time it may or may not re-encounter the error.
 success_or_failure="y" _send_qemu_cmd $QEMU_HANDLE \
 "{'execute': 'block-job-cancel',
  'arguments': { 'device': 'testdisk',
 'force': true}}" \
- "BLOCK_JOB_CANCELLED" "Assertion"
+ "BLOCK_JOB_CANCELLED" "Assertion" \
+| grep -v '"BLOCK_JOB_ERROR"'
 
 # success, all done
 echo "*** done"
diff --git a/tests/qemu-iotests/229.out b/tests/qemu-iotests/229.out
index 4c4112805f..a3eb33788a 100644
--- a/tests/qemu-iotests/229.out
+++ b/tests/qemu-iotests/229.out
@@ -17,7 +17,6 @@ wrote 2097152/2097152 bytes at offset 0
 
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "running", "id": "testdisk"}}
 {"return": {}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"BLOCK_JOB_ERROR", "data": {"device": "testdisk", "operation": "write", 
"action": "stop"}}
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "aborting", "id": "testdisk"}}
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"BLOCK_JOB_CANCELLED", "data": {"device": "testdisk", "len": 2097152, "offset": 
1048576, "speed": 0, "type": "mirror"}}
 *** done
-- 
2.20.1




[Qemu-devel] [PATCH 2/2] mmap-alloc: fix hugetlbfs misaligned length in ppc64

2019-01-30 Thread Murilo Opsfelder Araujo
The commit 7197fb4058bcb68986bae2bb2c04d6370f3e7218 ("util/mmap-alloc:
fix hugetlb support on ppc64") fixed Huge TLB mappings on ppc64.

However, we still need to consider the underlying huge page size
during munmap() because it requires that both address and length be a
multiple of the underlying huge page size for Huge TLB mappings.
Quote from "Huge page (Huge TLB) mappings" paragraph under NOTES
section of the munmap(2) manual:

  "For munmap(), addr and length must both be a multiple of the
  underlying huge page size."

On ppc64, the munmap() in qemu_ram_munmap() does not work for Huge TLB
mappings because the mapped segment can be aligned with the underlying
huge page size, not aligned with the native system page size, as
returned by getpagesize().

This has the side effect of not releasing huge pages back to the pool
after a hugetlbfs file-backed memory device is hot-unplugged.

This patch fixes the situation in qemu_ram_mmap() and
qemu_ram_munmap() by considering the underlying page size on ppc64.

After this patch, memory hot-unplug releases huge pages back to the
pool.

Fixes: 7197fb4058bcb68986bae2bb2c04d6370f3e7218
Signed-off-by: Murilo Opsfelder Araujo 
---
 exec.c|  4 ++--
 include/qemu/mmap-alloc.h |  2 +-
 util/mmap-alloc.c | 22 --
 util/oslib-posix.c|  2 +-
 4 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/exec.c b/exec.c
index da3e635f91..0db6d8bf34 100644
--- a/exec.c
+++ b/exec.c
@@ -1871,7 +1871,7 @@ static void *file_ram_alloc(RAMBlock *block,
 if (mem_prealloc) {
 os_mem_prealloc(fd, area, memory, smp_cpus, errp);
 if (errp && *errp) {
-qemu_ram_munmap(area, memory);
+qemu_ram_munmap(fd, area, memory);
 return NULL;
 }
 }
@@ -2392,7 +2392,7 @@ static void reclaim_ramblock(RAMBlock *block)
 xen_invalidate_map_cache_entry(block->host);
 #ifndef _WIN32
 } else if (block->fd >= 0) {
-qemu_ram_munmap(block->host, block->max_length);
+qemu_ram_munmap(block->fd, block->host, block->max_length);
 close(block->fd);
 #endif
 } else {
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index 50385e3f81..ef04f0ed5b 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-alloc.h
@@ -9,6 +9,6 @@ size_t qemu_mempath_getpagesize(const char *mem_path);
 
 void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared);
 
-void qemu_ram_munmap(void *ptr, size_t size);
+void qemu_ram_munmap(int fd, void *ptr, size_t size);
 
 #endif
diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
index f71ea038c8..8565885420 100644
--- a/util/mmap-alloc.c
+++ b/util/mmap-alloc.c
@@ -80,6 +80,7 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
 int flags;
 int guardfd;
 size_t offset;
+size_t pagesize;
 size_t total;
 void *guardptr;
 void *ptr;
@@ -100,7 +101,8 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
  * anonymous memory is OK.
  */
 flags = MAP_PRIVATE;
-if (fd == -1 || qemu_fd_getpagesize(fd) == getpagesize()) {
+pagesize = qemu_fd_getpagesize(fd);
+if (fd == -1 || pagesize == getpagesize()) {
 guardfd = -1;
 flags |= MAP_ANONYMOUS;
 } else {
@@ -109,6 +111,7 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
 }
 #else
 guardfd = -1;
+pagesize = getpagesize();
 flags = MAP_PRIVATE | MAP_ANONYMOUS;
 #endif
 
@@ -120,7 +123,7 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
 
 assert(is_power_of_2(align));
 /* Always align to host page size */
-assert(align >= getpagesize());
+assert(align >= pagesize);
 
 flags = MAP_FIXED;
 flags |= fd == -1 ? MAP_ANONYMOUS : 0;
@@ -143,17 +146,24 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, 
bool shared)
  * a guard page guarding against potential buffer overflows.
  */
 total -= offset;
-if (total > size + getpagesize()) {
-munmap(ptr + size + getpagesize(), total - size - getpagesize());
+if (total > size + pagesize) {
+munmap(ptr + size + pagesize, total - size - pagesize);
 }
 
 return ptr;
 }
 
-void qemu_ram_munmap(void *ptr, size_t size)
+void qemu_ram_munmap(int fd, void *ptr, size_t size)
 {
+size_t pagesize;
+
 if (ptr) {
 /* Unmap both the RAM block and the guard page */
-munmap(ptr, size + getpagesize());
+#if defined(__powerpc64__) && defined(__linux__)
+pagesize = qemu_fd_getpagesize(fd);
+#else
+pagesize = getpagesize();
+#endif
+munmap(ptr, size + pagesize);
 }
 }
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 4ce1ba9ca4..37c5854b9c 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -226,7 +226,7 @@ void qemu_vfree(void *ptr)
 void qemu_anon_ram_free(void *ptr, size_t size)
 {
 trace_qemu_anon_ram_free(ptr, size);
-

[Qemu-devel] [PATCH 1/2] mmap-alloc: unfold qemu_ram_mmap()

2019-01-30 Thread Murilo Opsfelder Araujo
Unfold parts of qemu_ram_mmap() for the sake of understanding, moving
declarations to the top, and keeping architecture-specifics in the
ifdef-else blocks.  No changes in the function behaviour.

Give ptr and ptr1 meaningful names:
  ptr  -> guardptr : pointer to the PROT_NONE guard region
  ptr1 -> ptr  : pointer to the mapped memory returned to caller

Signed-off-by: Murilo Opsfelder Araujo 
---
 util/mmap-alloc.c | 53 ++-
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
index fd329eccd8..f71ea038c8 100644
--- a/util/mmap-alloc.c
+++ b/util/mmap-alloc.c
@@ -77,11 +77,19 @@ size_t qemu_mempath_getpagesize(const char *mem_path)
 
 void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
 {
+int flags;
+int guardfd;
+size_t offset;
+size_t total;
+void *guardptr;
+void *ptr;
+
 /*
  * Note: this always allocates at least one extra page of virtual address
  * space, even if size is already aligned.
  */
-size_t total = size + align;
+total = size + align;
+
 #if defined(__powerpc64__) && defined(__linux__)
 /* On ppc64 mappings in the same segment (aka slice) must share the same
  * page size. Since we will be re-allocating part of this segment
@@ -91,16 +99,22 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
  * We do this unless we are using the system page size, in which case
  * anonymous memory is OK.
  */
-int anonfd = fd == -1 || qemu_fd_getpagesize(fd) == getpagesize() ? -1 : 
fd;
-int flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;
-void *ptr = mmap(0, total, PROT_NONE, flags | MAP_PRIVATE, anonfd, 0);
+flags = MAP_PRIVATE;
+if (fd == -1 || qemu_fd_getpagesize(fd) == getpagesize()) {
+guardfd = -1;
+flags |= MAP_ANONYMOUS;
+} else {
+guardfd = fd;
+flags |= MAP_NORESERVE;
+}
 #else
-void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+guardfd = -1;
+flags = MAP_PRIVATE | MAP_ANONYMOUS;
 #endif
-size_t offset;
-void *ptr1;
 
-if (ptr == MAP_FAILED) {
+guardptr = mmap(0, total, PROT_NONE, flags, guardfd, 0);
+
+if (guardptr == MAP_FAILED) {
 return MAP_FAILED;
 }
 
@@ -108,19 +122,20 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, 
bool shared)
 /* Always align to host page size */
 assert(align >= getpagesize());
 
-offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
-ptr1 = mmap(ptr + offset, size, PROT_READ | PROT_WRITE,
-MAP_FIXED |
-(fd == -1 ? MAP_ANONYMOUS : 0) |
-(shared ? MAP_SHARED : MAP_PRIVATE),
-fd, 0);
-if (ptr1 == MAP_FAILED) {
-munmap(ptr, total);
+flags = MAP_FIXED;
+flags |= fd == -1 ? MAP_ANONYMOUS : 0;
+flags |= shared ? MAP_SHARED : MAP_PRIVATE;
+offset = QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guardptr;
+
+ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE, flags, fd, 0);
+
+if (ptr == MAP_FAILED) {
+munmap(guardptr, total);
 return MAP_FAILED;
 }
 
 if (offset > 0) {
-munmap(ptr, offset);
+munmap(guardptr, offset);
 }
 
 /*
@@ -129,10 +144,10 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, 
bool shared)
  */
 total -= offset;
 if (total > size + getpagesize()) {
-munmap(ptr1 + size + getpagesize(), total - size - getpagesize());
+munmap(ptr + size + getpagesize(), total - size - getpagesize());
 }
 
-return ptr1;
+return ptr;
 }
 
 void qemu_ram_munmap(void *ptr, size_t size)
-- 
2.20.1




[Qemu-devel] [PATCH 0/2] mmap-alloc: fix hugetlbfs misaligned length in ppc64

2019-01-30 Thread Murilo Opsfelder Araujo
The first patch unfolds parts of qemu_ram_mmap() to make it clearer.
No changes in the function behaviour.

The second one fixes the alignment of the length given to munmap().

I am pretty sure there is room for improvement, so I would love to
hear your feedback.

Thank you!

Murilo Opsfelder Araujo (2):
  mmap-alloc: unfold qemu_ram_mmap()
  mmap-alloc: fix hugetlbfs misaligned length in ppc64

 exec.c|  4 +--
 include/qemu/mmap-alloc.h |  2 +-
 util/mmap-alloc.c | 73 ++-
 util/oslib-posix.c|  2 +-
 4 files changed, 53 insertions(+), 28 deletions(-)

--
2.20.1




Re: [Qemu-devel] [PATCH 0/2] qemu-macppc patches

2019-01-30 Thread David Gibson
On Mon, Jan 28, 2019 at 09:21:55PM +, Mark Cave-Ayland wrote:
> Here's the contents of my qemu-macppc branch: just two minor patches 
> consisting of
> an update to MAINTAINERS, plus bringing in updated binaries containing 
> bugfixes
> for Ben's MacOS NDRV VGA driver.

Applied to ppc-for-4.0, thanks.

Sorry for the delay, I had been intending to merge this in from your
git tree as discussed, but hit some conflicts that I didn't get around
to resolving.

> Signed-off-by: Mark Cave-Ayland 
> 
> Mark Cave-Ayland (2):
>   MAINTAINERS: add myself as maintainer for Mac Old World and New World
> machines
>   QemuMacDrivers: update qemu_vga.ndrv to 90c488d built from submodule
> 
>  MAINTAINERS   |   6 --
>  pc-bios/qemu_vga.ndrv | Bin 14752 -> 18752 bytes
>  roms/QemuMacDrivers   |   2 +-
>  3 files changed, 5 insertions(+), 3 deletions(-)
> 

-- 
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 v2 10/10] iotests.py: s/_/-/g on keys in qmp_log()

2019-01-30 Thread John Snow



On 1/30/19 10:24 AM, Max Reitz wrote:
> This follows what qmp() does, so the output will correspond to the
> actual QMP command.
> 
> Signed-off-by: Max Reitz 

Reviewed-by: John Snow 

Thank you!



Re: [Qemu-devel] [PATCH] MAINTAINERS: Merge the two e500 sections

2019-01-30 Thread David Gibson
On Wed, Jan 30, 2019 at 05:22:25PM +0100, Thomas Huth wrote:
> There is currently a "e500" machine section and a "ppce500" device
> section in the maintainers file - with some oddities: The wildcard
> in the device section also covers the files from the machine section.
> And hw/pci-host/ppce500.c is in the device section, while its header
> is in the machine section.
> This is really quite confusing, and I don't see a reason why we really
> need two sections here, so let's simply merge them.
> 
> Signed-off-by: Thomas Huth 

Applied to ppc-for-4.0, thanks.

> ---
>  MAINTAINERS | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eac36b6..30dbe37 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -957,9 +957,10 @@ e500
>  M: David Gibson 
>  L: qemu-...@nongnu.org
>  S: Odd Fixes
> -F: hw/ppc/e500.[hc]
> -F: hw/ppc/e500plat.c
> +F: hw/ppc/e500*
>  F: hw/gpio/mpc8xxx.c
> +F: hw/net/fsl_etsec/
> +F: hw/pci-host/ppce500.c
>  F: include/hw/ppc/ppc_e500.h
>  F: include/hw/pci-host/ppce500.h
>  F: pc-bios/u-boot.e500
> @@ -1316,14 +1317,6 @@ F: hw/i2c/ppc4xx_i2c.c
>  F: include/hw/ppc/ppc4xx.h
>  F: include/hw/i2c/ppc4xx_i2c.h
>  
> -ppce500
> -M: David Gibson 
> -L: qemu-...@nongnu.org
> -S: Odd Fixes
> -F: hw/ppc/e500*
> -F: hw/pci-host/ppce500.c
> -F: hw/net/fsl_etsec/
> -
>  Character devices
>  M: Marc-André Lureau 
>  R: Paolo Bonzini 

-- 
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] [Qemu-ppc] [PATCH qemu] spapr: Drop unused parameters from fdt building helper

2019-01-30 Thread David Gibson
On Wed, Jan 30, 2019 at 05:53:16PM +0100, Greg Kurz wrote:
> On Wed, 30 Jan 2019 17:43:44 +0100
> Philippe Mathieu-Daudé  wrote:
> 
> > Hi Alexey,
> > 
> > On 1/30/19 1:43 PM, Greg Kurz wrote:
> > > On Wed, 30 Jan 2019 12:42:16 +1100
> > > Alexey Kardashevskiy  wrote:
> > >   
> > >> spapr_load_rtas() handles now RTAS address and size information in the 
> > >> FDT
> > >> so drop them from spapr_build_fdt().
> > >>
> > >> While we are here, fix a small typo.
> > >>
> > >> Fixes: 2cac78c12ade9 "pseries: Consolidate RTAS loading"  
> > > 
> > > One nit. The last rtas_* user in spapr_build_fdt() was removed by the
> > > following hunk:
> > > 
> > > @@ -949,12 +966,6 @@ static void *spapr_build_fdt(sPAPRMachineState 
> > > *spapr,
> > >  }
> > >  }
> > >  
> > > -/* RTAS */
> > > -ret = spapr_rtas_device_tree_setup(fdt, rtas_addr, rtas_size);
> > > -if (ret < 0) {
> > > -error_report("Couldn't set up RTAS device tree properties");
> > > -}
> > > -
> > >  /* cpus */
> > >  spapr_populate_cpus_dt_node(fdt, spapr);
> > >  
> > > from commit:
> > > 
> > > 3f5dabceba24 "pseries: Consolidate construction of /rtas device tree 
> > > node"  
> > 
> > Can you (or David if he agrees) add a line about since when/why it is no
> > more required?
> > 
> 
> Commit 3f5dabceba24 (first released in QEMU 2.10) simply moved the FDT code
> for RTAS to some other function, leaving the rtas_addr and rtas_size arguments
> unused in spapr_build_fdt(). This patch is a trivial cleanup really.

Applied to ppc-for-4.0, with the Fixes line adjusted as suggested.

> 
> > > Reviewed-by: Greg Kurz 
> > >   
> > >> Signed-off-by: Alexey Kardashevskiy   
> > 
> > Reviewed-by: Philippe Mathieu-Daudé 
> > 
> > >> ---
> > >>  hw/ppc/spapr.c | 8 +++-
> > >>  1 file changed, 3 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > >> index a217c7f..fa12723 100644
> > >> --- a/hw/ppc/spapr.c
> > >> +++ b/hw/ppc/spapr.c
> > >> @@ -1225,9 +1225,7 @@ static void spapr_dt_hypervisor(sPAPRMachineState 
> > >> *spapr, void *fdt)
> > >>  }
> > >>  }
> > >>  
> > >> -static void *spapr_build_fdt(sPAPRMachineState *spapr,
> > >> - hwaddr rtas_addr,
> > >> - hwaddr rtas_size)
> > >> +static void *spapr_build_fdt(sPAPRMachineState *spapr)
> > >>  {
> > >>  MachineState *machine = MACHINE(spapr);
> > >>  MachineClass *mc = MACHINE_GET_CLASS(machine);
> > >> @@ -1644,14 +1642,14 @@ static void spapr_machine_reset(void)
> > >>  
> > >>  /*
> > >>   * We place the device tree and RTAS just below either the top of 
> > >> the RMA,
> > >> - * or just below 2GB, whichever is lowere, so that it can be
> > >> + * or just below 2GB, whichever is lower, so that it can be
> > >>   * processed with 32-bit real mode code if necessary
> > >>   */
> > >>  rtas_limit = MIN(spapr->rma_size, RTAS_MAX_ADDR);
> > >>  rtas_addr = rtas_limit - RTAS_MAX_SIZE;
> > >>  fdt_addr = rtas_addr - FDT_MAX_SIZE;
> > >>  
> > >> -fdt = spapr_build_fdt(spapr, rtas_addr, spapr->rtas_size);
> > >> +fdt = spapr_build_fdt(spapr);
> > >>  
> > >>  spapr_load_rtas(spapr, fdt, rtas_addr);
> > >>
> > > 
> > >   
> 

-- 
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 v8 0/2] qemu-img info lists bitmap directory entries

2019-01-30 Thread John Snow



On 1/29/19 11:01 PM, Eric Blake wrote:
> On 1/28/19 12:40 PM, Andrey Shinkevich wrote:
>> Here is the update for the bitmap extension of the qcow2 specific
>> information as the output of the 'qemu-img info' command.
>> The version #7 was in email with the message ID:
>> <1544698788-52893-1-git-send-email-andrey.shinkev...@virtuozzo.com>
>>
>> v8:
>> The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
>> and 206, were modified to show the bitmap extension for the qemu specific
>> information. A new test file 239 was added to the test set that checks the
>> output for the fields of the bitmap section.
>> The backward compatibility of the output for images of the version 2
>> of qcow2 was added.
> 
> So, I'm trying to test this, and I've discovered something rather
> annoying about persistent snapshots: they DON'T get written to disk
> until the qemu process exits.  In other words, even after creating a

Technically, they get written out on qcow2_inactivate -- so there is the
opportunity to write them out at key sync points if you want.

However, like Vladimir says, this data is going to be necessarily wrong
while the image is in-use, so there may not be great value in it. There
may be a lot of anti-value if users learn to use or rely on that data.

I suppose the debugging case you want to assist here is one of trust for
users -- if a user wants to take a quick poke at the image and see if
the persistent bitmap tracking really got enabled before trusting it for
the next week of operations.

> persistent bitmap via QMP (I'm trying to debug my libvirt API for
> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
> name', but it boils down to a QMP transaction with
> 'block-dirty-bitmap-add' as one of the commands), running:
> 
> $ qemu-img info -U Active1.qcow2
> 
> shows
> bitmaps:
> refcount bits: 16
> 
> for as long as the qemu process is running. What does it take to force a
> qcow2 image to write out its current set of known bitmaps to disk, even
> if they are known to be potentially dirty? Should it happen any time we
> flush L1/L2/refcount tables?  On a periodic but slow timer (say once
> every 5 minutes)? Other ideas?  I know we don't want to be flushing the
> full bitmap contents on every change to the in-memory internal bitmap,
> but meta-changes (such as adding a bitmap) seem like the sort of thing
> where it's worth flushing the qcow2 file; particularly when adding the
> bitmap via QMP 'transaction' which goes to the bother of flushing all
> pending I/O in order to properly roll back on failure (which means on
> success, it would be nice for the new bitmap name to show up in the
> qcow2 header, even if the contents of the bitmap are not up-to-date).
> 



Re: [Qemu-devel] [PATCH] MAINTAINERS: XIVE is an interrupt controller, not a machine

2019-01-30 Thread David Gibson
On Wed, Jan 30, 2019 at 04:45:40PM +0100, Thomas Huth wrote:
> The "XIVE" section is currently listed in the "PowerPC Machines"
> section, which is weird, since this is an interrupt controller
> device. Move it to the "Devices" section instead.
> 
> Signed-off-by: Thomas Huth 

Applied to ppc-for-4.0, thanks.

> ---
>  MAINTAINERS | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b334b53..eac36b6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1038,14 +1038,6 @@ F: tests/libqos/*spapr*
>  F: tests/rtas*
>  F: tests/libqos/rtas*
>  
> -XIVE
> -M: David Gibson 
> -M: Cédric Le Goater 
> -L: qemu-...@nongnu.org
> -S: Supported
> -F: hw/*/*xive*
> -F: include/hw/*/*xive*
> -
>  virtex_ml507
>  M: Edgar E. Iglesias 
>  L: qemu-...@nongnu.org
> @@ -1645,6 +1637,14 @@ F: tests/libqos/fw_cfg.c
>  F: tests/fw_cfg-test.c
>  T: git https://github.com/philmd/qemu.git fw_cfg-next
>  
> +XIVE
> +M: David Gibson 
> +M: Cédric Le Goater 
> +L: qemu-...@nongnu.org
> +S: Supported
> +F: hw/*/*xive*
> +F: include/hw/*/*xive*
> +
>  Subsystems
>  --
>  Audio

-- 
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] hw/ppc: Move ppc40x_*reset() functions from ppc405_uc.c to ppc.c

2019-01-30 Thread David Gibson
On Wed, Jan 30, 2019 at 03:30:49PM +0100, Thomas Huth wrote:
> Currently, it is not possible to build a QEMU binary without the
> ppc405_uc.c file, even if you do not want to have the embedded machines
> in the binary. This is bad since it's quite a bit of code and this code
> pulls in some more dependencies (e.g. via the usage of serial_mm_init())
> which would not be needed otherwise - especially with the upcoming
> Kconfig-style configuration system for QEMU.
> 
> The only functions from this file which are really always required for
> linking are the ppc40x_*reset() functions, so move these functions to
> ppc.c, close to the ppc40x_set_irq() function that calls them. Now we
> can flag ppc405_uc.c and ppc4xx_devs.c with the CONFIG_PPC4XX config
> switch, too.
> 
> And while we're at it, replace the printf()s in these ppc40x_*reset()
> functions with proper calls to qemu_log_mask().
> 
> Signed-off-by: Thomas Huth 

Applied, thanks.

> ---
>  hw/ppc/Makefile.objs |  3 +--
>  hw/ppc/ppc.c | 56 ++
>  hw/ppc/ppc405_uc.c   | 58 
> 
>  3 files changed, 57 insertions(+), 60 deletions(-)
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 4e0c1c0..1e753de 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -13,8 +13,7 @@ obj-y += spapr_pci_vfio.o
>  endif
>  obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
>  # PowerPC 4xx boards
> -obj-y += ppc4xx_devs.o ppc405_uc.o
> -obj-$(CONFIG_PPC4XX) += ppc4xx_pci.o ppc405_boards.o
> +obj-$(CONFIG_PPC4XX) += ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o 
> ppc405_boards.o
>  obj-$(CONFIG_PPC4XX) += ppc440_bamboo.o ppc440_pcix.o ppc440_uc.o
>  obj-$(CONFIG_SAM460EX) += sam460ex.o
>  # PReP
> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> index ec4be25..98b409f 100644
> --- a/hw/ppc/ppc.c
> +++ b/hw/ppc/ppc.c
> @@ -310,6 +310,62 @@ void ppcPOWER7_irq_init(PowerPCCPU *cpu)
>  }
>  #endif /* defined(TARGET_PPC64) */
>  
> +void ppc40x_core_reset(PowerPCCPU *cpu)
> +{
> +CPUPPCState *env = >env;
> +target_ulong dbsr;
> +
> +qemu_log_mask(CPU_LOG_RESET, "Reset PowerPC core\n");
> +cpu_interrupt(CPU(cpu), CPU_INTERRUPT_RESET);
> +dbsr = env->spr[SPR_40x_DBSR];
> +dbsr &= ~0x0300;
> +dbsr |= 0x0100;
> +env->spr[SPR_40x_DBSR] = dbsr;
> +}
> +
> +void ppc40x_chip_reset(PowerPCCPU *cpu)
> +{
> +CPUPPCState *env = >env;
> +target_ulong dbsr;
> +
> +qemu_log_mask(CPU_LOG_RESET, "Reset PowerPC chip\n");
> +cpu_interrupt(CPU(cpu), CPU_INTERRUPT_RESET);
> +/* XXX: TODO reset all internal peripherals */
> +dbsr = env->spr[SPR_40x_DBSR];
> +dbsr &= ~0x0300;
> +dbsr |= 0x0200;
> +env->spr[SPR_40x_DBSR] = dbsr;
> +}
> +
> +void ppc40x_system_reset(PowerPCCPU *cpu)
> +{
> +qemu_log_mask(CPU_LOG_RESET, "Reset PowerPC system\n");
> +qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
> +}
> +
> +void store_40x_dbcr0(CPUPPCState *env, uint32_t val)
> +{
> +PowerPCCPU *cpu = ppc_env_get_cpu(env);
> +
> +switch ((val >> 28) & 0x3) {
> +case 0x0:
> +/* No action */
> +break;
> +case 0x1:
> +/* Core reset */
> +ppc40x_core_reset(cpu);
> +break;
> +case 0x2:
> +/* Chip reset */
> +ppc40x_chip_reset(cpu);
> +break;
> +case 0x3:
> +/* System reset */
> +ppc40x_system_reset(cpu);
> +break;
> +}
> +}
> +
>  /* PowerPC 40x internal IRQ controller */
>  static void ppc40x_set_irq(void *opaque, int pin, int level)
>  {
> diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
> index 8d3a797..3ae7f6d 100644
> --- a/hw/ppc/ppc405_uc.c
> +++ b/hw/ppc/ppc405_uc.c
> @@ -1156,64 +1156,6 @@ static void ppc4xx_gpt_init(hwaddr base, qemu_irq 
> irqs[5])
>  }
>  
>  
> /*/
> -/* SPR */
> -void ppc40x_core_reset(PowerPCCPU *cpu)
> -{
> -CPUPPCState *env = >env;
> -target_ulong dbsr;
> -
> -printf("Reset PowerPC core\n");
> -cpu_interrupt(CPU(cpu), CPU_INTERRUPT_RESET);
> -dbsr = env->spr[SPR_40x_DBSR];
> -dbsr &= ~0x0300;
> -dbsr |= 0x0100;
> -env->spr[SPR_40x_DBSR] = dbsr;
> -}
> -
> -void ppc40x_chip_reset(PowerPCCPU *cpu)
> -{
> -CPUPPCState *env = >env;
> -target_ulong dbsr;
> -
> -printf("Reset PowerPC chip\n");
> -cpu_interrupt(CPU(cpu), CPU_INTERRUPT_RESET);
> -/* XXX: TODO reset all internal peripherals */
> -dbsr = env->spr[SPR_40x_DBSR];
> -dbsr &= ~0x0300;
> -dbsr |= 0x0200;
> -env->spr[SPR_40x_DBSR] = dbsr;
> -}
> -
> -void ppc40x_system_reset(PowerPCCPU *cpu)
> -{
> -printf("Reset PowerPC system\n");
> -qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
> -}
> -
> -void store_40x_dbcr0 (CPUPPCState *env, uint32_t val)
> -{
> -PowerPCCPU *cpu = ppc_env_get_cpu(env);
> -
> -switch ((val >> 28) & 0x3) 

Re: [Qemu-devel] [PATCH 01/15] s390 vfio-ccw: Add bootindex property and IPLB data

2019-01-30 Thread Farhan Ali




On 01/29/2019 08:29 AM, Jason J. Herne wrote:

Add bootindex property and iplb data for vfio-ccw devices. This allows us to
forward boot information into the bios for vfio-ccw devices.

Signed-off-by: Jason J. Herne
Acked-by: Halil Pasic
---
  hw/s390x/ipl.c  | 14 ++
  hw/s390x/s390-ccw.c |  9 +
  hw/vfio/ccw.c   | 13 +
  include/hw/s390x/s390-ccw.h |  1 +
  include/hw/s390x/vfio-ccw.h | 38 ++
  5 files changed, 63 insertions(+), 12 deletions(-)
  create mode 100644 include/hw/s390x/vfio-ccw.h

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 21f64ad..a993f65 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -19,6 +19,7 @@
  #include "hw/loader.h"
  #include "hw/boards.h"
  #include "hw/s390x/virtio-ccw.h"
+#include "hw/s390x/vfio-ccw.h"
  #include "hw/s390x/css.h"
  #include "hw/s390x/ebcdic.h"
  #include "ipl.h"
@@ -311,8 +312,12 @@ static CcwDevice *s390_get_ccw_device(DeviceState *dev_st)
  VirtioCcwDevice *virtio_ccw_dev = (VirtioCcwDevice *)
  object_dynamic_cast(OBJECT(qdev_get_parent_bus(dev_st)->parent),
  TYPE_VIRTIO_CCW_DEVICE);
+VFIOCCWDevice *vfio_ccw_dev = (VFIOCCWDevice *)
+object_dynamic_cast(OBJECT(dev_st), TYPE_VFIO_CCW);
  if (virtio_ccw_dev) {
  ccw_dev = CCW_DEVICE(virtio_ccw_dev);
+} else if (vfio_ccw_dev) {
+ccw_dev = CCW_DEVICE(vfio_ccw_dev);
  } else {
  SCSIDevice *sd = (SCSIDevice *)
  object_dynamic_cast(OBJECT(dev_st),
@@ -347,6 +352,8 @@ static bool s390_gen_initial_iplb(S390IPLState *ipl)
  if (ccw_dev) {
  SCSIDevice *sd = (SCSIDevice *) object_dynamic_cast(OBJECT(dev_st),
  TYPE_SCSI_DEVICE);
+VFIOCCWDevice *vc = (VFIOCCWDevice *)
+object_dynamic_cast(OBJECT(dev_st), TYPE_VFIO_CCW);
  
  if (sd) {

  ipl->iplb.len = cpu_to_be32(S390_IPLB_MIN_QEMU_SCSI_LEN);
@@ -358,6 +365,13 @@ static bool s390_gen_initial_iplb(S390IPLState *ipl)
  ipl->iplb.scsi.channel = cpu_to_be16(sd->channel);
  ipl->iplb.scsi.devno = cpu_to_be16(ccw_dev->sch->devno);
  ipl->iplb.scsi.ssid = ccw_dev->sch->ssid & 3;
+} else if (vc) {
+CcwDevice *ccw_dev = CCW_DEVICE(vc);


Do we need this line here? I though ccw_dev was already correctly casted 
in s390_get_ccw_device?



+
+ipl->iplb.len = cpu_to_be32(S390_IPLB_MIN_CCW_LEN);
+ipl->iplb.pbt = S390_IPL_TYPE_CCW;
+ipl->iplb.ccw.devno = cpu_to_be16(ccw_dev->sch->devno);
+ipl->iplb.ccw.ssid = ccw_dev->sch->ssid & 3;
  } else {
  VirtIONet *vn = (VirtIONet *) object_dynamic_cast(OBJECT(dev_st),

TYPE_VIRTIO_NET);





Re: [Qemu-devel] [PATCH 03/15] s390-bios: decouple common boot logic from virtio

2019-01-30 Thread Farhan Ali




On 01/29/2019 08:29 AM, Jason J. Herne wrote:

Create a boot_setup function to handle getting boot information from
the machine/hypervisor. This decouples common boot logic from the
virtio code path and allows us to make use of it for the real dasd boot
scenario.

Signed-off-by: Jason J. Herne 
Acked-by: Halil Pasic 
Reviewed-by: Collin Walling 
---
  pc-bios/s390-ccw/main.c | 28 
  1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index e82fe2c..67df421 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -14,16 +14,17 @@
  
  char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));

  static SubChannelId blk_schid = { .one = 1 };
-IplParameterBlock iplb __attribute__((__aligned__(PAGE_SIZE)));
  static char loadparm_str[LOADPARM_LEN + 1] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  QemuIplParameters qipl;
+IplParameterBlock iplb __attribute__((__aligned__(PAGE_SIZE)));
+static bool have_iplb;
  
  #define LOADPARM_PROMPT "PROMPT  "

  #define LOADPARM_EMPTY  ""
  #define BOOT_MENU_FLAG_MASK (QIPL_FLAG_BM_OPTS_CMD | QIPL_FLAG_BM_OPTS_ZIPL)
  
  /*

- * Priniciples of Operations (SA22-7832-09) chapter 17 requires that
+ * Principles of Operations (SA22-7832-09) chapter 17 requires that
   * a subsystem-identification is at 184-187 and bytes 188-191 are zero
   * after list-directed-IPL and ccw-IPL.
   */
@@ -111,23 +112,33 @@ static void css_setup(void)
  enable_mss_facility();
  }
  
+/*

+ * Collect various pieces of information from the hypervisor/hardware that
+ * we'll use to determine exactly how we'll boot.
+ */
+static void boot_setup(void)
+{
+char lpmsg[] = "LOADPARM=[]\n";
+
+sclp_get_loadparm_ascii(loadparm_str);
+memcpy(lpmsg + 10, loadparm_str, 8);
+sclp_print(lpmsg);
+
+have_iplb = store_iplb();
+}
+
  static void virtio_setup(void)
  {
  Schib schib;
  int ssid;
  bool found = false;
  uint16_t dev_no;
-char ldp[] = "LOADPARM=[]\n";
  VDev *vdev = virtio_get_device();
  QemuIplParameters *early_qipl = (QemuIplParameters *)QIPL_ADDRESS;
  
-sclp_get_loadparm_ascii(loadparm_str);

-memcpy(ldp + 10, loadparm_str, LOADPARM_LEN);
-sclp_print(ldp);
-
  memcpy(, early_qipl, sizeof(QemuIplParameters));
  
-if (store_iplb()) {

+if (have_iplb) {
  switch (iplb.pbt) {
  case S390_IPL_TYPE_CCW:
  dev_no = iplb.ccw.devno;
@@ -174,6 +185,7 @@ int main(void)
  {
  sclp_setup();
  css_setup();
+boot_setup();
  virtio_setup();
  
  zipl_load(); /* no return */



Reviewed-by: Farhan Ali 




Re: [Qemu-devel] [PATCH 02/15] s390-bios: decouple cio setup from virtio

2019-01-30 Thread Farhan Ali




On 01/29/2019 08:29 AM, Jason J. Herne wrote:

Move channel i/o setup code out to a separate function. This decouples cio
setup from the virtio code path and allows us to make use of it for booting
dasd devices.

Signed-off-by: Jason J. Herne 
Acked-by: Halil Pasic 
Reviewed-by: Collin Walling 
---
  pc-bios/s390-ccw/main.c | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index 544851d..e82fe2c 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -99,6 +99,18 @@ static void menu_setup(void)
  }
  }
  
+/*

+ * Initialize the channel I/O subsystem so we can talk to our ipl/boot device.
+ */
+static void css_setup(void)
+{
+/*
+ * Unconditionally enable mss support. In every sane configuration this
+ * will succeed; and even if it doesn't, stsch_err() can handle it.
+ */
+enable_mss_facility();
+}
+
  static void virtio_setup(void)
  {
  Schib schib;
@@ -109,13 +121,6 @@ static void virtio_setup(void)
  VDev *vdev = virtio_get_device();
  QemuIplParameters *early_qipl = (QemuIplParameters *)QIPL_ADDRESS;
  
-/*

- * We unconditionally enable mss support. In every sane configuration,
- * this will succeed; and even if it doesn't, stsch_err() can deal
- * with the consequences.
- */
-enable_mss_facility();
-
  sclp_get_loadparm_ascii(loadparm_str);
  memcpy(ldp + 10, loadparm_str, LOADPARM_LEN);
  sclp_print(ldp);
@@ -168,6 +173,7 @@ static void virtio_setup(void)
  int main(void)
  {
  sclp_setup();
+css_setup();
  virtio_setup();
  
  zipl_load(); /* no return */



Reviewed-by: Farhan Ali 




[Qemu-devel] [PATCH] RISC-V: Fix pmpcfg register indexing

2019-01-30 Thread Luke Nelson
pmpcfg_csr_{read,write} do not correctly handle accesses to PMP
configurations 8 through 15 (CSR pmpcfg2) on RV64.

The current code computes the pmpcfg index using:

  (reg_index * sizeof(target_ulong))

This is incorrect on RV64.  For example, when reg_index is 2 (i.e.,
pmpcfg2), the computed configuration index will be 16-23, which
should be 8-15.

A correct way is to use (reg_index * 4) instead, which works for
both RV32 and RV64.

Cc: Xi Wang 
Signed-off-by: Luke Nelson 
---
 target/riscv/pmp.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 15a5366616..a1bee56c86 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -311,9 +311,8 @@ void pmpcfg_csr_write(CPURISCVState *env, uint32_t 
reg_index,
 }
 
 for (i = 0; i < sizeof(target_ulong); i++) {
-cfg_val = (val >> 8 * i)  & 0xff;
-pmp_write_cfg(env, (reg_index * sizeof(target_ulong)) + i,
-cfg_val);
+cfg_val = (val >> (i * 8)) & 0xff;
+pmp_write_cfg(env, (reg_index * 4) + i, cfg_val);
 }
 }
 
@@ -328,7 +327,7 @@ target_ulong pmpcfg_csr_read(CPURISCVState *env, uint32_t 
reg_index)
 target_ulong val = 0;
 
 for (i = 0; i < sizeof(target_ulong); i++) {
-val = pmp_read_cfg(env, (reg_index * sizeof(target_ulong)) + i);
+val = pmp_read_cfg(env, (reg_index * 4) + i);
 cfg_val |= (val << (i * 8));
 }
 
-- 
2.19.1




Re: [Qemu-devel] [PATCH 06/18] Acceptance tests: use "arch:" tag to filter target specific tests

2019-01-30 Thread Cleber Rosa



On 1/18/19 5:38 AM, Cornelia Huck wrote:
> On Thu, 17 Jan 2019 13:56:16 -0500
> Cleber Rosa  wrote:
> 
>> Currently, the only test that contains some target architecture
>> information is "boot_linux_console.py" which test contains a "x86_64"
>> tag.  But that tag is not respected in the default execution, that is,
>> "make check-acceptance" doesn't do anything with it.
>>
>> That said, even the target architecture handling currently present in
>> the "avocado_qemu.Test" class, class is pretty limited.  For instance,
>> by default, it chooses a target based on the host architecture.
>>
>> Because the original implementation of the tags feature in Avocado did
>> not include any time of namespace or "key:val" mechanism, no tag has
>> relation to another tag.  The new implementation of the tags feature
>> from version 67.0 onwards, allows "key:val" tags, and because of that,
>> a test can be classified with a tag in a given key.  For instance, the
>> new proposed version of the "boot_linux_console.py" test, which
>> downloads and attempts to run a x86_64 kernel, is now tagged as:
>>
>>   :avocado: tags=arch:x86_64
>>
>> This means that it can be filtered (out) when no x86_64 target is
>> available.  At the same time, tests that don't have a "arch:" tag,
>> will not be filtered out.
>>
>> Signed-off-by: Cleber Rosa 
>> ---
>>  tests/Makefile.include | 3 +++
>>  tests/acceptance/boot_linux_console.py | 2 +-
>>  tests/requirements.txt | 2 +-
>>  3 files changed, 5 insertions(+), 2 deletions(-)
>>
> 
>> diff --git a/tests/acceptance/boot_linux_console.py 
>> b/tests/acceptance/boot_linux_console.py
>> index 98324f7591..46b20bdfe2 100644
>> --- a/tests/acceptance/boot_linux_console.py
>> +++ b/tests/acceptance/boot_linux_console.py
>> @@ -19,7 +19,7 @@ class BootLinuxConsole(Test):
>>  and the kernel command line is properly passed from QEMU to the kernel
>>  
>>  :avocado: enable
>> -:avocado: tags=x86_64
>> +:avocado: tags=arch:x86_64
>>  """
>>  
>>  timeout = 60
> 
> You probably want to do the same change in virtio_version.py;
> otherwise, if I run the acceptance tests on s390x, it will run into
> timeouts (it looks like that test is intended to be run with x86
> machines anyway.)
> 

Right, good catch.  Also, the same applies to the "linux_initrd.py"
test, merged after this version.

- Cleber.



Re: [Qemu-devel] [PATCH v1] add new function to copy dirty-bitmap

2019-01-30 Thread John Snow



On 1/2/19 5:01 AM, mahaocong wrote:
> From: mahaocong 
> 
> This patch adds new function to copy the hbitmap from an exist dirty-bitmap to
> another. The destination bitmap should have the same size and granularity with
> the source bitmap, or the copy will fail.
> 
> Signed-off-by: mahaocong 

/technically/ we *can* do this already by creating a blank bitmap and
merging from one bitmap to the empty one.

Do you have a good argument for why copy is needed in addition?

--js



  1   2   3   4   >