[Bug 1856837] Re: qemu 4.2.0 arm segmentation fault with gcc 9.2

[Fabian Godehardt]

Sorry for the delay. I added the sysroot, the binary and the files causing the 
segfault.
Please let me know if there is something missing.

I used the following commands to let it run:

export LD_LIBRARY_PATH=/opt/qemu-test/test1/lib
/opt/qemu-test/test1/bin/qemu-arm "/opt/qemu-test/test1/files/mksnapshot.arm" 
--log-snapshot-positions --logfile "/tmp/snapshot.log" --random-seed 314159265 
"/tmp/snapshot.cc"


Thanks again!
Fabian

** Attachment added: "Tarball containing sysroot, qemu binary and files"
   
https://bugs.launchpad.net/qemu/+bug/1856837/+attachment/5317851/+files/qemu-segfault-v8.tar.xz

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

Title:
  qemu 4.2.0 arm  segmentation fault with gcc 9.2

Status in QEMU:
  New

Bug description:
  As discussed with f4bug yesterday on IRC here comes the bug
  description.

  I'm building/configured qemu-4.2.0 on an x86_64 (gcc (Debian
  6.3.0-18+deb9u1) 6.3.0 20170516) with target-list "arm-softmmu,arm-
  linux-user" and debug enabled. I use the arm-linux-user variant,
  "qemu-arm".

  Then i'm trying to cross-compile (arm gcc) an old version of googles
  v8 (as i need this version of the lib for binary compatibility) which
  uses qemu during build.

  It worked with gcc 5.4.0 but not with 9.2.0. I also tried with 6.5.0,
  7.4.0 and 8.3.0 but those are also causing the same segmentation
  fault.

  The executed command wich breaks qemu is:

   qemu-arm /tmp/build/out/arm.release/mksnapshot.arm --log-snapshot-
  positions --logfile
  /tmp/build/out/arm.release/obj.host/v8_snapshot/geni/snapshot.log
  --random-seed 314159265 /tmp/build/out/arm.release/obj.host/v8_snap

  The printed error message is:

  ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 
MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped

  Calling qemu with gdb gives the following information:

   Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault.
   0x55d63d11 in static_code_gen_buffer ()

  and

   (gdb) bt
   #0  0x55d63d11 in static_code_gen_buffer ()
   #1  0x55628d58 in cpu_tb_exec (itb=, 
cpu=0x57c33930) at 
   /tmp/build/qemu/accel/tcg/cpu-exec.c:172
   #2  cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, 
   cpu=0x57c33930) at /tmp/build/qemu/accel/tcg/cpu-exec.c:618
   #3  cpu_exec (cpu=cpu@entry=0x57c2b660) at 
/tmp/build/qemu/accel/tcg/cpu-exec.c:731
   #4  0x55661578 in cpu_loop (env=0x57c33930) at 
/tmp/build/qemu/linux-user/arm/cpu_loop.c:219
  #5  0x555d6d76 in main (argc=, argv=, 
envp=) at /tmp/build/qemu/linux-user/main.c:865

  Calling qemu-arm with debug switch "-d in_asm,int,op_opt" shows the
  log in the attached file.

  Thanks for any hints!
  Fabian

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

Re: [PATCH 2/2] ppc/pnv: Use the CPU topology to compute the default number of chips

[Cédric Le Goater]

On 12/21/19 11:28 AM, Greg Kurz wrote:
> On Sat, 21 Dec 2019 11:39:06 +1100
> David Gibson  wrote:
> 
>> On Fri, Dec 20, 2019 at 05:51:48PM +0100, Greg Kurz wrote:
>>> Multi TCG mandates the CPU topology to be dimensioned to the actual
>>> number of CPUs, depending on the number of chips the user asked for.
>>> That is, '-machine num-chips=N' should always have a '-smp' companion
>>> with a topology that meats the resulting number of CPUs, typically
>>> '-smp sockets=N'.
>>>
>>> Simplify the command line for these setups by computing the default
>>> number of chips based on the CPU topology, ie. no need to explicitely
>>> set "num-chips" anymore. This must be done at machine init because
>>> smp_parse() is called after instance init.
>>>
>>> Signed-off-by: Greg Kurz 
>>
>> Is there actually any reason to retain num-chips at all?  Or could we
>> just set the number of chips equal to the number of sockets, which
>> seems to make sense to me.
>>
> 
> I don't quite know why "num-chips" was introduced in the first place... so
> yes, if it turns out it isn't needed, I'll gladly drop the property.

I concur. We have some freedom on the PowerNV machine options. 
Let's replace "num-chips" with "sockets".

Thanks,

C. 

Re: [Qemu-devel] What should a virtual board emulate?

[Gerd Hoffmann]

  Hi,

> 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit
> commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951
> Author: Paolo Bonzini 
> Date:   Tue Mar 19 15:37:19 2019 +0100
> 
> mips-fulong2e: obey -vga none
> 
> Do not create an ATI VGA if "-vga none" was passed on the command line.

> 1/ the Radeon chip is soldered on the motherboard,
> 
> 2/ the default BIOS expects the Radeon chip to be
>unconditionally present,
> 
> I insist this patch is incorrect for the particular case of the Fuloong2e
> board. I plan to revert it when I post the test.

Yep.  IMHO devices which you can't unplug on the physical board should
be present even with "qemu -nodefaults".

cheers,
  Gerd

[PATCH v2] MAINTAINERS: Replace Claudio Fontana for tcg/aarch64

[Richard Henderson]

Claudio's Huawei address has been defunct for quite a while.  In

  https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06872.html

he asked for his personal address to be removed as well.

I will take over officially.

Cc: Claudio Fontana 
Cc: Philippe Mathieu-Daudé 
Cc: Alex Bennée 
Signed-off-by: Richard Henderson 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f453fc94c..1f5f3ca21b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2384,8 +2384,7 @@ F: plugins/
 F: tests/plugin
 
 AArch64 TCG target
-M: Claudio Fontana 
-M: Claudio Fontana 
+M: Richard Henderson 
 S: Maintained
 L: qemu-...@nongnu.org
 F: tcg/aarch64/
-- 
2.20.1

Re: [PATCH qemu v2] spapr: Kill SLOF

[Alexey Kardashevskiy]

On 06/01/2020 15:19, David Gibson wrote:
> On Mon, Jan 06, 2020 at 10:42:42AM +1100, Alexey Kardashevskiy wrote:
>> The Petitboot bootloader is way more advanced than SLOF is ever going to
>> be as Petitboot comes with the full-featured Linux kernel with all
>> the drivers, and initramdisk with quite user friendly interface.
>> The problem with ditching SLOF is that an unmodified pseries kernel can
>> either start via:
>> 1. kexec, this requires presence of RTAS and skips
>> ibm,client-architecture-support entirely;
>> 2. normal boot, this heavily relies on the OF1275 client interface to
>> fetch the device tree and do early setup (claim memory).
>>
>> This adds a new bios-less mode to the pseries machine: "bios=on|off".
>> When enabled, QEMU does not load SLOF and jumps to the kernel from
>> "-kernel".
>>
>> The client interface is implemented exactly as RTAS - a 20 bytes blob,
>> right next after the RTAS blob. The entry point is passed to the kernel
>> via GPR5.
>>
>> This implements a handful of client interface methods just to get going.
>> In particular, this implements the device tree fetching,
>> ibm,client-architecture-support and instantiate-rtas.
>>
>> This implements changing FDT properties only for "linux,rtas-base" and
>> "linux,rtas-entry", just to get early boot going.
>>
>> This assigns "phandles" to device tree nodes as there is no more SLOF
>> and OF nodes addresses of which served as phandle values.
>> This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
>> phandles are regenerated at every FDT rebuild.
>>
>> When bios=off, this adds "/chosen" every time QEMU builds a tree.
>>
>> This implements "claim" which the client (Linux) uses for memory
>> allocation; this is also  used by QEMU for claiming kernel/initrd images,
>> client interface entry point, RTAS and the initial stack.
>>
>> While at this, add a "kernel-addr" machine parameter to allow moving
>> the kernel in memory. This is useful for debugging if the kernel is
>> loaded at @0, although not necessary.
>>
>> This does not implement instances properly but in order to boot a VM,
>> we only really need a stdout instance and the "/" instance for
>> "call-method", we fake these.
> 
> As we've discussed, I really like the idea of this.  It think the
> basic approach looks good too.
> 
> As you probably realize, there are quite a lot of things to be
> polished though.  Comments below.
> 
>>
>> The test command line:
>>
>> qemu-system-ppc64 \
>> -nodefaults \
>> -chardev stdio,id=STDIO0,signal=off,mux=on \
>> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
>> -mon id=MON0,chardev=STDIO0,mode=readline \
>> -nographic \
>> -vga none \
>> -kernel vmldbg \
>> -machine pseries,bios=off \
>> -m 4G \
>> -enable-kvm \
>> -initrd pb/rootfs.cpio.xz \
>> img/u1804-64le.qcow2 \
>> -snapshot \
>> -smp 8,threads=8 \
>> -L /home/aik/t/qemu-ppc64-bios/ \
>> -trace events=qemu_trace_events \
>> -d guest_errors \
>> -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
>> -mon chardev=SOCKET0,mode=control
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>> Changes:
>> v2:
>> * fixed claim()
>> * added "setprop"
>> * cleaner client interface and RTAS blobs management
>> * boots to petitboot and further to the target system
>> * more trace points
>> ---
>>  hw/ppc/Makefile.objs   |   1 +
>>  include/hw/loader.h|   1 +
>>  include/hw/ppc/spapr.h |  25 ++-
>>  hw/ppc/spapr.c | 231 ++--
>>  hw/ppc/spapr_client.c  | 464 +
>>  hw/ppc/spapr_hcall.c   |  49 +++--
>>  hw/ppc/trace-events|   9 +
>>  7 files changed, 743 insertions(+), 37 deletions(-)
>>  create mode 100644 hw/ppc/spapr_client.c
>>
>> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
>> index 101e9fc59185..ce31c0acd2fb 100644
>> --- a/hw/ppc/Makefile.objs
>> +++ b/hw/ppc/Makefile.objs
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
>> spapr_rtas.o
>>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
>>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
>>  obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
>> +obj-$(CONFIG_PSERIES) += spapr_client.o
> 
> This applies in a bunch of places here.  Just calling things "client"
> is clear enough if you're already thinking about Open Firmware.  But
> this appears in a bunch of places where you might come across it
> without that context, in which case it could be kind of confusing.  So
> I'd suggest using "of_client" or "of_client_interface" in most places
> you're using "client".
> 
>>  obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
>>  # IBM PowerNV
>>  obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
>> pnv_occ.o pnv_bmc.o
>> diff --git a/include/hw/loader.h b/include/hw/loader.h
>> index 48a96cd55904..a2f58077a47e 100644
>> --- a/include/hw/loader.h
>> +++ b/include/hw/loader.h
>> @@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
>> *blob, 

Re: [PATCH] MAINTAINERS: Remove Claudio Fontana bouncing email

[Richard Henderson]

On 12/30/19 9:18 PM, Philippe Mathieu-Daudé wrote:
> Claudio Fontana Huawei email is bouncing, remove it.
> 
>   The message you sent to claudio.font...@huawei.com couldn't be
>   delivered due to: Recipient email address is possibly incorrect.
> 
>   Further information:
> 5.1.1 Error: invalid recipients
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 387879aebc..8db4de6b9a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2383,7 +2383,6 @@ F: plugins/
>  F: tests/plugin
>  
>  AArch64 TCG target
> -M: Claudio Fontana 
>  M: Claudio Fontana 
>  S: Maintained
>  L: qemu-...@nongnu.org
> 

In

  https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06872.html

Claudio asks to be removed from the section entirely.
I can take it up.


r~

Re: [PATCH qemu v2] spapr: Kill SLOF

[David Gibson]

On Mon, Jan 06, 2020 at 10:42:42AM +1100, Alexey Kardashevskiy wrote:
> The Petitboot bootloader is way more advanced than SLOF is ever going to
> be as Petitboot comes with the full-featured Linux kernel with all
> the drivers, and initramdisk with quite user friendly interface.
> The problem with ditching SLOF is that an unmodified pseries kernel can
> either start via:
> 1. kexec, this requires presence of RTAS and skips
> ibm,client-architecture-support entirely;
> 2. normal boot, this heavily relies on the OF1275 client interface to
> fetch the device tree and do early setup (claim memory).
> 
> This adds a new bios-less mode to the pseries machine: "bios=on|off".
> When enabled, QEMU does not load SLOF and jumps to the kernel from
> "-kernel".
> 
> The client interface is implemented exactly as RTAS - a 20 bytes blob,
> right next after the RTAS blob. The entry point is passed to the kernel
> via GPR5.
> 
> This implements a handful of client interface methods just to get going.
> In particular, this implements the device tree fetching,
> ibm,client-architecture-support and instantiate-rtas.
> 
> This implements changing FDT properties only for "linux,rtas-base" and
> "linux,rtas-entry", just to get early boot going.
> 
> This assigns "phandles" to device tree nodes as there is no more SLOF
> and OF nodes addresses of which served as phandle values.
> This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
> phandles are regenerated at every FDT rebuild.
> 
> When bios=off, this adds "/chosen" every time QEMU builds a tree.
> 
> This implements "claim" which the client (Linux) uses for memory
> allocation; this is also  used by QEMU for claiming kernel/initrd images,
> client interface entry point, RTAS and the initial stack.
> 
> While at this, add a "kernel-addr" machine parameter to allow moving
> the kernel in memory. This is useful for debugging if the kernel is
> loaded at @0, although not necessary.
> 
> This does not implement instances properly but in order to boot a VM,
> we only really need a stdout instance and the "/" instance for
> "call-method", we fake these.

As we've discussed, I really like the idea of this.  It think the
basic approach looks good too.

As you probably realize, there are quite a lot of things to be
polished though.  Comments below.

> 
> The test command line:
> 
> qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline \
> -nographic \
> -vga none \
> -kernel vmldbg \
> -machine pseries,bios=off \
> -m 4G \
> -enable-kvm \
> -initrd pb/rootfs.cpio.xz \
> img/u1804-64le.qcow2 \
> -snapshot \
> -smp 8,threads=8 \
> -L /home/aik/t/qemu-ppc64-bios/ \
> -trace events=qemu_trace_events \
> -d guest_errors \
> -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
> -mon chardev=SOCKET0,mode=control
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v2:
> * fixed claim()
> * added "setprop"
> * cleaner client interface and RTAS blobs management
> * boots to petitboot and further to the target system
> * more trace points
> ---
>  hw/ppc/Makefile.objs   |   1 +
>  include/hw/loader.h|   1 +
>  include/hw/ppc/spapr.h |  25 ++-
>  hw/ppc/spapr.c | 231 ++--
>  hw/ppc/spapr_client.c  | 464 +
>  hw/ppc/spapr_hcall.c   |  49 +++--
>  hw/ppc/trace-events|   9 +
>  7 files changed, 743 insertions(+), 37 deletions(-)
>  create mode 100644 hw/ppc/spapr_client.c
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 101e9fc59185..ce31c0acd2fb 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
> spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
>  obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
> +obj-$(CONFIG_PSERIES) += spapr_client.o

This applies in a bunch of places here.  Just calling things "client"
is clear enough if you're already thinking about Open Firmware.  But
this appears in a bunch of places where you might come across it
without that context, in which case it could be kind of confusing.  So
I'd suggest using "of_client" or "of_client_interface" in most places
you're using "client".

>  obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
>  # IBM PowerNV
>  obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
> pnv_occ.o pnv_bmc.o
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 48a96cd55904..a2f58077a47e 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
> *blob, size_t len,
>  int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void 
> *data,
>  size_t datasize, size_t romsize, hwaddr addr,
> 

Re: [PATCH v2 0/7] configure: Improve PIE and other linkage

[Richard Henderson]

On 12/19/19 8:34 AM, Richard Henderson wrote:
> This begins by dropping the -Ttext-segment stuff, which Fangrui Song
> correctly points out does not work with lld.  But it's also obsolete,
> so instead of adding support for lld's --image-base, remove it all.
> 
> Then, remove some other legacy random addresses that were supposed
> to apply to softmmu, but didn't really make any sense, and aren't
> used anyway when PIE is used, which is the default with a modern
> linux distribution.
> 
> Then, clean up some of the configure logic surrounding PIE, and its
> current non-application to non-x86.
> 
> Finally, add support for static-pie linking.
> 
> Changes in v2:
>  - Remove mention of config-host.ld from make distclean
>  - Do not split -z,rodata/-z,now into two tests
>  - Fix --disable-pie --static
> 
> Tested in conjunction with AJB's 
>   configure: allow disable of cross compilation container
>   https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg02943.html
> 
> as otherwise check-tcg simply doesn't work on aarch64 if you happen
> to have docker installed.

Ping.  Patches 3 and 7 still unreviewed.


r~

Re: [PATCH] arm/translate-a64: fix uninitialized variable warning

[Pan Nengyuan]

On 1/6/2020 10:15 AM, Richard Henderson wrote:
> On 1/6/20 11:57 AM, pannengy...@huawei.com wrote:
>> From: Pan Nengyuan 
>>
>> Fixes:
>> target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512':
>> target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized 
>> in this function [-Werror=maybe-uninitialized]
>> genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr);
>> ^
>> qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used 
>> uninitialized in this function [-Werror=maybe-uninitialized]
>> if (!feature) {
>>
>> Reported-by: Euler Robot 
>> Signed-off-by: Pan Nengyuan 
>> Cc: Peter Maydell  
> 
> Are you compiling with reduced optimization?  The compiler should be able to
> prove that these variables are initialized.  It certainly does with -O2, on 
> all
> known gcc versions.

Yes, I compile it with optimization flags (-O2) and get this warnings. The gcc 
version is 8.2.1.

> 
> Perhaps a better fix is to add a
> 
> default:
> g_assert_not_reached();
> 
> entry to the o == 0 switch.  Though of course opcode must be in [0-3], based 
> on
> the extraction mask, so a default label isn't actually reachable.  But that's
> the only path I can see for which incomplete optimization would fail to prove
> initializatio
Yes, a default label is a better way.

> 
> r~
> 

Re: [PATCH] arm/translate-a64: fix uninitialized variable warning

[Richard Henderson]

On 1/6/20 11:57 AM, pannengy...@huawei.com wrote:
> From: Pan Nengyuan 
> 
> Fixes:
> target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512':
> target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized 
> in this function [-Werror=maybe-uninitialized]
> genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr);
> ^
> qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> if (!feature) {
> 
> Reported-by: Euler Robot 
> Signed-off-by: Pan Nengyuan 
> Cc: Peter Maydell  

Are you compiling with reduced optimization?  The compiler should be able to
prove that these variables are initialized.  It certainly does with -O2, on all
known gcc versions.

Perhaps a better fix is to add a

default:
g_assert_not_reached();

entry to the o == 0 switch.  Though of course opcode must be in [0-3], based on
the extraction mask, so a default label isn't actually reachable.  But that's
the only path I can see for which incomplete optimization would fail to prove
initialization.


r~

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Guoheyi]

在 2020/1/5 20:53, Michael S. Tsirkin 写道:

On Sun, Jan 05, 2020 at 07:34:01AM -0500, Michael S. Tsirkin wrote:

On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:

According to ACPI spec, _ADR should be used for device which is on a
bus that has a standard enumeration algorithm. It does not make sense
to have a _ADR object for devices which already have _HID and will be
enumerated by OSPM.

Signed-off-by: Heyi Guo 

Are you sure? I would think this depends on the ID and the device
really. E.g. PCI devices all are expected to have _ADR and some of them
have a _HID.


To clarify I am not commenting on patches.
The spec says this:
6.1.5 _HID (Hardware ID)

This object is used to supply OSPM with the device’s PNP ID or ACPI ID. 
1

When describing a platform, use of any _HID objects is optional. 
However, a _HID object must be

used to describe any device that will be enumerated by OSPM. OSPM only 
enumerates a device

when no bus enumerator can detect the device ID. For example, devices 
on an ISA bus are

enumerated by OSPM. Use the _ADR object to describe devices enumerated 
by bus enumerators

other than OSPM.


Note: "detect the device ID" not "enumerate the device" which I think
means there's a driver matching this vendor/device ID.

So it seems fine to have _ADR so device is enumerated, and still have
_HID e.g. so ACPI driver can be loaded as fallback if there's
no bus driver.


Note I am not saying the patch itself is not correct.
Maybe these devices are not on any standard bus and that
is why they should not have _ADR? I have not looked.

I am just saying that spec does not seem to imply _HID and _ADR
can't coexist.


That's true; I did't find such statement either. Maybe what we can say 
is that the _ADR is senseless here.


Thanks,

Heyi





CC Corey who added a device with both HID and ADR to x86 recenly.

Apropos Corey, why was HID APP0005 chosen?


---
Cc: Shannon Zhao 
Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
  hw/arm/virt-acpi-build.c  |   8 
  tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
  4 files changed, 8 deletions(-)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 9f4c7d1889..be752c0ad8 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry 
*uart_memmap,
   AML_EXCLUSIVE, _irq, 1));
  aml_append(dev, aml_name_decl("_CRS", crs));
  
-/* The _ADR entry is used to link this device to the UART described

- * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
- */
-aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
-
  aml_append(scope, dev);
  }
  
@@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,

  aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
  aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
  aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
  aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
  aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
  aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
@@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const 
MemMapEntry *gpio_memmap,
  {
  Aml *dev = aml_device("GPO0");
  aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
  
  Aml *crs = aml_resource_template();

@@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
  {
  Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
  aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
  aml_append(scope, dev);
  }
diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT


Please do not include binary changes in acpi patches.

See comment at the top of tests/bios-tables-test.c for documentation
on how to update these.

--
MST


.

[PATCH] arm/translate-a64: fix uninitialized variable warning

[pannengyuan]

From: Pan Nengyuan 

Fixes:
target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512':
target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr);
^
qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
if (!feature) {

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
Cc: Peter Maydell  
---
 target/arm/translate-a64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index d4bebbe629..211e3d813f 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -13564,8 +13564,8 @@ static void disas_crypto_three_reg_sha512(DisasContext 
*s, uint32_t insn)
 int rm = extract32(insn, 16, 5);
 int rn = extract32(insn, 5, 5);
 int rd = extract32(insn, 0, 5);
-bool feature;
-CryptoThreeOpFn *genfn;
+bool feature = false;
+CryptoThreeOpFn *genfn = NULL;
 
 if (o == 0) {
 switch (opcode) {
-- 
2.21.0.windows.1

[PATCH] nbd: fix uninitialized variable warning

[pannengyuan]

From: Pan Nengyuan 

Fixes:
/mnt/sdb/qemu/nbd/server.c: In function 'nbd_handle_request':
/mnt/sdb/qemu/nbd/server.c:2313:9: error: 'ret' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
 int ret;

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
---
 nbd/server.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nbd/server.c b/nbd/server.c
index 24ebc1a805..7eb3de0842 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -2310,7 +2310,7 @@ static coroutine_fn int nbd_handle_request(NBDClient 
*client,
NBDRequest *request,
uint8_t *data, Error **errp)
 {
-int ret;
+int ret = 0;
 int flags;
 NBDExport *exp = client->exp;
 char *msg;
-- 
2.21.0.windows.1

Re: [Patch v2 0/6] migration/postcopy: enable compress during postcopy

[Wei Yang]

On Wed, Dec 18, 2019 at 07:55:38PM +, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> Would this one be picked up in this version?
>
>I think that one is on Juan's list for the pull he's going to do soon.
>
>Dave
>

Happy New Year to all~

May I ask the plan for this patch set?


-- 
Wei Yang
Help you, Help me

Re: [PATCH 0/2] not use multifd during postcopy

[Wei Yang]

On Mon, Dec 16, 2019 at 10:35:39AM +0800, Wei Yang wrote:
>Would this one be picked up this time?

Happy new year to all.

Can I ask the plan for this patch set?

>
>On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>>We don't support multifd during postcopy, but user still could enable
>>both multifd and postcopy. This leads to migration failure.
>>
>>Patch 1 does proper cleanup, otherwise we may have data corruption.
>>Patch 2 does the main job.
>>
>>BTW, current multifd synchronization method needs a cleanup. Will send another
>>patch set.
>>
>>Wei Yang (2):
>>  migration/multifd: clean pages after filling packet
>>  migration/multifd: not use multifd during postcopy
>>
>> migration/ram.c | 15 ++-
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>>-- 
>>2.17.1
>
>-- 
>Wei Yang
>Help you, Help me

-- 
Wei Yang
Help you, Help me

Re: [PATCH 08/86] alpha:dp264: use memdev for RAM

[Richard Henderson]

On 12/31/19 11:02 PM, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
>   MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  hw/alpha/alpha_sys.h | 2 +-
>  hw/alpha/dp264.c | 3 ++-
>  hw/alpha/typhoon.c   | 8 ++--
>  3 files changed, 5 insertions(+), 8 deletions(-)

Acked-by: Richard Henderson 


r~

[PATCH qemu v2] spapr: Kill SLOF

[Alexey Kardashevskiy]

The Petitboot bootloader is way more advanced than SLOF is ever going to
be as Petitboot comes with the full-featured Linux kernel with all
the drivers, and initramdisk with quite user friendly interface.
The problem with ditching SLOF is that an unmodified pseries kernel can
either start via:
1. kexec, this requires presence of RTAS and skips
ibm,client-architecture-support entirely;
2. normal boot, this heavily relies on the OF1275 client interface to
fetch the device tree and do early setup (claim memory).

This adds a new bios-less mode to the pseries machine: "bios=on|off".
When enabled, QEMU does not load SLOF and jumps to the kernel from
"-kernel".

The client interface is implemented exactly as RTAS - a 20 bytes blob,
right next after the RTAS blob. The entry point is passed to the kernel
via GPR5.

This implements a handful of client interface methods just to get going.
In particular, this implements the device tree fetching,
ibm,client-architecture-support and instantiate-rtas.

This implements changing FDT properties only for "linux,rtas-base" and
"linux,rtas-entry", just to get early boot going.

This assigns "phandles" to device tree nodes as there is no more SLOF
and OF nodes addresses of which served as phandle values.
This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
phandles are regenerated at every FDT rebuild.

When bios=off, this adds "/chosen" every time QEMU builds a tree.

This implements "claim" which the client (Linux) uses for memory
allocation; this is also  used by QEMU for claiming kernel/initrd images,
client interface entry point, RTAS and the initial stack.

While at this, add a "kernel-addr" machine parameter to allow moving
the kernel in memory. This is useful for debugging if the kernel is
loaded at @0, although not necessary.

This does not implement instances properly but in order to boot a VM,
we only really need a stdout instance and the "/" instance for
"call-method", we fake these.

The test command line:

qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline \
-nographic \
-vga none \
-kernel vmldbg \
-machine pseries,bios=off \
-m 4G \
-enable-kvm \
-initrd pb/rootfs.cpio.xz \
img/u1804-64le.qcow2 \
-snapshot \
-smp 8,threads=8 \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events \
-d guest_errors \
-chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
-mon chardev=SOCKET0,mode=control

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2:
* fixed claim()
* added "setprop"
* cleaner client interface and RTAS blobs management
* boots to petitboot and further to the target system
* more trace points
---
 hw/ppc/Makefile.objs   |   1 +
 include/hw/loader.h|   1 +
 include/hw/ppc/spapr.h |  25 ++-
 hw/ppc/spapr.c | 231 ++--
 hw/ppc/spapr_client.c  | 464 +
 hw/ppc/spapr_hcall.c   |  49 +++--
 hw/ppc/trace-events|   9 +
 7 files changed, 743 insertions(+), 37 deletions(-)
 create mode 100644 hw/ppc/spapr_client.c

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 101e9fc59185..ce31c0acd2fb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
spapr_rtas.o
 obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
 obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
 obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
+obj-$(CONFIG_PSERIES) += spapr_client.o
 obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
 # IBM PowerNV
 obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
pnv_occ.o pnv_bmc.o
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 48a96cd55904..a2f58077a47e 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
*blob, size_t len,
 int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void *data,
 size_t datasize, size_t romsize, hwaddr addr,
 AddressSpace *as);
+bool rom_intersect(uint64_t start, uint64_t size);
 int rom_check_and_register_reset(void);
 void rom_set_fw(FWCfgState *f);
 void rom_set_order_override(int order);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 61f005c6f686..876879d12029 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -105,6 +105,11 @@ struct SpaprCapabilities {
 uint8_t caps[SPAPR_CAP_NUM];
 };
 
+typedef struct {
+uint64_t start;
+uint64_t size;
+} spapr_of_claimed;
+
 /**
  * SpaprMachineClass:
  */
@@ -158,8 +163,13 @@ struct SpaprMachineState {
 uint32_t fdt_size;
 uint32_t fdt_initial_size;
 void *fdt_blob;
+uint32_t rtas_base;
 long kernel_size;
 bool kernel_le;
+uint64_t kernel_addr;
+bool bios_enabled;
+GArray *claimed; /* array of 

Re: [RFC PATCH qemu] spapr: Kill SLOF

[Alexey Kardashevskiy]

Another version is coming, I'll start putting fewer people in the cc:
list, watch qemu-...@nongnu.org for further updates if interested. Thanks,


On 03/01/2020 18:44, Alexey Kardashevskiy wrote:
> The Petitboot bootloader is way more advanced than SLOF is ever going to
> be as Petitboot comes with the full-featured Linux kernel with all
> the drivers, and initramdisk with quite user friendly interface.
> The problem with ditching SLOF is that an unmodified pseries kernel can
> either start via:
> 1. kexec, this requires presence of RTAS and skips
> ibm,client-architecture-support entirely;
> 2. normal boot, this heavily relies on the OF1275 client interface to
> fetch the device tree and do early setup (claim memory).
> 
> This adds a new bios-less mode to the pseries machine: "bios=on|off".
> When enabled, QEMU does not load SLOF and jumps to the kernel from
> "-kernel".
> 
> The client interface is implemented exactly as RTAS - a 20 bytes blob,
> right next after the RTAS blob. The entry point is passed to the kernel
> via GPR5.
> 
> This implements a handful of client interface methods just to get going.
> In particular, this implements the device tree fetching,
> ibm,client-architecture-support and instantiate-rtas.
> This does not implement changing properties, i.e. "setprop".
> 
> This assigns "phandles" to device tree nodes as there is no more SLOF
> and OF nodes addresses of which served as phandle values.
> This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
> phandles are regenerated at every FDT rebuild.
> 
> When bios=off, this adds "/chosen" every time QEMU builds a tree.
> 
> This implements "claim" which the client (Linux) uses for memory
> allocation; this is also  used by QEMU for claiming kernel/initrd images
> and the initial stack.
> 
> While at this, add a "kernel-addr" machine parameter to allow moving
> the kernel in memory. This is useful for debugging if the kernel is
> loaded at @0, although not necessary.
> 
> This does not implement instances properly but in order to boot a VM,
> we only really need a stdout instance and the "/" instance for
> "call-method", we fake these.
> 
> Sadly Petitboot still does not boot the selected system:
> "Must be root to change default boot option" (the message is likely
> to be misleading), debugging.
> 
> The test command line:
> 
> qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline \
> -nographic \
> -vga none \
> -kernel vmldbg \
> -machine pseries,bios=off \
> -m 4G \
> -enable-kvm \
> -initrd pb/rootfs.cpio.xz \
> img/u1804-64le.qcow2 \
> -snapshot \
> -smp 8,threads=8 \
> -L /home/aik/t/qemu-ppc64-bios/ \
> -trace events=qemu_trace_events \
> -d guest_errors \
> -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
> -mon chardev=SOCKET0,mode=control
> 
> Cc: Paul Mackerras 
> Cc: Nicholas Piggin 
> Cc: Michael Ellerman 
> Cc: Michael Roth 
> Cc: Fabiano Rosas 
> Cc: Leonardo Bras 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  hw/ppc/Makefile.objs   |   1 +
>  include/hw/loader.h|   1 +
>  include/hw/ppc/spapr.h |  25 ++-
>  hw/ppc/spapr.c | 207 +---
>  hw/ppc/spapr_client.c  | 423 +
>  hw/ppc/spapr_hcall.c   |  47 +++--
>  hw/ppc/trace-events|   7 +
>  7 files changed, 676 insertions(+), 35 deletions(-)
>  create mode 100644 hw/ppc/spapr_client.c
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 101e9fc59185..ce31c0acd2fb 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
> spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
>  obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
> +obj-$(CONFIG_PSERIES) += spapr_client.o
>  obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
>  # IBM PowerNV
>  obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
> pnv_occ.o pnv_bmc.o
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 48a96cd55904..a2f58077a47e 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
> *blob, size_t len,
>  int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void 
> *data,
>  size_t datasize, size_t romsize, hwaddr addr,
>  AddressSpace *as);
> +bool rom_intersect(uint64_t start, uint64_t size);
>  int rom_check_and_register_reset(void);
>  void rom_set_fw(FWCfgState *f);
>  void rom_set_order_override(int order);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 61f005c6f686..876879d12029 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -105,6 +105,11 @@ struct SpaprCapabilities {
>

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Corey Minyard]

On Sun, Jan 05, 2020 at 07:33:55AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:
> > According to ACPI spec, _ADR should be used for device which is on a
> > bus that has a standard enumeration algorithm. It does not make sense
> > to have a _ADR object for devices which already have _HID and will be
> > enumerated by OSPM.
> > 
> > Signed-off-by: Heyi Guo 
> 
> Are you sure? I would think this depends on the ID and the device
> really. E.g. PCI devices all are expected to have _ADR and some of them
> have a _HID.

That's my understanding, too.

> 
> CC Corey who added a device with both HID and ADR to x86 recenly.
> 
> Apropos Corey, why was HID APP0005 chosen?

I don't remember.  I thought I had looked it up someplace, but I didn't
document it.

>From reading the spec, I believe you could safely delete the _HID and it
would be fine.  However, I don't see anything that says it can't be
there, either.  But it is extraneous.

Searching on the web a bit, I see that the APP0005 has confused windows.
It does look to be wrong.  Maybe deleting it would be a good idea.

-corey

> 
> > ---
> > Cc: Shannon Zhao 
> > Cc: Peter Maydell 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Igor Mammedov 
> > Cc: qemu-...@nongnu.org
> > Cc: qemu-devel@nongnu.org
> > ---
> >  hw/arm/virt-acpi-build.c  |   8 
> >  tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
> >  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
> >  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
> >  4 files changed, 8 deletions(-)
> > 
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 9f4c7d1889..be752c0ad8 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const 
> > MemMapEntry *uart_memmap,
> >   AML_EXCLUSIVE, _irq, 1));
> >  aml_append(dev, aml_name_decl("_CRS", crs));
> >  
> > -/* The _ADR entry is used to link this device to the UART described
> > - * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
> > - */
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
> > -
> >  aml_append(scope, dev);
> >  }
> >  
> > @@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
> > MemMapEntry *memmap,
> >  aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
> >  aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
> >  aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
> >  aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> > @@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const 
> > MemMapEntry *gpio_memmap,
> >  {
> >  Aml *dev = aml_device("GPO0");
> >  aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >  
> >  Aml *crs = aml_resource_template();
> > @@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
> >  {
> >  Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
> >  aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >  aml_append(scope, dev);
> >  }
> > diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT
> 
> 
> Please do not include binary changes in acpi patches.
> 
> See comment at the top of tests/bios-tables-test.c for documentation
> on how to update these.
> 
> -- 
> MST
> 

Re: [PATCH] plugins/core: add missing break in cb_to_tcg_flags

[Richard Henderson]

On 1/5/20 5:29 PM, Emilio G. Cota wrote:
> Reported-by: Robert Henry 
> Signed-off-by: Emilio G. Cota 
> ---
>  plugins/core.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH] RISCV: support riscv vector extension 0.7.1

[Richard Henderson]

On 12/30/19 6:11 PM, LIU Zhiwei wrote:
> 
> However It's not clear when use tcg_gen_gvec_*_ptr or tcg_gen_gvec_ool. I 
> think
> the meaning of oprsz is the
> the bits of active elements.  Therefore , oprsz is  8 * env->vext.vl in RISC-V
> and it can't be fetched  from
> TB_FLAGS like SVE.
> 
> Probably oprsz field will be not be used in RISC-V vector extension.

Correct.  For those risc-v helpers that are called when VL != VLMAX, you would
ignore the oprsz field and fetch it from env.

It may still be handy to pass in vlmax as maxsz, even if you leave the oprsz
field 0.  You'll find that out as you do the coding, I suppose.


r~

Re: [PATCH v6 12/21] libqtest: add in-process qtest.c tx/rx handlers

[Alexander Bulekov]

On 200103 1115, Stefan Hajnoczi wrote:
> On Fri, Nov 29, 2019 at 09:34:47PM +, Oleinik, Alexander wrote:
> > +QTestState *qtest_inproc_init(QTestState **s, bool log, const char* arch,
> > +void (*send)(void*, const char*))
> > +{
> > +QTestState *qts;
> > +qts = g_new0(QTestState, 1);
> > +*s = qts; /* Expose qts early on, since the query endianness relies on 
> > it */
> > +qts->wstatus = 0;
> > +for (int i = 0; i < MAX_IRQ; i++) {
> > +qts->irq_level[i] = false;
> > +}
> > +
> > +qtest_client_set_rx_handler(qts, qtest_client_inproc_recv_line);
> > +
> > +/* send() may not have a matching protoype, so use a type-safe wrapper 
> > */
> > +qts->ops.external_send = send;
> > +qtest_client_set_tx_handler(qts, send_wrapper);
> > +
> > +qts->big_endian = qtest_query_target_endianness(qts);
> > +gchar *bin_path = g_strconcat("/qemu-system-", arch, NULL);
> > +setenv("QTEST_QEMU_BINARY", bin_path, 0);
> > +g_free(bin_path);
> 
> Is this a dummy path that is needed to make other code happy?  Or does
> the user need to have an actual file at /qemu-system-ARCH?

Yes - with the inproc mode this is only needed to make qtest_get_arch
happy, which simply returns the suffix of the env variable. Standard
qtest initialization relies on it in qtest_init_without_qmp_handshake,
but that function is not used by the fuzzer.

Re: [PATCH v6 02/21] libqos: Rename i2c_send and i2c_recv

[Alexander Bulekov]

On 200103 1201, Philippe Mathieu-Daudé wrote:
> On 12/9/19 1:02 PM, Thomas Huth wrote:
> > On 29/11/2019 22.34, Oleinik, Alexander wrote:
> > > The names i2c_send and i2c_recv collide with functions defined in
> > > hw/i2c/core.c. This causes an error when linking against libqos and
> > > softmmu simultaneously (for example when using qtest inproc). Rename the
> > > libqos functions to avoid this.
> > > 
> > > Signed-off-by: Alexander Bulekov 
> > > ---
> > >   tests/libqos/i2c.c   | 10 +-
> > >   tests/libqos/i2c.h   |  4 ++--
> > >   tests/pca9552-test.c | 10 +-
> > >   3 files changed, 12 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/tests/libqos/i2c.c b/tests/libqos/i2c.c
> > > index 156114e745..38f800dbab 100644
> > > --- a/tests/libqos/i2c.c
> > > +++ b/tests/libqos/i2c.c
> > > @@ -10,12 +10,12 @@
> > >   #include "libqos/i2c.h"
> > >   #include "libqtest.h"
> > > -void i2c_send(QI2CDevice *i2cdev, const uint8_t *buf, uint16_t len)
> > > +void qi2c_send(QI2CDevice *i2cdev, const uint8_t *buf, uint16_t len)
> > >   {
> > >   i2cdev->bus->send(i2cdev->bus, i2cdev->addr, buf, len);
> > >   }
> > > -void i2c_recv(QI2CDevice *i2cdev, uint8_t *buf, uint16_t len)
> > > +void qi2c_recv(QI2CDevice *i2cdev, uint8_t *buf, uint16_t len)
> > >   {
> > >   i2cdev->bus->recv(i2cdev->bus, i2cdev->addr, buf, len);
> > >   }
> > 
> > I'd prefer qos_i2c_send and qos_i2c_recv instead ... but that's just a
> > matter of taste.
> > 
> > Acked-by: Thomas Huth 
> 
> Agreed.
> 
> Renamed qos_*:
> Reviewed-by: Philippe Mathieu-Daudé 
> 
Paolo originally suggested the qi2c names in the v3 patchset, since they
are consistent with the QI2CDevice struct and the qvirtio functions.
Prior to that they had worse i2c_test... names. Scanning through the
other function names in tests/libqos, it seems most qos_ functions are
related to the internals of the qos system (eg. qos_graph_init,
qos_node_create_machine ...), while q-prefixed functions are generally
hw-specific (eg. qpci_msix_enable, qfw_cfg_read_data,
qusb_pci_init_one). Of course this pattern isn't perfectly consistent
(eg. qos_init_sdhci_mm).

Unless there is something I'm missing, I'm leaning toward leaving the
functions named qi2c_recv, qi2c_send.

Re: [PATCH v6 01/21] softmmu: split off vl.c:main() into main.c

[Alexander Bulekov]

On 200103 0958, Stefan Hajnoczi wrote:
> On Fri, Nov 29, 2019 at 09:34:36PM +, Oleinik, Alexander wrote:
> > @@ -3853,7 +3834,7 @@ int main(int argc, char **argv, char **envp)
> >  set_memory_options(_slots, _size, machine_class);
> >  
> >  os_daemonize();
> > -rcu_disable_atfork();
> > +/* rcu_disable_atfork(); */
> >  
> >  if (pid_file && !qemu_write_pidfile(pid_file, )) {
> >  error_reportf_err(err, "cannot create PID file: ");
> 
> Did you find a solution for this?

Yes, though obviously it didn't make it into v6 :) I'm planning to just
check qtest_enabled(), since for now we are always using qtest.

Re: [Qemu-devel] [PATCH v4 3/7] target/riscv: Create function to test if FP is enabled

[Aurelien Jarno]

On 2020-01-05 17:36, Aurelien Jarno wrote:
> > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > index e0d4586760..2789215b5e 100644
> > --- a/target/riscv/csr.c
> > +++ b/target/riscv/csr.c
> 
> [ snip ]
> 
> > @@ -307,6 +307,7 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
> > target_ulong val)
> >  {
> >  target_ulong mstatus = env->mstatus;
> >  target_ulong mask = 0;
> > +int dirty;
> >  
> >  /* flush tlb on mstatus fields that affect VM */
> >  if (env->priv_ver <= PRIV_VERSION_1_09_1) {
> > @@ -340,8 +341,9 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
> > target_ulong val)
> >  
> >  mstatus = (mstatus & ~mask) | (val & mask);
> >  
> > -int dirty = ((mstatus & MSTATUS_FS) == MSTATUS_FS) |
> > -((mstatus & MSTATUS_XS) == MSTATUS_XS);
> > +dirty = (riscv_cpu_fp_enabled(env) &&
> > + ((mstatus & MSTATUS_FS) == MSTATUS_FS)) |
> > +((mstatus & MSTATUS_XS) == MSTATUS_XS);
> >  mstatus = set_field(mstatus, MSTATUS_SD, dirty);
> >  env->mstatus = mstatus;
> 
> This patch, and more precisely the above two hunks broke
> qemu-system-riscv64. More precisely, when running a Debian sid system
> inside QEMU, sshd hangs during key exchange.

The problem is that at this stage, mstatus != env->status. Prior to that
patch, dirty was computed exclusively on the new mstatus status, after
the update by val. With this patch, riscv_cpu_fp_enabled() refers to the
old value of mstatus. Therefore when FS is changed from "Off" (FS = 00)
to "Dirty" (FS == 11), the SD bit is not set.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH v4 3/7] target/riscv: Create function to test if FP is enabled

[Aurelien Jarno]

Hi,

On 2019-08-23 08:21, Alistair Francis wrote:
> Let's create a function that tests if floating point support is
> enabled. We can then protect all floating point operations based on if
> they are enabled.
> 
> This patch so far doesn't change anything, it's just preparing for the
> Hypervisor support for floating point operations.
> 
> Signed-off-by: Alistair Francis 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Christophe de Dinechin 
> Reviewed-by: Chih-Min Chao 
> Reviewed-by: Bin Meng 
> ---
>  target/riscv/cpu.h|  6 +-
>  target/riscv/cpu_helper.c | 10 ++
>  target/riscv/csr.c| 20 +++-
>  3 files changed, 26 insertions(+), 10 deletions(-)
> 

[ snip ]

> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index e0d4586760..2789215b5e 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c

[ snip ]

> @@ -307,6 +307,7 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
> target_ulong val)
>  {
>  target_ulong mstatus = env->mstatus;
>  target_ulong mask = 0;
> +int dirty;
>  
>  /* flush tlb on mstatus fields that affect VM */
>  if (env->priv_ver <= PRIV_VERSION_1_09_1) {
> @@ -340,8 +341,9 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
> target_ulong val)
>  
>  mstatus = (mstatus & ~mask) | (val & mask);
>  
> -int dirty = ((mstatus & MSTATUS_FS) == MSTATUS_FS) |
> -((mstatus & MSTATUS_XS) == MSTATUS_XS);
> +dirty = (riscv_cpu_fp_enabled(env) &&
> + ((mstatus & MSTATUS_FS) == MSTATUS_FS)) |
> +((mstatus & MSTATUS_XS) == MSTATUS_XS);
>  mstatus = set_field(mstatus, MSTATUS_SD, dirty);
>  env->mstatus = mstatus;

This patch, and more precisely the above two hunks broke
qemu-system-riscv64. More precisely, when running a Debian sid system
inside QEMU, sshd hangs during key exchange.

Reverting this commit "fixes" the issue up to the following commit which
breaks things again:

| commit bdce1a5c6d512257f83b6b6831bee2c975643bbd
| Author: Alistair Francis 
| Date:   Fri Aug 23 08:21:25 2019 -0700
| 
| target/riscv: Use TB_FLAGS_MSTATUS_FS for floating point
| 
| Use the TB_FLAGS_MSTATUS_FS macro when enabling floating point in the tb
| flags.
| 
| Signed-off-by: Alistair Francis 
| Reviewed-by: Palmer Dabbelt 
| Signed-off-by: Palmer Dabbelt 

I wonder if the issue is related to the fact that MSTATUS_FS and thus
TB_FLAGS_MSTATUS_FS actually consist in 2 bits and are not a simple
flag.

Overall I am able to get QEMU v4.2 working again by applying the
following patch:

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index e59343e13c..f0ff57e27a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -295,7 +295,7 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState *env, 
target_ulong *pc,
 #else
 *flags = cpu_mmu_index(env, 0);
 if (riscv_cpu_fp_enabled(env)) {
-*flags |= TB_FLAGS_MSTATUS_FS;
+*flags |= env->mstatus & MSTATUS_FS;
 }
 #endif
 }
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index da02f9f0b1..1754c6c575 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -307,7 +307,6 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
target_ulong val)
 {
 target_ulong mstatus = env->mstatus;
 target_ulong mask = 0;
-int dirty;
 
 /* flush tlb on mstatus fields that affect VM */
 if (env->priv_ver <= PRIV_VERSION_1_09_1) {
@@ -341,9 +340,8 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
target_ulong val)
 
 mstatus = (mstatus & ~mask) | (val & mask);
 
-dirty = (riscv_cpu_fp_enabled(env) &&
- ((mstatus & MSTATUS_FS) == MSTATUS_FS)) |
-((mstatus & MSTATUS_XS) == MSTATUS_XS);
+int dirty = ((mstatus & MSTATUS_FS) == MSTATUS_FS) |
+((mstatus & MSTATUS_XS) == MSTATUS_XS);
 mstatus = set_field(mstatus, MSTATUS_SD, dirty);
 env->mstatus = mstatus;
 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [PATCH 1/2] virtio: reset region cache when on queue deletion

[Yuri Benditovich]

On Sun, Jan 5, 2020 at 1:39 PM Michael S. Tsirkin  wrote:

> On Thu, Jan 02, 2020 at 09:09:04AM +0200, Yuri Benditovich wrote:
> >
> >
> > On Thu, Jan 2, 2020 at 1:50 AM Michael S. Tsirkin 
> wrote:
> >
> > On Thu, Dec 26, 2019 at 11:29:50AM +0200, Yuri Benditovich wrote:
> > > On Thu, Dec 26, 2019 at 10:58 AM Jason Wang 
> wrote:
> > > >
> > > >
> > > > On 2019/12/26 下午12:36, Yuri Benditovich wrote:
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1708480
> > > > > Fix leak of region reference that prevents complete
> > > > > device deletion on hot unplug.
> > > >
> > > >
> > > > More information is needed here, the bug said only q35 can meet
> this
> > > > issue. What makes q35 different here?
> > > >
> > >
> > > I do not have any ready answer, I did not dig into it too much.
> > > Probably Michael Tsirkin or Paolo Bonzini can answer without
> digging.
> >
> >
> >
> > > >
> > > > >
> > > > > Signed-off-by: Yuri Benditovich 
> > > > > ---
> > > > >   hw/virtio/virtio.c | 5 +
> > > > >   1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > > index 04716b5f6c..baadec8abc 100644
> > > > > --- a/hw/virtio/virtio.c
> > > > > +++ b/hw/virtio/virtio.c
> > > > > @@ -2340,6 +2340,11 @@ void virtio_del_queue(VirtIODevice
> *vdev, int
> > n)
> > > > >   vdev->vq[n].vring.num_default = 0;
> > > > >   vdev->vq[n].handle_output = NULL;
> > > > >   vdev->vq[n].handle_aio_output = NULL;
> > > > > +/*
> > > > > + * with vring.num = 0 the queue will be ignored
> > > > > + * in later loops of region cache reset
> > > > > + */
> > > >
> > > >
> > > > I can't get the meaning of this comment.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > > +virtio_virtqueue_reset_region_cache(>vq[n]);
> >
> >
> > Do we need to drop this from virtio_device_free_virtqueues then?
> >
> >
> >
> > Not mandatory. Repetitive  virtio_virtqueue_reset_region_cache does not
> do
> > anything bad.
> > Some of virtio devices do not do 'virtio_del_queue' at all. Currently
> > virtio_device_free_virtqueues resets region cache for them.
> > IMO, not calling 'virtio_del_queue' is a bug, but not in the scope of
> current
> > series, I'll take care of that later.
>
> Maybe we should just del all queues in virtio_device_unrealize?
> Will allow us to drop some logic tracking which vqs were created.
>
>
Yes, this is also possible with some rework of
virtio_device_free_virtqueues.
virtio-net has some additional operations around queue deletion, it deletes
queues when switches from single queue to multiple.


>
> >
> > > > >   g_free(vdev->vq[n].used_elems);
> > > > >   }
> > > > >
> > > >
> >
> >
>
>

Re: [PATCH 1/2] virtio: reset region cache when on queue deletion

[Yuri Benditovich]

On Sun, Jan 5, 2020 at 2:22 PM Michael S. Tsirkin  wrote:

> On Thu, Dec 26, 2019 at 06:36:48AM +0200, Yuri Benditovich wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1708480
> > Fix leak of region reference that prevents complete
> > device deletion on hot unplug.
> >
> > Signed-off-by: Yuri Benditovich 
>
> I rebased this on top of my tree.
>
> Got this:
>
>
> commit f3dee6a062c1f4445768296ee39070bab9863372
> Author: Yuri Benditovich 
> Date:   Thu Dec 26 06:36:48 2019 +0200
>
> virtio: reset region cache when on queue deletion
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1708480
> Fix leak of region reference that prevents complete
> device deletion on hot unplug.
>
> Signed-off-by: Yuri Benditovich 
> Message-Id: <20191226043649.14481-2-yuri.benditov...@daynix.com>
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 95d8ff8508..7b861e0ca0 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -2344,6 +2344,7 @@ void virtio_delete_queue(VirtQueue *vq)
>  vq->handle_aio_output = NULL;
>  g_free(vq->used_elems);
>  vq->used_elems = NULL;
> +virtio_virtqueue_reset_region_cache(vq);
>  }
>
>  void virtio_del_queue(VirtIODevice *vdev, int n)
>
> Can you confirm pls?
>

Yes, it is

Re: [PATCH v18 1/7] Wrapper function to wait on condition for the main loop mutex

[Greg Kurz]

On Thu,  2 Jan 2020 13:21:05 +0530
Ganesh Goudar  wrote:

> From: Aravinda Prasad 
> 
> Introduce a wrapper function to wait on condition for
> the main loop mutex. This function atomically releases
> the main loop mutex and causes the calling thread to
> block on the condition. This wrapper is required because
> qemu_global_mutex is a static variable.
> 
> Signed-off-by: Aravinda Prasad 
> Reviewed-by: David Gibson 
> Reviewed-by: Greg Kurz 
> ---

This should have your Signed-off-by: tag as well.

>  cpus.c   | 5 +
>  include/qemu/main-loop.h | 8 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/cpus.c b/cpus.c
> index b472378b70..79388d2b0f 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1835,6 +1835,11 @@ void qemu_mutex_unlock_iothread(void)
>  qemu_mutex_unlock(_global_mutex);
>  }
>  
> +void qemu_cond_wait_iothread(QemuCond *cond)
> +{
> +qemu_cond_wait(cond, _global_mutex);
> +}
> +
>  static bool all_vcpus_paused(void)
>  {
>  CPUState *cpu;
> diff --git a/include/qemu/main-loop.h b/include/qemu/main-loop.h
> index f6ba78ea73..a6d20b0719 100644
> --- a/include/qemu/main-loop.h
> +++ b/include/qemu/main-loop.h
> @@ -295,6 +295,14 @@ void qemu_mutex_lock_iothread_impl(const char *file, int 
> line);
>   */
>  void qemu_mutex_unlock_iothread(void);
>  
> +/*
> + * qemu_cond_wait_iothread: Wait on condition for the main loop mutex
> + *
> + * This function atomically releases the main loop mutex and causes
> + * the calling thread to block on the condition.
> + */
> +void qemu_cond_wait_iothread(QemuCond *cond);
> +
>  /* internal interfaces */
>  
>  void qemu_fd_register(int fd);

Re: [PATCH v2] Implement the Screamer sound chip for the mac99 machine type

[Programmingkid]

> On Jan 4, 2020, at 8:58 PM, Programmingkid  wrote:
> 
> I found the patch that breaks Screamer sound support for qemu-system-ppc. It 
> is this:
> 
> commit 2ceb8240fa4e4e30fb853565eb2bed3032d74f62
> Author: Kővágó, Zoltán 
> Date:   Thu Sep 19 23:24:11 2019 +0200
> 
>coreaudio: port to the new audio backend api
> 
>Signed-off-by: Kővágó, Zoltán 
>Message-id: 
> 586a1e66de5cbc6c5234f9ae556d24befb6afada.1568927990.git.dirty.ice...@gmail.com
>Signed-off-by: Gerd Hoffmann 
> 
> 
> Reversing this patch should make the Screamer patch work with the current git 
> version of QEMU.

@Peter Maydell

Does QEMU play audio correctly on your version of Mac OS X? I am using Mac OS 
10.12 and the audio sound demonically loud and scary. I am currently at this 
git revision:

f0dcfddecee8b860e015bb07d67cfcbdfbfd51d

Merge: 40f09ee833 725fe5d10d
Author: Peter Maydell 
Date:   Fri Jan 3 17:18:08 2020 +

Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
into staging

I have ran several tests with qemu-system-i386 using Windows guest with the 
ac97 and sb16 sound cards. It sounds just as bad for me on qemu-system-ppc. 

Thank you.

[PULL v3 27/32] tests: add virtio-scsi and virtio-blk seg_max_adjust test

[Michael S. Tsirkin]

From: Denis Plotnikov 

It tests proper seg_max_adjust settings for all machine types except
'none', 'isapc', 'microvm'

Signed-off-by: Denis Plotnikov 
Message-Id: <20191220140905.1718-3-dplotni...@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 tests/acceptance/virtio_seg_max_adjust.py | 134 ++
 1 file changed, 134 insertions(+)
 create mode 100755 tests/acceptance/virtio_seg_max_adjust.py

diff --git a/tests/acceptance/virtio_seg_max_adjust.py 
b/tests/acceptance/virtio_seg_max_adjust.py
new file mode 100755
index 00..5458573138
--- /dev/null
+++ b/tests/acceptance/virtio_seg_max_adjust.py
@@ -0,0 +1,134 @@
+#!/usr/bin/env python
+#
+# Test virtio-scsi and virtio-blk queue settings for all machine types
+#
+# Copyright (c) 2019 Virtuozzo International GmbH
+#
+# 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 sys
+import os
+import re
+
+sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..', 'python'))
+from qemu.machine import QEMUMachine
+from avocado_qemu import Test
+
+#list of machine types and virtqueue properties to test
+VIRTIO_SCSI_PROPS = {'seg_max_adjust': 'seg_max_adjust'}
+VIRTIO_BLK_PROPS = {'seg_max_adjust': 'seg-max-adjust'}
+
+DEV_TYPES = {'virtio-scsi-pci': VIRTIO_SCSI_PROPS,
+ 'virtio-blk-pci': VIRTIO_BLK_PROPS}
+
+VM_DEV_PARAMS = {'virtio-scsi-pci': ['-device', 'virtio-scsi-pci,id=scsi0'],
+ 'virtio-blk-pci': ['-device',
+'virtio-blk-pci,id=scsi0,drive=drive0',
+'-drive',
+'driver=null-co,id=drive0,if=none']}
+
+
+class VirtioMaxSegSettingsCheck(Test):
+@staticmethod
+def make_pattern(props):
+pattern_items = ['{0} = \w+'.format(prop) for prop in props]
+return '|'.join(pattern_items)
+
+def query_virtqueue(self, vm, dev_type_name):
+query_ok = False
+error = None
+props = None
+
+output = vm.command('human-monitor-command',
+command_line = 'info qtree')
+props_list = DEV_TYPES[dev_type_name].values();
+pattern = self.make_pattern(props_list)
+res = re.findall(pattern, output)
+
+if len(res) != len(props_list):
+props_list = set(props_list)
+res = set(res)
+not_found = props_list.difference(res)
+not_found = ', '.join(not_found)
+error = '({0}): The following properties not found: {1}'\
+ .format(dev_type_name, not_found)
+else:
+query_ok = True
+props = dict()
+for prop in res:
+p = prop.split(' = ')
+props[p[0]] = p[1]
+return query_ok, props, error
+
+def check_mt(self, mt, dev_type_name):
+with QEMUMachine(self.qemu_bin) as vm:
+vm.set_machine(mt["name"])
+for s in VM_DEV_PARAMS[dev_type_name]:
+vm.add_args(s)
+vm.launch()
+query_ok, props, error = self.query_virtqueue(vm, dev_type_name)
+
+if not query_ok:
+self.fail('machine type {0}: {1}'.format(mt['name'], error))
+
+for prop_name, prop_val in props.items():
+expected_val = mt[prop_name]
+self.assertEqual(expected_val, prop_val)
+
+@staticmethod
+def seg_max_adjust_enabled(mt):
+# machine types >= 5.0 should have seg_max_adjust = true
+# others seg_max_adjust = false
+mt = mt.split("-")
+
+# machine types with one line name and name like pc-x.x
+if len(mt) <= 2:
+return False
+
+# machine types like pc--x.x[.x]
+ver = mt[2]
+ver = ver.split(".");
+
+# versions >= 5.0 goes with seg_max_adjust enabled
+major = int(ver[0])
+
+if major >= 5:
+return True
+return False
+
+def test_machine_types(self):
+# collect all machine types except 'none', 'isapc', 'microvm'
+with QEMUMachine(self.qemu_bin) as vm:
+vm.launch()
+machines = [m['name'] for m in vm.command('query-machines')]
+vm.shutdown()
+machines.remove('none')
+machines.remove('isapc')
+machines.remove('microvm')
+
+for dev_type in DEV_TYPES:
+   

[PULL v3 31/32] intel_iommu: a fix to vtd_find_as_from_bus_num()

[Michael S. Tsirkin]

From: Liu Yi L 

Ensure the return value of vtd_find_as_from_bus_num() is NULL by
enforcing vtd_bus=NULL. This would help caller of vtd_find_as_from_bus_num()
to decide if any further operation on the returned vtd_bus.

Cc: qemu-sta...@nongnu.org
Cc: Kevin Tian 
Cc: Jacob Pan 
Cc: Peter Xu 
Cc: Yi Sun 
Signed-off-by: Liu Yi L 
Signed-off-by: Yi Sun 
Message-Id: <1578058086-4288-2-git-send-email-yi.l@intel.com>
Reviewed-by: Peter Xu 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/intel_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index ee06993675..609b80750a 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -948,6 +948,7 @@ static VTDBus *vtd_find_as_from_bus_num(IntelIOMMUState *s, 
uint8_t bus_num)
 return vtd_bus;
 }
 }
+vtd_bus = NULL;
 }
 return vtd_bus;
 }
-- 
MST

[PULL v3 29/32] virtio: reset region cache when on queue deletion

[Michael S. Tsirkin]

From: Yuri Benditovich 

https://bugzilla.redhat.com/show_bug.cgi?id=1708480
Fix leak of region reference that prevents complete
device deletion on hot unplug.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Yuri Benditovich 
Message-Id: <20191226043649.14481-2-yuri.benditov...@daynix.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 95d8ff8508..7b861e0ca0 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2344,6 +2344,7 @@ void virtio_delete_queue(VirtQueue *vq)
 vq->handle_aio_output = NULL;
 g_free(vq->used_elems);
 vq->used_elems = NULL;
+virtio_virtqueue_reset_region_cache(vq);
 }
 
 void virtio_del_queue(VirtIODevice *vdev, int n)
-- 
MST

[PULL v3 25/32] hw: fix using 4.2 compat in 5.0 machine types for i440fx/q35

[Michael S. Tsirkin]

From: Denis Plotnikov 

5.0 machine type uses 4.2 compats. This seems to be incorrect, since
the latests machine type by now is 5.0 and it should use its own
compat or shouldn't use any relying on the defaults.
Seems, like this appeared because of some problems on merge/rebase.

Signed-off-by: Denis Plotnikov 
Message-Id: <20191223072856.5369-1-dplotni...@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/pc_piix.c | 1 -
 hw/i386/pc_q35.c  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 721c7aa64e..fa12203079 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -425,7 +425,6 @@ static void pc_i440fx_5_0_machine_options(MachineClass *m)
 m->alias = "pc";
 m->is_default = 1;
 pcmc->default_cpu_version = 1;
-compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
 }
 
 DEFINE_I440FX_MACHINE(v5_0, "pc-i440fx-5.0", NULL,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 52f45735e4..84cf925cf4 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -354,7 +354,6 @@ static void pc_q35_5_0_machine_options(MachineClass *m)
 pc_q35_machine_options(m);
 m->alias = "q35";
 pcmc->default_cpu_version = 1;
-compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
 }
 
 DEFINE_Q35_MACHINE(v5_0, "pc-q35-5.0", NULL,
-- 
MST

[PULL v3 19/32] ACPI: add expected files for HMAT tests (acpihmat)

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
---
 tests/bios-tables-test-allowed-diff.h |   8 
 tests/data/acpi/pc/APIC.acpihmat  | Bin 0 -> 128 bytes
 tests/data/acpi/pc/DSDT.acpihmat  | Bin 0 -> 6455 bytes
 tests/data/acpi/pc/HMAT.acpihmat  | Bin 0 -> 280 bytes
 tests/data/acpi/pc/SRAT.acpihmat  | Bin 0 -> 280 bytes
 tests/data/acpi/q35/APIC.acpihmat | Bin 0 -> 128 bytes
 tests/data/acpi/q35/DSDT.acpihmat | Bin 0 -> 9203 bytes
 tests/data/acpi/q35/HMAT.acpihmat | Bin 0 -> 280 bytes
 tests/data/acpi/q35/SRAT.acpihmat | Bin 0 -> 280 bytes
 9 files changed, 8 deletions(-)

diff --git a/tests/bios-tables-test-allowed-diff.h 
b/tests/bios-tables-test-allowed-diff.h
index 3c9e0c979b..dfb8523c8b 100644
--- a/tests/bios-tables-test-allowed-diff.h
+++ b/tests/bios-tables-test-allowed-diff.h
@@ -1,9 +1 @@
 /* List of comma-separated changed AML files to ignore */
-"tests/data/acpi/pc/APIC.acpihmat",
-"tests/data/acpi/pc/SRAT.acpihmat",
-"tests/data/acpi/pc/HMAT.acpihmat",
-"tests/data/acpi/pc/DSDT.acpihmat",
-"tests/data/acpi/q35/APIC.acpihmat",
-"tests/data/acpi/q35/SRAT.acpihmat",
-"tests/data/acpi/q35/HMAT.acpihmat",
-"tests/data/acpi/q35/DSDT.acpihmat",
diff --git a/tests/data/acpi/pc/APIC.acpihmat b/tests/data/acpi/pc/APIC.acpihmat
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a21f164699bfccd8992ea1bdb5717f2dc3025496
 100644
GIT binary patch
literal 128
zcmZ<^@N{lqU|?Xp<>c?|5v<@85#a0y6k`O6f!H9Lf#JbFFwFr}2jX%tGJA8l)n3DUlYJT5~Da#Tw;OmQgB5
z;e`?xQH-Fp0w_-I0@g(f^nx~cZ9hWu2zi9`6;d?uRn+h7awwY80?9=Qh?+C!o9~>N
zIp@p_4clm3JxpZZtF6
zQqyh}m`6RXM_sK?U7@Go8VvOxF_0>z{4Y}*=owjb~^1iRBDC2O&%H{P469?*Yd<3S)Dt4h6;IOcSyOPx-
z!WD4$wLe@U78=P|`7%3EwMsS4-eFO_K#izg#6ML(cR4Bz6PvU5R=uHvG+44E7K{9y
z6ECfDk9kauEHJ*xci0Y#Ozbje@9J977{a4bE#a@qaH9S|m${5%)E3*q|Ah$V>+HR5
zu5SznPS1`HR78A%sRS%2D~3MY#1jLL=EdA9|33PCl*Ly0kI^5oPz%fKV$A2xtyHao
z-0T>LZR<>Hx$h*$A9Bj&|{_)z>HriG$3SBz5nl+Y*)M?Vn=~t1uE{d-UPP0_OVD*q(BW%2Nc(JOlG3`}LFI|f`=Sey^@YH<>9`(iJt-z0wM57Jv?U^J)4RXZ+GHZiZuivg
zZGaL;n`&*%U|YQl-P^pE?zTj1*ln||$CE>;08qMnTSSIE#X(PW*rT&8@3Y-ap)w>c
zd$`4zcfSRD54Sk;wjR1IcCXcUod*{#N6A~t70Nbl)vsq2eC6nCk-qYZHe0!lRqZA2
zi%uI!pXiIEwp6*U*AoELv*{_3{BnXN{9xN>e`_EP71Ng*)#Txr%OxH~VrDldeQQa<8Ge8=JMn+3DE47N^G3vzH=Wh8`3cdvXO%`;klFjC_}?-2FHc0qdkOl%cqf+NSnr(A-=_dWw&8kU!5Ae#H60Rg?h_=Nlq`P6jF9mmnKqB)ShY#u0?%&`j
zQ7BN5I`NVGHp^B}!6vPml`UkK;4co4N%PL1?(Xbn+DFnnxbOw}EpV#LQGS;#I_{Ye
zbGVO{g3JVSP@2b>jf!bzw(k6Sn~H{F8nwEJI1et3EHwE)Jt(s(vC}!
zP9%M
zs8J=79qOhAjU~ZX)99Y|i26vsLo)X}(|#xac-TX(R{{<3yLb5kU3)V)~po`^Blz
zDbrMGnlwd!dig~mK;Oii(44~9LGvUWYI
z9!00zR9E{I0;>@_0@|ja^FE-c3n;Y(#Az1y;TN|PVS?}tAV}K@)5_wVL)n@A1f^zp
z@^|E+YDW(Q8)tEl{?8|AYKvD9JMAQw8pprsv_!2c#{mw<^Hecw6i8M
zV{lN@GzSMYnmDKrt65%FGb%2WlInVl3Z1_cgBt)!nD#CzUyjj9F?_uSPmPfdORxE*
z`~`%nYeDs*OMFo3mWBA|!$}swQ=bBgzVKFko_e0*3i^4FXFo#yJT;Uj{qXzGXiy3S
zBVEAh6Jfq4DE5pg2M7Q9DbRfL!;#$mhG2-}-_m1q$81!w)DkM~dLM1B#FK{3k23?Y@DG5!5LM7{@gieM*uS(V_37ras
zN>;q117D}ZpzlalRYKKJsANq`XgUn~u4J8&(3w!EWSy1J*)V89vLf<>X=$NQ$@-Fn
zz7z&6O4gGSdNLF$Sx-smsW7N6S?45lE)*(RPfO_OFsLC}(N*P^e^`m(ckzXi2i3
zmC&=HP|5nTguWaGU6HJ>Na!n}P|12uLeCus)ynh6jannpOWkkdA+k@kZrc}B2(
zkRd^8mLZ@b1)2^Cq?x?mPU01_Z=MiD(R;0w^3bjitO7+I4R>CfqbaPX|iu4b)+6IEy#y@m1HD=)MtG8P`^wv!ddD&
zzI>?nXNek
Qg_O1sXWa%LGz<~_AAR>eTL1t6

literal 0
HcmV?d1

diff --git a/tests/data/acpi/pc/HMAT.acpihmat b/tests/data/acpi/pc/HMAT.acpihmat
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..c00f7ba6cd0acecbc4b158f430d29b2f32988522
 100644
GIT binary patch
literal 280
zcmeb9bqtYUWME*L;pFe^5v<@85#a0r6axw|fY=}!1~h;SWIjwBokmuNOFc;30ICth
zW`eR`Fhdzga*PcB{=?M+<*vJ6H|M*!-WC@U?fIv`?15Cr@;rh|!0TAyG
A0RR91

literal 0
HcmV?d1

diff --git a/tests/data/acpi/pc/SRAT.acpihmat b/tests/data/acpi/pc/SRAT.acpihmat
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..1dcae90aec688e88f9d212e632ff2e0dc7bc
 100644
GIT binary patch
literal 280
zcmWFzatx7RWME)C;N1+c3F
q8VCj-m|+T0)xmizPc?|5v<@85#a0y6k`O6f!H9Lf#JbFFwFr}2jX%tGJl1TZsreZQ3+HD9Lq;HVsVfQY0;|Op$crfCjjB<5o
zWT7}k(jb7O0QuoVfrNF?-snJw-g@gb{u6R*fS!8oH7Md!)c4Ko$TLd{h!53)oNxBM
z@0+(fGjFv^zvFkmxxkneRIYmUPO);m<@xBd7-Q6?Z>N#D!FqdsrPjA{sf^Xz
zDz^KqU%6JZ{<0l@9)@>53ay(FyY+>0@7B%egO9^oj6iSSia4i+v%@s`
z+5LLM%zw+D{c47ew*3-YYpFWo0I*k9WQhD4d(f;tPD3N2HS;s?(~9xt$n+^
zboujF?vx+=>Yu;4`v%Vdu!?UR-)j+lgztrXIUG8l4R);ei7t+<4Cg-^h{Lkap(9a9
zJ@@mni|zTpJ69Bb9Cx2jz=RtqD<*l<4Tt!}{bjD7W8j%9lL4#o2?S2z7)tL^uT
z?xlXGTV@gUgb{V!{A0+SaG3ve5VAp-J32aK!XDpf7<-pFmnWa6;m~Qr>B}}c<-Ryo7{D?H(`vN0Qat4O-d+<|Fva(Hs<(fJ
z+RVEel+(<@R|Q|qR@YAnR5is92z3gmD)Y+KP0Op`quIiTbNTcOX;qP`^$wnEcRdu9
z*DQx?L?d0~r)pNjBIcydGplCpvR#(SzRP+CKijDI$MAI8of7BcSfU_?EMyi~ud
zeLe-Hy@RKNtJjW+v-3%!%_q(?hk!3Z%P}y++(miDY5d_Zi?e*l?q`k*I()ijy_0??
zZQJMfM4@U1=VV1Gny}(o7pI{Ua#EUy>4#}%pLax>bxO0ENW)WVICM@=%#(VULLM7=
z>{i2DXKucaZ!6lS$obQ&7F`0z`;S;It#-FHxAE5ATrPvz!?Ue?l6%tcb!MvAPktZXV3Yw8jHF$)&>3gkUP@gk-A0Bh+N>GQXlHuL&^cx5M5ycJhE8tiN=+lozsTSX;UXcUFVFUbH>m)W9mex>zp-o
z#rO`QmJosOZ?F?2enPK3J7f}yiu=q#8z5$ZbU44rd^)*jLS5&)p>y8QIdAGj
zsOxkMovxwNHFYA?b)GVGo-%ZvGIb)7Yv;XrcQ*q@(}vE|rcQ*q#

[PULL v3 16/32] hmat acpi: Build Memory Side Cache Information Structure(s)

[Michael S. Tsirkin]

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 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.

Acked-by: Markus Armbruster 
Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-7-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/acpi/hmat.c | 69 +-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 4635d45dee..7c24bb5371 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -143,14 +143,62 @@ static void build_hmat_lb(GArray *table_data, 
HMAT_LB_Info *hmat_lb,
 g_free(entry_list);
 }
 
+/* ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure: Table 5-147 */
+static void build_hmat_cache(GArray *table_data, uint8_t total_levels,
+ NumaHmatCacheOptions *hmat_cache)
+{
+/*
+ * Cache Attributes: Bits [3:0] – Total Cache Levels
+ * for this Memory Proximity Domain
+ */
+uint32_t cache_attr = total_levels;
+
+/* Bits [7:4] : Cache Level described in this structure */
+cache_attr |= (uint32_t) hmat_cache->level << 4;
+
+/* Bits [11:8] - Cache Associativity */
+cache_attr |= (uint32_t) hmat_cache->associativity << 8;
+
+/* Bits [15:12] - Write Policy */
+cache_attr |= (uint32_t) hmat_cache->policy << 12;
+
+/* Bits [31:16] - Cache Line size in bytes */
+cache_attr |= (uint32_t) hmat_cache->line << 16;
+
+/* Type */
+build_append_int_noprefix(table_data, 2, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, 32, 4);
+/* Proximity Domain for the Memory */
+build_append_int_noprefix(table_data, hmat_cache->node_id, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+/* Memory Side Cache Size */
+build_append_int_noprefix(table_data, hmat_cache->size, 8);
+/* Cache Attributes */
+build_append_int_noprefix(table_data, cache_attr, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/*
+ * Number of SMBIOS handles (n)
+ * Linux kernel uses Memory Side Cache Information Structure
+ * without SMBIOS entries for now, so set Number of SMBIOS handles
+ * as 0.
+ */
+build_append_int_noprefix(table_data, 0, 2);
+}
+
 /* Build HMAT sub table structures */
 static void hmat_build_table_structs(GArray *table_data, NumaState *numa_state)
 {
 uint16_t flags;
 uint32_t num_initiator = 0;
 uint32_t initiator_list[MAX_NODES];
-int i, hierarchy, type;
+int i, hierarchy, type, cache_level, total_levels;
 HMAT_LB_Info *hmat_lb;
+NumaHmatCacheOptions *hmat_cache;
 
 for (i = 0; i < numa_state->num_nodes; i++) {
 flags = 0;
@@ -184,6 +232,25 @@ static void hmat_build_table_structs(GArray *table_data, 
NumaState *numa_state)
 }
 }
 }
+
+/*
+ * ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure:
+ * Table 5-147
+ */
+for (i = 0; i < numa_state->num_nodes; i++) {
+total_levels = 0;
+for (cache_level = 1; cache_level < HMAT_LB_LEVELS; cache_level++) {
+if (numa_state->hmat_cache[i][cache_level]) {
+total_levels++;
+}
+}
+for (cache_level = 0; cache_level <= total_levels; cache_level++) {
+hmat_cache = numa_state->hmat_cache[i][cache_level];
+if (hmat_cache) {
+build_hmat_cache(table_data, total_levels, hmat_cache);
+}
+}
+}
 }
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state)
-- 
MST

[PULL v3 13/32] numa: Extend CLI to provide memory side cache information

[Michael S. Tsirkin]

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).
Before using hmat-cache option, enable HMAT with -machine hmat=on.

Acked-by: Markus Armbruster 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-4-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Igor Mammedov 
---
 qapi/machine.json | 81 +--
 include/sysemu/numa.h |  5 +++
 hw/core/numa.c| 80 ++
 qemu-options.hx   | 17 +++--
 4 files changed, 179 insertions(+), 4 deletions(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index cf8faf5a2a..b3d30bc816 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -428,10 +428,12 @@
 #
 # @hmat-lb: memory latency and bandwidth information (Since: 5.0)
 #
+# @hmat-cache: memory side cache information (Since: 5.0)
+#
 # Since: 2.1
 ##
 { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
+  'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] }
 
 ##
 # @NumaOptions:
@@ -447,7 +449,8 @@
 'node': 'NumaNodeOptions',
 'dist': 'NumaDistOptions',
 'cpu': 'NumaCpuOptions',
-'hmat-lb': 'NumaHmatLBOptions' }}
+'hmat-lb': 'NumaHmatLBOptions',
+'hmat-cache': 'NumaHmatCacheOptions' }}
 
 ##
 # @NumaNodeOptions:
@@ -646,6 +649,80 @@
 '*latency': 'uint64',
 '*bandwidth': 'size' }}
 
+##
+# @HmatCacheAssociativity:
+#
+# Cache associativity in the Memory Side Cache Information Structure
+# of HMAT
+#
+# For more information of @HmatCacheAssociativity, see chapter
+# 5.2.27.5: Table 5-147 of ACPI 6.3 spec.
+#
+# @none: None (no memory side cache in this proximity domain,
+#  or cache associativity unknown)
+#
+# @direct: Direct Mapped
+#
+# @complex: Complex Cache Indexing (implementation specific)
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatCacheAssociativity',
+  'data': [ 'none', 'direct', 'complex' ] }
+
+##
+# @HmatCacheWritePolicy:
+#
+# Cache write policy in the Memory Side Cache Information Structure
+# of HMAT
+#
+# For more information of @HmatCacheWritePolicy, see chapter
+# 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
+#
+# @none: None (no memory side cache in this proximity domain,
+#  or cache write policy unknown)
+#
+# @write-back: Write Back (WB)
+#
+# @write-through: Write Through (WT)
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatCacheWritePolicy',
+  'data': [ 'none', 'write-back', 'write-through' ] }
+
+##
+# @NumaHmatCacheOptions:
+#
+# Set the memory side cache information for a given memory domain.
+#
+# For more information of @NumaHmatCacheOptions, see chapter
+# 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
+#
+# @node-id: the memory proximity domain to which the memory belongs.
+#
+# @size: the size of memory side cache in bytes.
+#
+# @level: the cache level described in this structure.
+#
+# @associativity: the cache associativity,
+# none/direct-mapped/complex(complex cache indexing).
+#
+# @policy: the write policy, none/write-back/write-through.
+#
+# @line: the cache Line size in bytes.
+#
+# Since: 5.0
+##
+{ 'struct': 'NumaHmatCacheOptions',
+  'data': {
+   'node-id': 'uint32',
+   'size': 'size',
+   'level': 'uint8',
+   'associativity': 'HmatCacheAssociativity',
+   'policy': 'HmatCacheWritePolicy',
+   'line': 'uint16' }}
+
 ##
 # @HostMemPolicy:
 #
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 70f93c83d7..ba693cc80b 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -91,6 +91,9 @@ struct NumaState {
 
 /* NUMA nodes HMAT Locality Latency and Bandwidth Information */
 HMAT_LB_Info *hmat_lb[HMAT_LB_LEVELS][HMAT_LB_TYPES];
+
+/* Memory Side Cache Information Structure */
+NumaHmatCacheOptions *hmat_cache[MAX_NODES][HMAT_LB_LEVELS];
 };
 typedef struct NumaState NumaState;
 
@@ -98,6 +101,8 @@ void set_numa_options(MachineState *ms, NumaOptions *object, 
Error **errp);
 void parse_numa_opts(MachineState *ms);
 void parse_numa_hmat_lb(NumaState *numa_state, NumaHmatLBOptions *node,
 Error **errp);
+void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
+   Error **errp);
 void numa_complete_configuration(MachineState *ms);
 void query_numa_node_mem(NumaNodeMem node_mem[], MachineState *ms);
 extern QemuOptsList qemu_numa_opts;
diff --git a/hw/core/numa.c b/hw/core/numa.c
index 34eb413f5d..747c9680b0 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -379,6 +379,73 @@ void parse_numa_hmat_lb(NumaState *numa_state, 
NumaHmatLBOptions *node,
 g_array_append_val(hmat_lb->list, lb_data);
 }
 
+void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
+   Error 

[PULL v3 32/32] intel_iommu: add present bit check for pasid table entries

[Michael S. Tsirkin]

From: Liu Yi L 

The present bit check for pasid entry (pe) and pasid directory
entry (pdire) were missed in previous commits as fpd bit check
doesn't require present bit as "Set". This patch adds the present
bit check for callers which wants to get a valid pe/pdire.

Cc: qemu-sta...@nongnu.org
Cc: Kevin Tian 
Cc: Jacob Pan 
Cc: Peter Xu 
Cc: Yi Sun 
Reviewed-by: Peter Xu 
Signed-off-by: Liu Yi L 
Message-Id: <1578058086-4288-3-git-send-email-yi.l@intel.com>
Reviewed-by: Peter Xu 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/intel_iommu_internal.h |  1 +
 hw/i386/intel_iommu.c  | 92 +++---
 2 files changed, 74 insertions(+), 19 deletions(-)

diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
index edcf9fc9bb..862033ebe6 100644
--- a/hw/i386/intel_iommu_internal.h
+++ b/hw/i386/intel_iommu_internal.h
@@ -479,6 +479,7 @@ typedef struct VTDRootEntry VTDRootEntry;
 #define VTD_PASID_ENTRY_FPD   (1ULL << 1) /* Fault Processing Disable 
*/
 
 /* PASID Granular Translation Type Mask */
+#define VTD_PASID_ENTRY_P  1ULL
 #define VTD_SM_PASID_ENTRY_PGTT(7ULL << 6)
 #define VTD_SM_PASID_ENTRY_FLT (1ULL << 6)
 #define VTD_SM_PASID_ENTRY_SLT (2ULL << 6)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 609b80750a..a523ef0e65 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -686,9 +686,18 @@ static inline bool vtd_pe_type_check(X86IOMMUState 
*x86_iommu,
 return true;
 }
 
-static int vtd_get_pasid_dire(dma_addr_t pasid_dir_base,
-  uint32_t pasid,
-  VTDPASIDDirEntry *pdire)
+static inline bool vtd_pdire_present(VTDPASIDDirEntry *pdire)
+{
+return pdire->val & 1;
+}
+
+/**
+ * Caller of this function should check present bit if wants
+ * to use pdir entry for futher usage except for fpd bit check.
+ */
+static int vtd_get_pdire_from_pdir_table(dma_addr_t pasid_dir_base,
+ uint32_t pasid,
+ VTDPASIDDirEntry *pdire)
 {
 uint32_t index;
 dma_addr_t addr, entry_size;
@@ -703,18 +712,22 @@ static int vtd_get_pasid_dire(dma_addr_t pasid_dir_base,
 return 0;
 }
 
-static int vtd_get_pasid_entry(IntelIOMMUState *s,
-   uint32_t pasid,
-   VTDPASIDDirEntry *pdire,
-   VTDPASIDEntry *pe)
+static inline bool vtd_pe_present(VTDPASIDEntry *pe)
+{
+return pe->val[0] & VTD_PASID_ENTRY_P;
+}
+
+static int vtd_get_pe_in_pasid_leaf_table(IntelIOMMUState *s,
+  uint32_t pasid,
+  dma_addr_t addr,
+  VTDPASIDEntry *pe)
 {
 uint32_t index;
-dma_addr_t addr, entry_size;
+dma_addr_t entry_size;
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(s);
 
 index = VTD_PASID_TABLE_INDEX(pasid);
 entry_size = VTD_PASID_ENTRY_SIZE;
-addr = pdire->val & VTD_PASID_TABLE_BASE_ADDR_MASK;
 addr = addr + index * entry_size;
 if (dma_memory_read(_space_memory, addr, pe, entry_size)) {
 return -VTD_FR_PASID_TABLE_INV;
@@ -732,25 +745,54 @@ static int vtd_get_pasid_entry(IntelIOMMUState *s,
 return 0;
 }
 
-static int vtd_get_pasid_entry_from_pasid(IntelIOMMUState *s,
-  dma_addr_t pasid_dir_base,
-  uint32_t pasid,
-  VTDPASIDEntry *pe)
+/**
+ * Caller of this function should check present bit if wants
+ * to use pasid entry for futher usage except for fpd bit check.
+ */
+static int vtd_get_pe_from_pdire(IntelIOMMUState *s,
+ uint32_t pasid,
+ VTDPASIDDirEntry *pdire,
+ VTDPASIDEntry *pe)
+{
+dma_addr_t addr = pdire->val & VTD_PASID_TABLE_BASE_ADDR_MASK;
+
+return vtd_get_pe_in_pasid_leaf_table(s, pasid, addr, pe);
+}
+
+/**
+ * This function gets a pasid entry from a specified pasid
+ * table (includes dir and leaf table) with a specified pasid.
+ * Sanity check should be done to ensure return a present
+ * pasid entry to caller.
+ */
+static int vtd_get_pe_from_pasid_table(IntelIOMMUState *s,
+   dma_addr_t pasid_dir_base,
+   uint32_t pasid,
+   VTDPASIDEntry *pe)
 {
 int ret;
 VTDPASIDDirEntry pdire;
 
-ret = vtd_get_pasid_dire(pasid_dir_base, pasid, );
+ret = vtd_get_pdire_from_pdir_table(pasid_dir_base,
+pasid, );
 if (ret) {
 return ret;
 }
 
-ret = vtd_get_pasid_entry(s, pasid, , pe);
+if (!vtd_pdire_present()) {
+return -VTD_FR_PASID_TABLE_INV;
+}
+
+ret 

[PULL v3 30/32] virtio-net: delete also control queue when TX/RX deleted

[Michael S. Tsirkin]

From: Yuri Benditovich 

https://bugzilla.redhat.com/show_bug.cgi?id=1708480
If the control queue is not deleted together with TX/RX, it
later will be ignored in freeing cache resources and hot
unplug will not be completed.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Yuri Benditovich 
Message-Id: <20191226043649.14481-3-yuri.benditov...@daynix.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/net/virtio-net.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index db3d7c38e6..f325440d01 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3101,7 +3101,8 @@ static void virtio_net_device_unrealize(DeviceState *dev, 
Error **errp)
 for (i = 0; i < max_queues; i++) {
 virtio_net_del_queue(n, i);
 }
-
+/* delete also control vq */
+virtio_del_queue(vdev, max_queues * 2);
 qemu_announce_timer_del(>announce_timer, false);
 g_free(n->vqs);
 qemu_del_nic(n->nic);
-- 
MST

[PULL v3 24/32] vhost-user-scsi: reset the device if supported

[Michael S. Tsirkin]

From: Raphael Norwitz 

If the vhost-user-scsi backend supports the VHOST_USER_F_RESET_DEVICE
protocol feature, then the device can be reset when requested.

If this feature is not supported, do not try a reset as this will send
a VHOST_USER_RESET_OWNER that the backend is not expecting,
potentially putting into an inoperable state.

Signed-off-by: David Vrabel 
Signed-off-by: Raphael Norwitz 
Message-Id: <1572385083-5254-3-git-send-email-raphael.norw...@nutanix.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/scsi/vhost-user-scsi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
index 6a6c15dd32..23f972df59 100644
--- a/hw/scsi/vhost-user-scsi.c
+++ b/hw/scsi/vhost-user-scsi.c
@@ -39,6 +39,10 @@ static const int user_feature_bits[] = {
 VHOST_INVALID_FEATURE_BIT
 };
 
+enum VhostUserProtocolFeature {
+VHOST_USER_PROTOCOL_F_RESET_DEVICE = 13,
+};
+
 static void vhost_user_scsi_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserSCSI *s = (VHostUserSCSI *)vdev;
@@ -62,6 +66,25 @@ static void vhost_user_scsi_set_status(VirtIODevice *vdev, 
uint8_t status)
 }
 }
 
+static void vhost_user_scsi_reset(VirtIODevice *vdev)
+{
+VHostSCSICommon *vsc = VHOST_SCSI_COMMON(vdev);
+struct vhost_dev *dev = >dev;
+
+/*
+ * Historically, reset was not implemented so only reset devices
+ * that are expecting it.
+ */
+if (!virtio_has_feature(dev->protocol_features,
+VHOST_USER_PROTOCOL_F_RESET_DEVICE)) {
+return;
+}
+
+if (dev->vhost_ops->vhost_reset_device) {
+dev->vhost_ops->vhost_reset_device(dev);
+}
+}
+
 static void vhost_dummy_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
 }
@@ -182,6 +205,7 @@ static void vhost_user_scsi_class_init(ObjectClass *klass, 
void *data)
 vdc->get_features = vhost_scsi_common_get_features;
 vdc->set_config = vhost_scsi_common_set_config;
 vdc->set_status = vhost_user_scsi_set_status;
+vdc->reset = vhost_user_scsi_reset;
 fwc->get_dev_path = vhost_scsi_common_get_fw_dev_path;
 }
 
-- 
MST

[PULL v3 11/32] numa: Extend CLI to provide initiator information for numa nodes

[Michael S. Tsirkin]

From: Tao Xu 

In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT),
The initiator represents processor which access to memory. And in 5.2.27.3
Memory Proximity Domain Attributes Structure, the attached initiator is
defined as where the memory controller responsible for a memory proximity
domain. With attached initiator information, the topology of heterogeneous
memory can be described. Add new machine property 'hmat' to enable all
HMAT specific options.

Extend CLI of "-numa node" option to indicate the initiator numa node-id.
In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
the platform's HMAT tables. Before using initiator option, enable HMAT with
-machine hmat=on.

Acked-by: Markus Armbruster 
Reviewed-by: Igor Mammedov 
Reviewed-by: Jingqi Liu 
Suggested-by: Dan Williams 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-2-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 qapi/machine.json | 10 ++-
 include/sysemu/numa.h |  5 
 hw/core/machine.c | 64 +++
 hw/core/numa.c| 23 
 qemu-options.hx   | 35 +++
 5 files changed, 131 insertions(+), 6 deletions(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index ca26779f1a..27d0e37534 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -463,6 +463,13 @@
 # @memdev: memory backend object.  If specified for one node,
 #  it must be specified for all nodes.
 #
+# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145,
+# points to the nodeid which has the memory controller
+# responsible for this NUMA node. This field provides
+# additional information as to the initiator node that
+# is closest (as in directly attached) to this node, and
+# therefore has the best performance (since 5.0)
+#
 # Since: 2.1
 ##
 { 'struct': 'NumaNodeOptions',
@@ -470,7 +477,8 @@
'*nodeid': 'uint16',
'*cpus':   ['uint16'],
'*mem':'size',
-   '*memdev': 'str' }}
+   '*memdev': 'str',
+   '*initiator': 'uint16' }}
 
 ##
 # @NumaDistOptions:
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index ae9c41d02b..788cbec7a2 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -18,6 +18,8 @@ struct NodeInfo {
 uint64_t node_mem;
 struct HostMemoryBackend *node_memdev;
 bool present;
+bool has_cpu;
+uint16_t initiator;
 uint8_t distance[MAX_NODES];
 };
 
@@ -33,6 +35,9 @@ struct NumaState {
 /* Allow setting NUMA distance for different NUMA nodes */
 bool have_numa_distance;
 
+/* Detect if HMAT support is enabled. */
+bool hmat_enabled;
+
 /* NUMA nodes information */
 NodeInfo nodes[MAX_NODES];
 };
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 0854dcebdd..f5e2b32b3b 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -430,6 +430,20 @@ static void machine_set_nvdimm(Object *obj, bool value, 
Error **errp)
 ms->nvdimms_state->is_enabled = value;
 }
 
+static bool machine_get_hmat(Object *obj, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+return ms->numa_state->hmat_enabled;
+}
+
+static void machine_set_hmat(Object *obj, bool value, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+ms->numa_state->hmat_enabled = value;
+}
+
 static char *machine_get_nvdimm_persistence(Object *obj, Error **errp)
 {
 MachineState *ms = MACHINE(obj);
@@ -557,6 +571,7 @@ void machine_set_cpu_numa_node(MachineState *machine,
const CpuInstanceProperties *props, Error 
**errp)
 {
 MachineClass *mc = MACHINE_GET_CLASS(machine);
+NodeInfo *numa_info = machine->numa_state->nodes;
 bool match = false;
 int i;
 
@@ -626,6 +641,17 @@ void machine_set_cpu_numa_node(MachineState *machine,
 match = true;
 slot->props.node_id = props->node_id;
 slot->props.has_node_id = props->has_node_id;
+
+if (machine->numa_state->hmat_enabled) {
+if ((numa_info[props->node_id].initiator < MAX_NODES) &&
+(props->node_id != numa_info[props->node_id].initiator)) {
+error_setg(errp, "The initiator of CPU NUMA node %" PRId64
+" should be itself", props->node_id);
+return;
+}
+numa_info[props->node_id].has_cpu = true;
+numa_info[props->node_id].initiator = props->node_id;
+}
 }
 
 if (!match) {
@@ -846,6 +872,13 @@ static void machine_initfn(Object *obj)
 
 if (mc->numa_mem_supported) {
 ms->numa_state = g_new0(NumaState, 1);
+object_property_add_bool(obj, "hmat",
+ machine_get_hmat, machine_set_hmat,
+ _abort);
+object_property_set_description(obj, "hmat",
+"Set on/off to enable/disable 

[PULL v3 28/32] virtio-mmio: update queue size on guest write

[Michael S. Tsirkin]

From: Denis Plotnikov 

Some guests read back queue size after writing it.
Always update the on size write otherwise they might be confused.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Denis Plotnikov 
Message-Id: <20191224081446.17003-1-dplotni...@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio-mmio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index ef40b7a9b2..872f2cd237 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -308,8 +308,9 @@ static void virtio_mmio_write(void *opaque, hwaddr offset, 
uint64_t value,
 break;
 case VIRTIO_MMIO_QUEUE_NUM:
 trace_virtio_mmio_queue_write(value, VIRTQUEUE_MAX_SIZE);
+virtio_queue_set_num(vdev, vdev->queue_sel, value);
+
 if (proxy->legacy) {
-virtio_queue_set_num(vdev, vdev->queue_sel, value);
 virtio_queue_update_rings(vdev, vdev->queue_sel);
 } else {
 proxy->vqs[vdev->queue_sel].num = value;
-- 
MST

[PULL v3 23/32] vhost-user: add VHOST_USER_RESET_DEVICE to reset devices

[Michael S. Tsirkin]

From: Raphael Norwitz 

Add a VHOST_USER_RESET_DEVICE message which will reset the vhost user
backend. Disabling all rings, and resetting all internal state, ready
for the backend to be reinitialized.

A backend has to report it supports this features with the
VHOST_USER_PROTOCOL_F_RESET_DEVICE protocol feature bit. If it does
so, the new message is used instead of sending a RESET_OWNER which has
had inconsistent implementations.

Signed-off-by: David Vrabel 
Signed-off-by: Raphael Norwitz 
Message-Id: <1572385083-5254-2-git-send-email-raphael.norw...@nutanix.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/vhost-user.c  |  8 +++-
 docs/interop/vhost-user.rst | 15 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 02a9b25199..d27a10fcc6 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -58,6 +58,7 @@ enum VhostUserProtocolFeature {
 VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD = 10,
 VHOST_USER_PROTOCOL_F_HOST_NOTIFIER = 11,
 VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD = 12,
+VHOST_USER_PROTOCOL_F_RESET_DEVICE = 13,
 VHOST_USER_PROTOCOL_F_MAX
 };
 
@@ -98,6 +99,7 @@ typedef enum VhostUserRequest {
 VHOST_USER_GET_INFLIGHT_FD = 31,
 VHOST_USER_SET_INFLIGHT_FD = 32,
 VHOST_USER_GPU_SET_SOCKET = 33,
+VHOST_USER_RESET_DEVICE = 34,
 VHOST_USER_MAX
 } VhostUserRequest;
 
@@ -890,10 +892,14 @@ static int vhost_user_set_owner(struct vhost_dev *dev)
 static int vhost_user_reset_device(struct vhost_dev *dev)
 {
 VhostUserMsg msg = {
-.hdr.request = VHOST_USER_RESET_OWNER,
 .hdr.flags = VHOST_USER_VERSION,
 };
 
+msg.hdr.request = virtio_has_feature(dev->protocol_features,
+ VHOST_USER_PROTOCOL_F_RESET_DEVICE)
+? VHOST_USER_RESET_DEVICE
+: VHOST_USER_RESET_OWNER;
+
 if (vhost_user_write(dev, , NULL, 0) < 0) {
 return -1;
 }
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 015ac08177..5f8b3a456b 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -785,6 +785,7 @@ Protocol features
   #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD  10
   #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER  11
   #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
+  #define VHOST_USER_PROTOCOL_F_RESET_DEVICE   13
 
 Master message types
 
@@ -1190,6 +1191,20 @@ Master message types
   ancillary data. The GPU protocol is used to inform the master of
   rendering state and updates. See vhost-user-gpu.rst for details.
 
+``VHOST_USER_RESET_DEVICE``
+  :id: 34
+  :equivalent ioctl: N/A
+  :master payload: N/A
+  :slave payload: N/A
+
+  Ask the vhost user backend to disable all rings and reset all
+  internal device state to the initial state, ready to be
+  reinitialized. The backend retains ownership of the device
+  throughout the reset operation.
+
+  Only valid if the ``VHOST_USER_PROTOCOL_F_RESET_DEVICE`` protocol
+  feature is set by the backend.
+
 Slave message types
 ---
 
-- 
MST

[PULL v3 17/32] tests/numa: Add case for QMP build HMAT

[Michael S. Tsirkin]

From: Tao Xu 

Check configuring HMAT usecase

Acked-by: Markus Armbruster 
Suggested-by: Igor Mammedov 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-8-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Igor Mammedov 
---
 tests/numa-test.c | 213 ++
 1 file changed, 213 insertions(+)

diff --git a/tests/numa-test.c b/tests/numa-test.c
index 8de8581231..17dd807d2a 100644
--- a/tests/numa-test.c
+++ b/tests/numa-test.c
@@ -327,6 +327,216 @@ static void pc_dynamic_cpu_cfg(const void *data)
 qtest_quit(qs);
 }
 
+static void pc_hmat_build_cfg(const void *data)
+{
+QTestState *qs = qtest_initf("%s -nodefaults --preconfig -machine hmat=on "
+ "-smp 2,sockets=2 "
+ "-m 128M,slots=2,maxmem=1G "
+ "-object memory-backend-ram,size=64M,id=m0 "
+ "-object memory-backend-ram,size=64M,id=m1 "
+ "-numa node,nodeid=0,memdev=m0 "
+ "-numa node,nodeid=1,memdev=m1,initiator=0 "
+ "-numa cpu,node-id=0,socket-id=0 "
+ "-numa cpu,node-id=0,socket-id=1",
+ data ? (char *)data : "");
+
+/* Fail: Initiator should be less than the number of nodes */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 2, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Target should be less than the number of nodes */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 2,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Initiator should contain cpu */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 1, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Data-type mismatch */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"write-latency\","
+" 'bandwidth': 524288000 } }")));
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"read-bandwidth\","
+" 'latency': 5 } }")));
+
+/* Fail: Bandwidth should be 1MB (1048576) aligned */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 1048575 } }")));
+
+/* Configuring HMAT bandwidth and latency details */
+g_assert_false(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 1 } }")));/* 1 ns */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 5 } }")));/* Fail: Duplicate configuration */
+g_assert_false(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 68717379584 } }")));/* 65534 MB/s */
+g_assert_false(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 65534 } }")));/* 65534 ns */
+g_assert_false(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 34358689792 } }")));/* 32767 MB/s */
+
+/* Fail: node_id should be less than the number of nodes */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-cache', 'node-id': 2, 'size': 10240,"
+" 'level': 1, 'associativity': \"direct\", 'policy': \"write-back\","
+" 'line': 8 } }")));
+
+/* Fail: level should be less than HMAT_LB_LEVELS (4) */
+g_assert_true(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 

[PULL v3 10/32] virtio: don't enable notifications during polling

[Michael S. Tsirkin]

From: Stefan Hajnoczi 

Virtqueue notifications are not necessary during polling, so we disable
them.  This allows the guest driver to avoid MMIO vmexits.
Unfortunately the virtio-blk and virtio-scsi handler functions re-enable
notifications, defeating this optimization.

Fix virtio-blk and virtio-scsi emulation so they leave notifications
disabled.  The key thing to remember for correctness is that polling
always checks one last time after ending its loop, therefore it's safe
to lose the race when re-enabling notifications at the end of polling.

There is a measurable performance improvement of 5-10% with the null-co
block driver.  Real-life storage configurations will see a smaller
improvement because the MMIO vmexit overhead contributes less to
latency.

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20191209210957.65087-1-stefa...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/virtio/virtio.h |  1 +
 hw/block/virtio-blk.c  |  9 +++--
 hw/scsi/virtio-scsi.c  |  9 +++--
 hw/virtio/virtio.c | 12 ++--
 4 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 72475c..b69d517496 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -228,6 +228,7 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
version_id);
 
 void virtio_notify_config(VirtIODevice *vdev);
 
+bool virtio_queue_get_notification(VirtQueue *vq);
 void virtio_queue_set_notification(VirtQueue *vq, int enable);
 
 int virtio_queue_ready(VirtQueue *vq);
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index d62e6377c2..b12157b5eb 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -764,13 +764,16 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
 {
 VirtIOBlockReq *req;
 MultiReqBuffer mrb = {};
+bool suppress_notifications = virtio_queue_get_notification(vq);
 bool progress = false;
 
 aio_context_acquire(blk_get_aio_context(s->blk));
 blk_io_plug(s->blk);
 
 do {
-virtio_queue_set_notification(vq, 0);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 0);
+}
 
 while ((req = virtio_blk_get_request(s, vq))) {
 progress = true;
@@ -781,7 +784,9 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
 }
 }
 
-virtio_queue_set_notification(vq, 1);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 1);
+}
 } while (!virtio_queue_empty(vq));
 
 if (mrb.num_reqs) {
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index e8b2b64d09..f080545f48 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -597,12 +597,15 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue 
*vq)
 {
 VirtIOSCSIReq *req, *next;
 int ret = 0;
+bool suppress_notifications = virtio_queue_get_notification(vq);
 bool progress = false;
 
 QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs);
 
 do {
-virtio_queue_set_notification(vq, 0);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 0);
+}
 
 while ((req = virtio_scsi_pop_req(s, vq))) {
 progress = true;
@@ -622,7 +625,9 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq)
 }
 }
 
-virtio_queue_set_notification(vq, 1);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 1);
+}
 } while (ret != -EINVAL && !virtio_queue_empty(vq));
 
 QTAILQ_FOREACH_SAFE(req, , next, next) {
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7bc6a9455e..95d8ff8508 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -432,6 +432,11 @@ static void virtio_queue_packed_set_notification(VirtQueue 
*vq, int enable)
 }
 }
 
+bool virtio_queue_get_notification(VirtQueue *vq)
+{
+return vq->notification;
+}
+
 void virtio_queue_set_notification(VirtQueue *vq, int enable)
 {
 vq->notification = enable;
@@ -3410,17 +3415,12 @@ static bool virtio_queue_host_notifier_aio_poll(void 
*opaque)
 {
 EventNotifier *n = opaque;
 VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
-bool progress;
 
 if (!vq->vring.desc || virtio_queue_empty(vq)) {
 return false;
 }
 
-progress = virtio_queue_notify_aio_vq(vq);
-
-/* In case the handler function re-enabled notifications */
-virtio_queue_set_notification(vq, 0);
-return progress;
+return virtio_queue_notify_aio_vq(vq);
 }
 
 static void virtio_queue_host_notifier_aio_poll_end(EventNotifier *n)
-- 
MST

[PULL v3 22/32] hw/pci/pci_host: Let pci_data_[read/write] use unsigned 'size' argument

[Michael S. Tsirkin]

From: Philippe Mathieu-Daudé 

Both functions are called by MemoryRegionOps.[read/write] handlers
with unsigned 'size' argument. Both functions call
pci_host_config_[read/write]_common() which expect a uint32_t 'len'
parameter (also unsigned).
Since it is pointless (and confuse) to use a signed value, use a
unsigned type.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191216002134.18279-3-phi...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/pci/pci_host.h | 4 ++--
 hw/pci/pci_host.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/hw/pci/pci_host.h b/include/hw/pci/pci_host.h
index ba31595fc7..9ce088bd13 100644
--- a/include/hw/pci/pci_host.h
+++ b/include/hw/pci/pci_host.h
@@ -62,8 +62,8 @@ void pci_host_config_write_common(PCIDevice *pci_dev, 
uint32_t addr,
 uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
  uint32_t limit, uint32_t len);
 
-void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len);
-uint32_t pci_data_read(PCIBus *s, uint32_t addr, int len);
+void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, unsigned len);
+uint32_t pci_data_read(PCIBus *s, uint32_t addr, unsigned len);
 
 extern const MemoryRegionOps pci_host_conf_le_ops;
 extern const MemoryRegionOps pci_host_conf_be_ops;
diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
index 0958d157de..ce7bcdb1d5 100644
--- a/hw/pci/pci_host.c
+++ b/hw/pci/pci_host.c
@@ -106,7 +106,7 @@ uint32_t pci_host_config_read_common(PCIDevice *pci_dev, 
uint32_t addr,
 return ret;
 }
 
-void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len)
+void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, unsigned len)
 {
 PCIDevice *pci_dev = pci_dev_find_by_addr(s, addr);
 uint32_t config_addr = addr & (PCI_CONFIG_SPACE_SIZE - 1);
@@ -119,7 +119,7 @@ void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, 
int len)
  val, len);
 }
 
-uint32_t pci_data_read(PCIBus *s, uint32_t addr, int len)
+uint32_t pci_data_read(PCIBus *s, uint32_t addr, unsigned len)
 {
 PCIDevice *pci_dev = pci_dev_find_by_addr(s, addr);
 uint32_t config_addr = addr & (PCI_CONFIG_SPACE_SIZE - 1);
-- 
MST

[PULL v3 26/32] virtio: make seg_max virtqueue size dependent

[Michael S. Tsirkin]

From: Denis Plotnikov 

Before the patch, seg_max parameter was immutable and hardcoded
to 126 (128 - 2) without respect to queue size. This has two negative effects:

1. when queue size is < 128, we have Virtio 1.1 specfication violation:
   (2.6.5.3.1 Driver Requirements) seq_max must be <= queue_size.
   This violation affects the old Linux guests (ver < 4.14). These guests
   crash on these queue_size setups.

2. when queue_size > 128, as was pointed out by Denis Lunev 
,
   seg_max restrics guest's block request length which affects guests'
   performance making them issues more block request than needed.
   https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html

To mitigate this two effects, the patch adds the property adjusting seg_max
to queue size automaticaly. Since seg_max is a guest visible parameter,
the property is machine type managable and allows to choose between
old (seg_max = 126 always) and new (seg_max = queue_size - 2) behaviors.

Not to change the behavior of the older VMs, prevent setting the default
seg_max_adjust value for older machine types.

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Denis Plotnikov 
Message-Id: <20191220140905.1718-2-dplotni...@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/virtio/virtio-blk.h  |  1 +
 include/hw/virtio/virtio-scsi.h |  1 +
 hw/block/virtio-blk.c   |  9 -
 hw/core/machine.c   |  3 +++
 hw/scsi/vhost-scsi.c|  2 ++
 hw/scsi/virtio-scsi.c   | 10 +-
 6 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h
index 9c19f5b634..1e62f869b2 100644
--- a/include/hw/virtio/virtio-blk.h
+++ b/include/hw/virtio/virtio-blk.h
@@ -38,6 +38,7 @@ struct VirtIOBlkConf
 uint32_t request_merging;
 uint16_t num_queues;
 uint16_t queue_size;
+bool seg_max_adjust;
 uint32_t max_discard_sectors;
 uint32_t max_write_zeroes_sectors;
 bool x_enable_wce_if_config_wce;
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 122f7c4b6f..24e768909d 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -48,6 +48,7 @@ typedef struct virtio_scsi_config VirtIOSCSIConfig;
 struct VirtIOSCSIConf {
 uint32_t num_queues;
 uint32_t virtqueue_size;
+bool seg_max_adjust;
 uint32_t max_sectors;
 uint32_t cmd_per_lun;
 #ifdef CONFIG_VHOST_SCSI
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index b12157b5eb..9bee514c4e 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -913,7 +913,8 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
uint8_t *config)
 blk_get_geometry(s->blk, );
 memset(, 0, sizeof(blkcfg));
 virtio_stq_p(vdev, , capacity);
-virtio_stl_p(vdev, _max, 128 - 2);
+virtio_stl_p(vdev, _max,
+ s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 128 - 2);
 virtio_stw_p(vdev, , conf->cyls);
 virtio_stl_p(vdev, _size, blk_size);
 virtio_stw_p(vdev, _io_size, conf->min_io_size / blk_size);
@@ -1138,6 +1139,11 @@ static void virtio_blk_device_realize(DeviceState *dev, 
Error **errp)
 error_setg(errp, "num-queues property must be larger than 0");
 return;
 }
+if (conf->queue_size <= 2) {
+error_setg(errp, "invalid queue-size property (%" PRIu16 "), "
+   "must be > 2", conf->queue_size);
+return;
+}
 if (!is_power_of_2(conf->queue_size) ||
 conf->queue_size > VIRTQUEUE_MAX_SIZE) {
 error_setg(errp, "invalid queue-size property (%" PRIu16 "), "
@@ -1267,6 +1273,7 @@ static Property virtio_blk_properties[] = {
 true),
 DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues, 1),
 DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 128),
+DEFINE_PROP_BOOL("seg-max-adjust", VirtIOBlock, conf.seg_max_adjust, true),
 DEFINE_PROP_LINK("iothread", VirtIOBlock, conf.iothread, TYPE_IOTHREAD,
  IOThread *),
 DEFINE_PROP_BIT64("discard", VirtIOBlock, host_features,
diff --git a/hw/core/machine.c b/hw/core/machine.c
index f5e2b32b3b..ec2e3fcb61 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -29,6 +29,9 @@
 
 GlobalProperty hw_compat_4_2[] = {
 { "virtio-blk-device", "x-enable-wce-if-config-wce", "off" },
+{ "virtio-blk-device", "seg-max-adjust", "off"},
+{ "virtio-scsi-device", "seg_max_adjust", "off"},
+{ "vhost-blk-device", "seg_max_adjust", "off"},
 };
 const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
 
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index c693fc748a..26f710d3ec 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -275,6 +275,8 @@ static Property vhost_scsi_properties[] = {
 DEFINE_PROP_UINT32("num_queues", VirtIOSCSICommon, conf.num_queues, 1),
 

[PULL v3 09/32] Implement backend program convention command for vhost-user-blk

[Michael S. Tsirkin]

From: Micky Yun Chan 

This patch is to add standard commands defined in docs/interop/vhost-user.rst
For vhost-user-* program

Signed-off-by: Micky Yun Chan (michiboo) 
Message-Id: <20191209015331.5455-1-chanmicky...@gmail.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 docs/interop/vhost-user.json|  31 +++
 contrib/vhost-user-blk/vhost-user-blk.c | 108 ++--
 docs/interop/vhost-user.rst |  17 
 3 files changed, 112 insertions(+), 44 deletions(-)

diff --git a/docs/interop/vhost-user.json b/docs/interop/vhost-user.json
index da6aaf51c8..ce0ef74db5 100644
--- a/docs/interop/vhost-user.json
+++ b/docs/interop/vhost-user.json
@@ -54,6 +54,37 @@
   ]
 }
 
+##
+# @VHostUserBackendBlockFeature:
+#
+# List of vhost user "block" features.
+#
+# @read-only: The --read-only command line option is supported.
+# @blk-file: The --blk-file command line option is supported.
+#
+# Since: 5.0
+##
+{
+  'enum': 'VHostUserBackendBlockFeature',
+  'data': [ 'read-only', 'blk-file' ]
+}
+
+##
+# @VHostUserBackendCapabilitiesBlock:
+#
+# Capabilities reported by vhost user "block" backends
+#
+# @features: list of supported features.
+#
+# Since: 5.0
+##
+{
+  'struct': 'VHostUserBackendCapabilitiesBlock',
+  'data': {
+'features': [ 'VHostUserBackendBlockFeature' ]
+  }
+}
+
 ##
 # @VHostUserBackendInputFeature:
 #
diff --git a/contrib/vhost-user-blk/vhost-user-blk.c 
b/contrib/vhost-user-blk/vhost-user-blk.c
index ae61034656..6fd91c7e99 100644
--- a/contrib/vhost-user-blk/vhost-user-blk.c
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -576,70 +576,90 @@ vub_new(char *blk_file)
 return vdev_blk;
 }
 
+static int opt_fdnum = -1;
+static char *opt_socket_path;
+static char *opt_blk_file;
+static gboolean opt_print_caps;
+static gboolean opt_read_only;
+
+static GOptionEntry entries[] = {
+{ "print-capabilities", 'c', 0, G_OPTION_ARG_NONE, _print_caps,
+  "Print capabilities", NULL },
+{ "fd", 'f', 0, G_OPTION_ARG_INT, _fdnum,
+  "Use inherited fd socket", "FDNUM" },
+{ "socket-path", 's', 0, G_OPTION_ARG_FILENAME, _socket_path,
+  "Use UNIX socket path", "PATH" },
+{"blk-file", 'b', 0, G_OPTION_ARG_FILENAME, _blk_file,
+ "block device or file path", "PATH"},
+{ "read-only", 'r', 0, G_OPTION_ARG_NONE, _read_only,
+  "Enable read-only", NULL }
+};
+
 int main(int argc, char **argv)
 {
-int opt;
-char *unix_socket = NULL;
-char *blk_file = NULL;
-bool enable_ro = false;
 int lsock = -1, csock = -1;
 VubDev *vdev_blk = NULL;
+GError *error = NULL;
+GOptionContext *context;
 
-while ((opt = getopt(argc, argv, "b:rs:h")) != -1) {
-switch (opt) {
-case 'b':
-blk_file = g_strdup(optarg);
-break;
-case 's':
-unix_socket = g_strdup(optarg);
-break;
-case 'r':
-enable_ro = true;
-break;
-case 'h':
-default:
-printf("Usage: %s [ -b block device or file, -s UNIX domain socket"
-   " | -r Enable read-only ] | [ -h ]\n", argv[0]);
-return 0;
+context = g_option_context_new(NULL);
+g_option_context_add_main_entries(context, entries, NULL);
+if (!g_option_context_parse(context, , , )) {
+g_printerr("Option parsing failed: %s\n", error->message);
+exit(EXIT_FAILURE);
+}
+if (opt_print_caps) {
+g_print("{\n");
+g_print("  \"type\": \"block\",\n");
+g_print("  \"features\": [\n");
+g_print("\"read-only\",\n");
+g_print("\"blk-file\"\n");
+g_print("  ]\n");
+g_print("}\n");
+exit(EXIT_SUCCESS);
+}
+
+if (!opt_blk_file) {
+g_print("%s\n", g_option_context_get_help(context, true, NULL));
+exit(EXIT_FAILURE);
+}
+
+if (opt_socket_path) {
+lsock = unix_sock_new(opt_socket_path);
+if (lsock < 0) {
+exit(EXIT_FAILURE);
 }
+} else if (opt_fdnum < 0) {
+g_print("%s\n", g_option_context_get_help(context, true, NULL));
+exit(EXIT_FAILURE);
+} else {
+lsock = opt_fdnum;
 }
 
-if (!unix_socket || !blk_file) {
-printf("Usage: %s [ -b block device or file, -s UNIX domain socket"
-   " | -r Enable read-only ] | [ -h ]\n", argv[0]);
-return -1;
-}
-
-lsock = unix_sock_new(unix_socket);
-if (lsock < 0) {
-goto err;
-}
-
-csock = accept(lsock, (void *)0, (void *)0);
+csock = accept(lsock, NULL, NULL);
 if (csock < 0) {
-fprintf(stderr, "Accept error %s\n", strerror(errno));
-goto err;
+g_printerr("Accept error %s\n", strerror(errno));
+exit(EXIT_FAILURE);
 }
 
-vdev_blk = vub_new(blk_file);
+vdev_blk = vub_new(opt_blk_file);
 if (!vdev_blk) {
-goto err;
+exit(EXIT_FAILURE);
 }
-if (enable_ro) {
+

[PULL v3 14/32] hmat acpi: Build Memory Proximity Domain Attributes Structure(s)

[Michael S. Tsirkin]

From: Liu Jingqi 

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

It describes the memory attributes, such as memory side cache
attributes and bandwidth and latency details, related to the
Memory Proximity Domain. The software is
expected to use this information as hint for optimization.

This structure describes Memory Proximity Domain Attributes by memory
subsystem and its associativity with processor proximity domain as well as
hint for memory usage.

In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
the platform's HMAT tables.

Acked-by: Markus Armbruster 
Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-5-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/acpi/hmat.h| 42 ++
 hw/acpi/hmat.c| 99 +++
 hw/i386/acpi-build.c  |  5 +++
 hw/acpi/Kconfig   |  7 ++-
 hw/acpi/Makefile.objs |  1 +
 5 files changed, 152 insertions(+), 2 deletions(-)
 create mode 100644 hw/acpi/hmat.h
 create mode 100644 hw/acpi/hmat.c

diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
new file mode 100644
index 00..437dbc6872
--- /dev/null
+++ b/hw/acpi/hmat.h
@@ -0,0 +1,42 @@
+/*
+ * HMAT ACPI Implementation Header
+ *
+ * Copyright(C) 2019 Intel Corporation.
+ *
+ * Author:
+ *  Liu jingqi 
+ *  Tao Xu 
+ *
+ * HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
+ * (HMAT)
+ *
+ * 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 
+ */
+
+#ifndef HMAT_H
+#define HMAT_H
+
+#include "hw/acpi/aml-build.h"
+
+/*
+ * ACPI 6.3: 5.2.27.3 Memory Proximity Domain Attributes Structure,
+ * Table 5-145, Field "flag", Bit [0]: set to 1 to indicate that data in
+ * the Proximity Domain for the Attached Initiator field is valid.
+ * Other bits reserved.
+ */
+#define HMAT_PROXIMITY_INITIATOR_VALID  0x1
+
+void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state);
+
+#endif
diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
new file mode 100644
index 00..9ff79308a4
--- /dev/null
+++ b/hw/acpi/hmat.c
@@ -0,0 +1,99 @@
+/*
+ * HMAT ACPI Implementation
+ *
+ * Copyright(C) 2019 Intel Corporation.
+ *
+ * Author:
+ *  Liu jingqi 
+ *  Tao Xu 
+ *
+ * HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
+ * (HMAT)
+ *
+ * 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/acpi/hmat.h"
+
+/*
+ * ACPI 6.3:
+ * 5.2.27.3 Memory Proximity Domain Attributes Structure: Table 5-145
+ */
+static void build_hmat_mpda(GArray *table_data, uint16_t flags,
+uint32_t initiator, uint32_t mem_node)
+{
+
+/* Memory Proximity Domain Attributes 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);
+/* Proximity Domain for the Attached Initiator */
+build_append_int_noprefix(table_data, initiator, 4);
+/* Proximity Domain for the Memory */
+build_append_int_noprefix(table_data, mem_node, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+/*
+ * Reserved:
+ * Previously defined as the Start Address of the System Physical
+  

[PULL v3 18/32] tests/bios-tables-test: add test cases for ACPI HMAT

[Michael S. Tsirkin]

From: Tao Xu 

ACPI table HMAT has been introduced, QEMU now builds HMAT tables for
Heterogeneous Memory with boot option '-numa node'.

Add test cases on PC and Q35 machines with 2 numa nodes.
Because HMAT is generated when system enable numa, the
following tables need to be added for this test:
tests/data/acpi/pc/APIC.acpihmat
tests/data/acpi/pc/SRAT.acpihmat
tests/data/acpi/pc/HMAT.acpihmat
tests/data/acpi/pc/DSDT.acpihmat
tests/data/acpi/q35/APIC.acpihmat
tests/data/acpi/q35/SRAT.acpihmat
tests/data/acpi/q35/HMAT.acpihmat
tests/data/acpi/q35/DSDT.acpihmat

Acked-by: Markus Armbruster 
Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Reviewed-by: Jingqi Liu 
Suggested-by: Igor Mammedov 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-9-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 tests/bios-tables-test-allowed-diff.h |  8 +
 tests/bios-tables-test.c  | 44 +++
 tests/data/acpi/pc/APIC.acpihmat  |  0
 tests/data/acpi/pc/DSDT.acpihmat  |  0
 tests/data/acpi/pc/HMAT.acpihmat  |  0
 tests/data/acpi/pc/SRAT.acpihmat  |  0
 tests/data/acpi/q35/APIC.acpihmat |  0
 tests/data/acpi/q35/DSDT.acpihmat |  0
 tests/data/acpi/q35/HMAT.acpihmat |  0
 tests/data/acpi/q35/SRAT.acpihmat |  0
 10 files changed, 52 insertions(+)
 create mode 100644 tests/data/acpi/pc/APIC.acpihmat
 create mode 100644 tests/data/acpi/pc/DSDT.acpihmat
 create mode 100644 tests/data/acpi/pc/HMAT.acpihmat
 create mode 100644 tests/data/acpi/pc/SRAT.acpihmat
 create mode 100644 tests/data/acpi/q35/APIC.acpihmat
 create mode 100644 tests/data/acpi/q35/DSDT.acpihmat
 create mode 100644 tests/data/acpi/q35/HMAT.acpihmat
 create mode 100644 tests/data/acpi/q35/SRAT.acpihmat

diff --git a/tests/bios-tables-test-allowed-diff.h 
b/tests/bios-tables-test-allowed-diff.h
index dfb8523c8b..3c9e0c979b 100644
--- a/tests/bios-tables-test-allowed-diff.h
+++ b/tests/bios-tables-test-allowed-diff.h
@@ -1 +1,9 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/APIC.acpihmat",
+"tests/data/acpi/pc/SRAT.acpihmat",
+"tests/data/acpi/pc/HMAT.acpihmat",
+"tests/data/acpi/pc/DSDT.acpihmat",
+"tests/data/acpi/q35/APIC.acpihmat",
+"tests/data/acpi/q35/SRAT.acpihmat",
+"tests/data/acpi/q35/HMAT.acpihmat",
+"tests/data/acpi/q35/DSDT.acpihmat",
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index bc0ad594a1..f1ac2d7e96 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -947,6 +947,48 @@ static void test_acpi_virt_tcg_numamem(void)
 
 }
 
+static void test_acpi_tcg_acpi_hmat(const char *machine)
+{
+test_data data;
+
+memset(, 0, sizeof(data));
+data.machine = machine;
+data.variant = ".acpihmat";
+test_acpi_one(" -machine hmat=on"
+  " -smp 2,sockets=2"
+  " -m 128M,slots=2,maxmem=1G"
+  " -object memory-backend-ram,size=64M,id=m0"
+  " -object memory-backend-ram,size=64M,id=m1"
+  " -numa node,nodeid=0,memdev=m0"
+  " -numa node,nodeid=1,memdev=m1,initiator=0"
+  " -numa cpu,node-id=0,socket-id=0"
+  " -numa cpu,node-id=0,socket-id=1"
+  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+  "data-type=access-latency,latency=1"
+  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+  "data-type=access-bandwidth,bandwidth=65534M"
+  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
+  "data-type=access-latency,latency=65534"
+  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
+  "data-type=access-bandwidth,bandwidth=32767M"
+  " -numa hmat-cache,node-id=0,size=10K,level=1,"
+  "associativity=direct,policy=write-back,line=8"
+  " -numa hmat-cache,node-id=1,size=10K,level=1,"
+  "associativity=direct,policy=write-back,line=8",
+  );
+free_test_data();
+}
+
+static void test_acpi_q35_tcg_acpi_hmat(void)
+{
+test_acpi_tcg_acpi_hmat(MACHINE_Q35);
+}
+
+static void test_acpi_piix4_tcg_acpi_hmat(void)
+{
+test_acpi_tcg_acpi_hmat(MACHINE_PC);
+}
+
 static void test_acpi_virt_tcg(void)
 {
 test_data data = {
@@ -991,6 +1033,8 @@ int main(int argc, char *argv[])
 qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
 qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
 qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
+qtest_add_func("acpi/piix4/acpihmat", test_acpi_piix4_tcg_acpi_hmat);
+qtest_add_func("acpi/q35/acpihmat", test_acpi_q35_tcg_acpi_hmat);
 } else if (strcmp(arch, "aarch64") == 0) {
 qtest_add_func("acpi/virt", test_acpi_virt_tcg);
 

[PULL v3 21/32] hw/pci/pci_host: Remove redundant PCI_DPRINTF()

[Michael S. Tsirkin]

From: Philippe Mathieu-Daudé 

In commit 3bf4dfdd111 we introduced the pci_cfg_[read/write]
trace events in pci_host_config_[read/write]_common().
We have the following call trace:

  pci_host_data_[read/write]()
- PCI_DPRINTF()
- pci_data_[read/write]()
- PCI_DPRINTF()
- pci_host_config_[read/write]_common()
trace_pci_cfg_[read/write]()

Since the PCI_DPRINTF() calls are redundant with the trace
events, remove them.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191216002134.18279-2-phi...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci_host.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
index c5f9244934..0958d157de 100644
--- a/hw/pci/pci_host.c
+++ b/hw/pci/pci_host.c
@@ -115,8 +115,6 @@ void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, 
int len)
 return;
 }
 
-PCI_DPRINTF("%s: %s: addr=%02" PRIx32 " val=%08" PRIx32 " len=%d\n",
-__func__, pci_dev->name, config_addr, val, len);
 pci_host_config_write_common(pci_dev, config_addr, PCI_CONFIG_SPACE_SIZE,
  val, len);
 }
@@ -125,18 +123,13 @@ uint32_t pci_data_read(PCIBus *s, uint32_t addr, int len)
 {
 PCIDevice *pci_dev = pci_dev_find_by_addr(s, addr);
 uint32_t config_addr = addr & (PCI_CONFIG_SPACE_SIZE - 1);
-uint32_t val;
 
 if (!pci_dev) {
 return ~0x0;
 }
 
-val = pci_host_config_read_common(pci_dev, config_addr,
-  PCI_CONFIG_SPACE_SIZE, len);
-PCI_DPRINTF("%s: %s: addr=%02"PRIx32" val=%08"PRIx32" len=%d\n",
-__func__, pci_dev->name, config_addr, val, len);
-
-return val;
+return pci_host_config_read_common(pci_dev, config_addr,
+   PCI_CONFIG_SPACE_SIZE, len);
 }
 
 static void pci_host_config_write(void *opaque, hwaddr addr,
@@ -167,8 +160,7 @@ static void pci_host_data_write(void *opaque, hwaddr addr,
 uint64_t val, unsigned len)
 {
 PCIHostState *s = opaque;
-PCI_DPRINTF("write addr " TARGET_FMT_plx " len %d val %x\n",
-addr, len, (unsigned)val);
+
 if (s->config_reg & (1u << 31))
 pci_data_write(s->bus, s->config_reg | (addr & 3), val, len);
 }
@@ -177,14 +169,11 @@ static uint64_t pci_host_data_read(void *opaque,
hwaddr addr, unsigned len)
 {
 PCIHostState *s = opaque;
-uint32_t val;
+
 if (!(s->config_reg & (1U << 31))) {
 return 0x;
 }
-val = pci_data_read(s->bus, s->config_reg | (addr & 3), len);
-PCI_DPRINTF("read addr " TARGET_FMT_plx " len %d val %x\n",
-addr, len, val);
-return val;
+return pci_data_read(s->bus, s->config_reg | (addr & 3), len);
 }
 
 const MemoryRegionOps pci_host_conf_le_ops = {
-- 
MST

[PULL v3 15/32] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)

[Michael S. Tsirkin]

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.

Acked-by: Markus Armbruster 
Reviewed-by: Igor Mammedov 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-6-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/acpi/hmat.c | 104 -
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 9ff79308a4..4635d45dee 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -25,6 +25,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "sysemu/numa.h"
 #include "hw/acpi/hmat.h"
 
@@ -67,11 +68,89 @@ static void build_hmat_mpda(GArray *table_data, uint16_t 
flags,
 build_append_int_noprefix(table_data, 0, 8);
 }
 
+/*
+ * ACPI 6.3: 5.2.27.4 System Locality Latency and Bandwidth Information
+ * Structure: Table 5-146
+ */
+static void build_hmat_lb(GArray *table_data, HMAT_LB_Info *hmat_lb,
+  uint32_t num_initiator, uint32_t num_target,
+  uint32_t *initiator_list)
+{
+int i, index;
+HMAT_LB_Data *lb_data;
+uint16_t *entry_list;
+uint32_t base;
+/* Length in bytes for entire structure */
+uint32_t lb_length
+= 32 /* Table length upto and including Entry Base Unit */
++ 4 * num_initiator /* Initiator Proximity Domain List */
++ 4 * num_target /* Target Proximity Domain List */
++ 2 * num_initiator * num_target; /* Latency or Bandwidth Entries */
+
+/* Type */
+build_append_int_noprefix(table_data, 1, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, lb_length, 4);
+/* Flags: Bits [3:0] Memory Hierarchy, Bits[7:4] Reserved */
+assert(!(hmat_lb->hierarchy >> 4));
+build_append_int_noprefix(table_data, hmat_lb->hierarchy, 1);
+/* Data Type */
+build_append_int_noprefix(table_data, hmat_lb->data_type, 1);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Number of Initiator Proximity Domains (s) */
+build_append_int_noprefix(table_data, num_initiator, 4);
+/* Number of Target Proximity Domains (t) */
+build_append_int_noprefix(table_data, num_target, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+
+/* Entry Base Unit */
+if (hmat_lb->data_type <= HMAT_LB_DATA_WRITE_LATENCY) {
+/* Convert latency base from nanoseconds to picosecond */
+base = hmat_lb->base * 1000;
+} else {
+/* Convert bandwidth base from Byte to Megabyte */
+base = hmat_lb->base / MiB;
+}
+build_append_int_noprefix(table_data, base, 8);
+
+/* Initiator Proximity Domain List */
+for (i = 0; i < num_initiator; i++) {
+build_append_int_noprefix(table_data, initiator_list[i], 4);
+}
+
+/* Target Proximity Domain List */
+for (i = 0; i < num_target; i++) {
+build_append_int_noprefix(table_data, i, 4);
+}
+
+/* Latency or Bandwidth Entries */
+entry_list = g_malloc0(num_initiator * num_target * sizeof(uint16_t));
+for (i = 0; i < hmat_lb->list->len; i++) {
+lb_data = _array_index(hmat_lb->list, HMAT_LB_Data, i);
+index = lb_data->initiator * num_target + lb_data->target;
+
+entry_list[index] = (uint16_t)(lb_data->data / hmat_lb->base);
+}
+
+for (i = 0; i < num_initiator * num_target; i++) {
+build_append_int_noprefix(table_data, entry_list[i], 2);
+}
+
+g_free(entry_list);
+}
+
 /* Build HMAT sub table structures */
 static void hmat_build_table_structs(GArray *table_data, NumaState *numa_state)
 {
 uint16_t flags;
-int i;
+uint32_t num_initiator = 0;
+uint32_t initiator_list[MAX_NODES];
+int i, hierarchy, type;
+HMAT_LB_Info *hmat_lb;
 
 for (i = 0; i < numa_state->num_nodes; i++) {
 flags = 0;
@@ -82,6 +161,29 @@ static void hmat_build_table_structs(GArray *table_data, 
NumaState *numa_state)
 
 build_hmat_mpda(table_data, flags, numa_state->nodes[i].initiator, i);
 }
+
+for (i = 0; i < numa_state->num_nodes; i++) {
+if (numa_state->nodes[i].has_cpu) {
+initiator_list[num_initiator++] = i;
+}
+}
+
+/*
+ * ACPI 6.3: 5.2.27.4 System Locality Latency and Bandwidth Information
+ * Structure: Table 5-146
+ */
+for (hierarchy = HMAT_LB_MEM_MEMORY;
+ hierarchy <= HMAT_LB_MEM_CACHE_3RD_LEVEL; hierarchy++) {
+for (type = HMAT_LB_DATA_ACCESS_LATENCY;
+ type <= HMAT_LB_DATA_WRITE_BANDWIDTH; type++) {
+hmat_lb = 

[PULL v3 08/32] virtio-pci: disable vring processing when bus-mastering is disabled

[Michael S. Tsirkin]

From: Michael Roth 

Currently the SLOF firmware for pseries guests will disable/re-enable
a PCI device multiple times via IO/MEM/MASTER bits of PCI_COMMAND
register after the initial probe/feature negotiation, as it tends to
work with a single device at a time at various stages like probing
and running block/network bootloaders without doing a full reset
in-between.

In QEMU, when PCI_COMMAND_MASTER is disabled we disable the
corresponding IOMMU memory region, so DMA accesses (including to vring
fields like idx/flags) will no longer undergo the necessary
translation. Normally we wouldn't expect this to happen since it would
be misbehavior on the driver side to continue driving DMA requests.

However, in the case of pseries, with iommu_platform=on, we trigger the
following sequence when tearing down the virtio-blk dataplane ioeventfd
in response to the guest unsetting PCI_COMMAND_MASTER:

  #2  0x55922651 in virtqueue_map_desc (vdev=vdev@entry=0x56dbcfb0, 
p_num_sg=p_num_sg@entry=0x7fffe657e1a8, addr=addr@entry=0x7fffe657e240, 
iov=iov@entry=0x7fffe6580240, max_num_sg=max_num_sg@entry=1024, 
is_write=is_write@entry=false, pa=0, sz=0)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:757
  #3  0x55922a89 in virtqueue_pop (vq=vq@entry=0x56dc8660, 
sz=sz@entry=184)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:950
  #4  0x558d3eca in virtio_blk_get_request (vq=0x56dc8660, 
s=0x56dbcfb0)
  at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:255
  #5  0x558d3eca in virtio_blk_handle_vq (s=0x56dbcfb0, 
vq=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:776
  #6  0x5591dd66 in virtio_queue_notify_aio_vq 
(vq=vq@entry=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1550
  #7  0x5591ecef in virtio_queue_notify_aio_vq (vq=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1546
  #8  0x5591ecef in virtio_queue_host_notifier_aio_poll 
(opaque=0x56dc86c8)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:2527
  #9  0x55d02164 in run_poll_handlers_once 
(ctx=ctx@entry=0x5688bfc0, timeout=timeout@entry=0x7fffe65844a8)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:520
  #10 0x55d02d1b in try_poll_mode (timeout=0x7fffe65844a8, 
ctx=0x5688bfc0)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:607
  #11 0x55d02d1b in aio_poll (ctx=ctx@entry=0x5688bfc0, 
blocking=blocking@entry=true)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:639
  #12 0x55d0004d in aio_wait_bh_oneshot (ctx=0x5688bfc0, 
cb=cb@entry=0x558d5130 , 
opaque=opaque@entry=0x56de86f0)
  at /home/mdroth/w/qemu.git/util/aio-wait.c:71
  #13 0x558d59bf in virtio_blk_data_plane_stop (vdev=)
  at /home/mdroth/w/qemu.git/hw/block/dataplane/virtio-blk.c:288
  #14 0x55b906a1 in virtio_bus_stop_ioeventfd 
(bus=bus@entry=0x56dbcf38)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:245
  #15 0x55b90dbb in virtio_bus_stop_ioeventfd 
(bus=bus@entry=0x56dbcf38)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:237
  #16 0x55b92a8e in virtio_pci_stop_ioeventfd (proxy=0x56db4e40)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:292
  #17 0x55b92a8e in virtio_write_config (pci_dev=0x56db4e40, 
address=, val=1048832, len=)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:613

I.e. the calling code is only scheduling a one-shot BH for
virtio_blk_data_plane_stop_bh, but somehow we end up trying to process
an additional virtqueue entry before we get there. This is likely due
to the following check in virtio_queue_host_notifier_aio_poll:

  static bool virtio_queue_host_notifier_aio_poll(void *opaque)
  {
  EventNotifier *n = opaque;
  VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
  bool progress;

  if (!vq->vring.desc || virtio_queue_empty(vq)) {
  return false;
  }

  progress = virtio_queue_notify_aio_vq(vq);

namely the call to virtio_queue_empty(). In this case, since no new
requests have actually been issued, shadow_avail_idx == last_avail_idx,
so we actually try to access the vring via vring_avail_idx() to get
the latest non-shadowed idx:

  int virtio_queue_empty(VirtQueue *vq)
  {
  bool empty;
  ...

  if (vq->shadow_avail_idx != vq->last_avail_idx) {
  return 0;
  }

  rcu_read_lock();
  empty = vring_avail_idx(vq) == vq->last_avail_idx;
  rcu_read_unlock();
  return empty;

but since the IOMMU region has been disabled we get a bogus value (0
usually), which causes virtio_queue_empty() to falsely report that
there are entries to be processed, which causes errors such as:

  "virtio: zero sized buffers are not allowed"

or

  "virtio-blk missing headers"

and puts the device in an error state.

This patch works around the issue by introducing virtio_set_disabled(),
which sets a 'disabled' 

[PULL v3 12/32] numa: Extend CLI to provide memory latency and bandwidth information

[Michael S. Tsirkin]

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). Before using
hmat-lb option, enable HMAT with -machine hmat=on.

Acked-by: Markus Armbruster 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
Message-Id: <20191213011929.2520-3-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Igor Mammedov 
---
 qapi/machine.json |  93 +++-
 include/sysemu/numa.h |  53 
 hw/core/numa.c| 194 ++
 qemu-options.hx   |  47 +-
 4 files changed, 384 insertions(+), 3 deletions(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index 27d0e37534..cf8faf5a2a 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -426,10 +426,12 @@
 #
 # @cpu: property based CPU(s) to node mapping (Since: 2.10)
 #
+# @hmat-lb: memory latency and bandwidth information (Since: 5.0)
+#
 # Since: 2.1
 ##
 { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu' ] }
+  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
 
 ##
 # @NumaOptions:
@@ -444,7 +446,8 @@
   'data': {
 'node': 'NumaNodeOptions',
 'dist': 'NumaDistOptions',
-'cpu': 'NumaCpuOptions' }}
+'cpu': 'NumaCpuOptions',
+'hmat-lb': 'NumaHmatLBOptions' }}
 
 ##
 # @NumaNodeOptions:
@@ -557,6 +560,92 @@
'base': 'CpuInstanceProperties',
'data' : {} }
 
+##
+# @HmatLBMemoryHierarchy:
+#
+# The memory hierarchy in the System Locality Latency and Bandwidth
+# Information Structure of HMAT (Heterogeneous Memory Attribute Table)
+#
+# For more information about @HmatLBMemoryHierarchy, see chapter
+# 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec.
+#
+# @memory: the structure represents the memory performance
+#
+# @first-level: first level of memory side cache
+#
+# @second-level: second level of memory side cache
+#
+# @third-level: third level of memory side cache
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatLBMemoryHierarchy',
+  'data': [ 'memory', 'first-level', 'second-level', 'third-level' ] }
+
+##
+# @HmatLBDataType:
+#
+# Data type in the System Locality Latency and Bandwidth
+# Information Structure of HMAT (Heterogeneous Memory Attribute Table)
+#
+# For more information about @HmatLBDataType, see chapter
+# 5.2.27.4: Table 5-146:  Field "Data Type" of ACPI 6.3 spec.
+#
+# @access-latency: access latency (nanoseconds)
+#
+# @read-latency: read latency (nanoseconds)
+#
+# @write-latency: write latency (nanoseconds)
+#
+# @access-bandwidth: access bandwidth (Bytes per second)
+#
+# @read-bandwidth: read bandwidth (Bytes per second)
+#
+# @write-bandwidth: write bandwidth (Bytes per second)
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatLBDataType',
+  'data': [ 'access-latency', 'read-latency', 'write-latency',
+'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
+
+##
+# @NumaHmatLBOptions:
+#
+# Set the system locality latency and bandwidth information
+# between Initiator and Target proximity Domains.
+#
+# For more information about @NumaHmatLBOptions, see chapter
+# 5.2.27.4: Table 5-146 of ACPI 6.3 spec.
+#
+# @initiator: the Initiator Proximity Domain.
+#
+# @target: the Target Proximity Domain.
+#
+# @hierarchy: the Memory Hierarchy. Indicates the performance
+# of memory or side cache.
+#
+# @data-type: presents the type of data, access/read/write
+# latency or hit latency.
+#
+# @latency: the value of latency from @initiator to @target
+#   proximity domain, the latency unit is "ns(nanosecond)".
+#
+# @bandwidth: the value of bandwidth between @initiator and @target
+# proximity domain, the bandwidth unit is
+# "Bytes per second".
+#
+# Since: 5.0
+##
+{ 'struct': 'NumaHmatLBOptions',
+'data': {
+'initiator': 'uint16',
+'target': 'uint16',
+'hierarchy': 'HmatLBMemoryHierarchy',
+'data-type': 'HmatLBDataType',
+'*latency': 'uint64',
+'*bandwidth': 'size' }}
+
 ##
 # @HostMemPolicy:
 #
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 788cbec7a2..70f93c83d7 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -14,11 +14,34 @@ struct CPUArchId;
 #define NUMA_DISTANCE_MAX 254
 #define NUMA_DISTANCE_UNREACHABLE 255
 
+/* the value of AcpiHmatLBInfo flags */
+enum {
+HMAT_LB_MEM_MEMORY   = 0,
+HMAT_LB_MEM_CACHE_1ST_LEVEL  = 1,
+HMAT_LB_MEM_CACHE_2ND_LEVEL  = 2,
+HMAT_LB_MEM_CACHE_3RD_LEVEL  = 3,
+HMAT_LB_LEVELS   /* must be the last entry */
+};
+
+/* the value of AcpiHmatLBInfo data type */
+enum {
+HMAT_LB_DATA_ACCESS_LATENCY   = 0,
+HMAT_LB_DATA_READ_LATENCY = 1,
+HMAT_LB_DATA_WRITE_LATENCY= 2,
+HMAT_LB_DATA_ACCESS_BANDWIDTH = 3,
+HMAT_LB_DATA_READ_BANDWIDTH   = 4,
+HMAT_LB_DATA_WRITE_BANDWIDTH  = 5,
+

[PULL v3 20/32] virtio-mmio: Clear v2 transport state on soft reset

[Michael S. Tsirkin]

From: Jean-Philippe Brucker 

At the moment when the guest writes a status of 0, we only reset the
virtio core state but not the virtio-mmio state. The virtio-mmio
specification says (v1.1 cs01, 4.2.2.1 Device Requirements:
MMIO Device Register Layout):

Upon reset, the device MUST clear all bits in InterruptStatus and
ready bits in the QueueReady register for all queues in the device.

The core already takes care of InterruptStatus by clearing isr, but we
still need to clear QueueReady.

It would be tempting to clean all registers, but since the specification
doesn't say anything more, guests could rely on the registers keeping
their state across reset. Linux for example, relies on this for
GuestPageSize in the legacy MMIO tranport.

Fixes: 44e687a4d9ab ("virtio-mmio: implement modern (v2) personality 
(virtio-1)")
Signed-off-by: Jean-Philippe Brucker 
Message-Id: <20191213095410.1516119-1-jean-phili...@linaro.org>
Reviewed-by: Sergio Lopez 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio-mmio.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index 94d934c44b..ef40b7a9b2 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -65,6 +65,19 @@ static void virtio_mmio_stop_ioeventfd(VirtIOMMIOProxy 
*proxy)
 virtio_bus_stop_ioeventfd(>bus);
 }
 
+static void virtio_mmio_soft_reset(VirtIOMMIOProxy *proxy)
+{
+int i;
+
+if (proxy->legacy) {
+return;
+}
+
+for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
+proxy->vqs[i].enabled = 0;
+}
+}
+
 static uint64_t virtio_mmio_read(void *opaque, hwaddr offset, unsigned size)
 {
 VirtIOMMIOProxy *proxy = (VirtIOMMIOProxy *)opaque;
@@ -378,6 +391,7 @@ static void virtio_mmio_write(void *opaque, hwaddr offset, 
uint64_t value,
 
 if (vdev->status == 0) {
 virtio_reset(vdev);
+virtio_mmio_soft_reset(proxy);
 }
 break;
 case VIRTIO_MMIO_QUEUE_DESC_LOW:
-- 
MST

[PULL v3 06/32] intel_iommu: fix bug to read DMAR_RTADDR_REG

[Michael S. Tsirkin]

From: Yi Sun 

Should directly read DMAR_RTADDR_REG but not using 's->root'.
Because 's->root' is modified in 'vtd_root_table_setup()' so
that the first 12 bits are omitted. This causes the guest
iommu debugfs cannot show pasid tables.

Signed-off-by: Yi Sun 
Message-Id: <20191205095439.29114-1-yi.y@linux.intel.com>
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Peter Xu 
Reviewed-by: Michael S. Tsirkin 
---
 hw/i386/intel_iommu.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 43c94b993b..ee06993675 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2610,16 +2610,15 @@ static uint64_t vtd_mem_read(void *opaque, hwaddr addr, 
unsigned size)
 switch (addr) {
 /* Root Table Address Register, 64-bit */
 case DMAR_RTADDR_REG:
+val = vtd_get_quad_raw(s, DMAR_RTADDR_REG);
 if (size == 4) {
-val = s->root & ((1ULL << 32) - 1);
-} else {
-val = s->root;
+val = val & ((1ULL << 32) - 1);
 }
 break;
 
 case DMAR_RTADDR_REG_HI:
 assert(size == 4);
-val = s->root >> 32;
+val = vtd_get_quad_raw(s, DMAR_RTADDR_REG) >> 32;
 break;
 
 /* Invalidation Queue Address Register, 64-bit */
-- 
MST

[PULL v3 05/32] virtio-input: convert to new virtio_delete_queue

[Michael S. Tsirkin]

Seems cleaner than using VQ index values.

Signed-off-by: Michael S. Tsirkin 
---
 hw/input/virtio-input.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/input/virtio-input.c b/hw/input/virtio-input.c
index ec54e46ad6..9c013afddb 100644
--- a/hw/input/virtio-input.c
+++ b/hw/input/virtio-input.c
@@ -280,6 +280,7 @@ static void virtio_input_device_unrealize(DeviceState *dev, 
Error **errp)
 {
 VirtIOInputClass *vic = VIRTIO_INPUT_GET_CLASS(dev);
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+VirtIOInput *vinput = VIRTIO_INPUT(dev);
 Error *local_err = NULL;
 
 if (vic->unrealize) {
@@ -289,8 +290,8 @@ static void virtio_input_device_unrealize(DeviceState *dev, 
Error **errp)
 return;
 }
 }
-virtio_del_queue(vdev, 0);
-virtio_del_queue(vdev, 1);
+virtio_delete_queue(vinput->evt);
+virtio_delete_queue(vinput->sts);
 virtio_cleanup(vdev);
 }
 
-- 
MST

[PULL v3 03/32] virtio-balloon: fix memory leak while attach virtio-balloon device

[Michael S. Tsirkin]

From: Pan Nengyuan 

ivq/dvq/svq/free_page_vq is forgot to cleanup in
virtio_balloon_device_unrealize, the memory leak stack is as follow:

Direct leak of 14336 byte(s) in 2 object(s) allocated from:
#0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f99fcb20015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x557d90638437 in virtio_add_queue hw/virtio/virtio.c:2327
#3 0x557d9064401d in virtio_balloon_device_realize 
hw/virtio/virtio-balloon.c:793
#4 0x557d906356f7 in virtio_device_realize hw/virtio/virtio.c:3504
#5 0x557d9073f081 in device_set_realized hw/core/qdev.c:876
#6 0x557d908b1f4d in property_set_bool qom/object.c:2080
#7 0x557d908b655e in object_property_set_qobject qom/qom-qobject.c:26

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
Message-Id: <1575444716-17632-2-git-send-email-pannengy...@huawei.com>
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: David Hildenbrand 
Reviewed-by: Michael S. Tsirkin 
Reviewed-by: David Hildenbrand 
---
 hw/virtio/virtio-balloon.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 40b04f5180..57f3b9f22d 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -831,6 +831,13 @@ static void virtio_balloon_device_unrealize(DeviceState 
*dev, Error **errp)
 }
 balloon_stats_destroy_timer(s);
 qemu_remove_balloon_handler(s);
+
+virtio_delete_queue(s->ivq);
+virtio_delete_queue(s->dvq);
+virtio_delete_queue(s->svq);
+if (s->free_page_vq) {
+virtio_delete_queue(s->free_page_vq);
+}
 virtio_cleanup(vdev);
 }
 
-- 
MST

[PULL v3 07/32] virtio: update queue size on guest write

[Michael S. Tsirkin]

Some guests read back queue size after writing it.
Update the size immediatly upon write otherwise
they get confused.

In particular this is the case for seabios.

Reported-by: Roman Kagan 
Suggested-by: Denis Plotnikov 
Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index c6b47a9c73..e5c759e19e 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1256,6 +1256,8 @@ static void virtio_pci_common_write(void *opaque, hwaddr 
addr,
 break;
 case VIRTIO_PCI_COMMON_Q_SIZE:
 proxy->vqs[vdev->queue_sel].num = val;
+virtio_queue_set_num(vdev, vdev->queue_sel,
+ proxy->vqs[vdev->queue_sel].num);
 break;
 case VIRTIO_PCI_COMMON_Q_MSIX:
 msix_vector_unuse(>pci_dev,
-- 
MST

[PULL v3 02/32] virtio: make virtio_delete_queue idempotent

[Michael S. Tsirkin]

Let's make sure calling this twice is harmless -
no known instances, but seems safer.

Suggested-by: Pan Nengyuan 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 31dd140990..6de3cfdc2c 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2337,6 +2337,7 @@ void virtio_delete_queue(VirtQueue *vq)
 vq->handle_output = NULL;
 vq->handle_aio_output = NULL;
 g_free(vq->used_elems);
+vq->used_elems = NULL;
 }
 
 void virtio_del_queue(VirtIODevice *vdev, int n)
-- 
MST

[PULL v3 00/32] virtio, pci, pc: fixes, features

[Michael S. Tsirkin]

Changes from v2:
- rebased on master
- a couple more bugfixes

The following changes since commit f0dcfddecee8b860e015bb07d67cfcbdfbfd51d9:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2020-01-03 17:18:08 +)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to 93ef96f3258f489f7bff28ca7b9e0dc74de2a75b:

  intel_iommu: add present bit check for pasid table entries (2020-01-05 
07:41:10 -0500)


virtio, pci, pc: fixes, features

Bugfixes all over the place.
HMAT support.
New flags for vhost-user-blk utility.
Auto-tuning of seg max for virtio storage.

Signed-off-by: Michael S. Tsirkin 


Denis Plotnikov (4):
  hw: fix using 4.2 compat in 5.0 machine types for i440fx/q35
  virtio: make seg_max virtqueue size dependent
  tests: add virtio-scsi and virtio-blk seg_max_adjust test
  virtio-mmio: update queue size on guest write

Jean-Philippe Brucker (1):
  virtio-mmio: Clear v2 transport state on soft reset

Liu Jingqi (5):
  numa: Extend CLI to provide memory latency and bandwidth information
  numa: Extend CLI to provide memory side cache information
  hmat acpi: Build Memory Proximity Domain Attributes Structure(s)
  hmat acpi: Build System Locality Latency and Bandwidth Information 
Structure(s)
  hmat acpi: Build Memory Side Cache Information Structure(s)

Liu Yi L (2):
  intel_iommu: a fix to vtd_find_as_from_bus_num()
  intel_iommu: add present bit check for pasid table entries

Michael Roth (1):
  virtio-pci: disable vring processing when bus-mastering is disabled

Michael S. Tsirkin (5):
  virtio: add ability to delete vq through a pointer
  virtio: make virtio_delete_queue idempotent
  virtio-input: convert to new virtio_delete_queue
  virtio: update queue size on guest write
  ACPI: add expected files for HMAT tests (acpihmat)

Micky Yun Chan (1):
  Implement backend program convention command for vhost-user-blk

Pan Nengyuan (2):
  virtio-balloon: fix memory leak while attach virtio-balloon device
  virtio-serial-bus: fix memory leak while attach virtio-serial-bus

Philippe Mathieu-Daudé (2):
  hw/pci/pci_host: Remove redundant PCI_DPRINTF()
  hw/pci/pci_host: Let pci_data_[read/write] use unsigned 'size' argument

Raphael Norwitz (2):
  vhost-user: add VHOST_USER_RESET_DEVICE to reset devices
  vhost-user-scsi: reset the device if supported

Stefan Hajnoczi (1):
  virtio: don't enable notifications during polling

Tao Xu (3):
  numa: Extend CLI to provide initiator information for numa nodes
  tests/numa: Add case for QMP build HMAT
  tests/bios-tables-test: add test cases for ACPI HMAT

Yi Sun (1):
  intel_iommu: fix bug to read DMAR_RTADDR_REG

Yuri Benditovich (2):
  virtio: reset region cache when on queue deletion
  virtio-net: delete also control queue when TX/RX deleted

 docs/interop/vhost-user.json  |  31 
 qapi/machine.json | 180 +-
 hw/acpi/hmat.h|  42 +
 hw/i386/intel_iommu_internal.h|   1 +
 include/hw/pci/pci_host.h |   4 +-
 include/hw/virtio/virtio-blk.h|   1 +
 include/hw/virtio/virtio-scsi.h   |   1 +
 include/hw/virtio/virtio.h|  18 ++
 include/sysemu/numa.h |  63 +++
 contrib/vhost-user-blk/vhost-user-blk.c   | 108 ++-
 hw/acpi/hmat.c| 268 +++
 hw/block/virtio-blk.c |  18 +-
 hw/char/virtio-serial-bus.c   |   8 +
 hw/core/machine.c |  68 +++
 hw/core/numa.c| 297 ++
 hw/i386/acpi-build.c  |   5 +
 hw/i386/intel_iommu.c | 100 +++---
 hw/i386/pc_piix.c |   1 -
 hw/i386/pc_q35.c  |   1 -
 hw/input/virtio-input.c   |   5 +-
 hw/net/virtio-net.c   |   3 +-
 hw/pci/pci_host.c |  25 +--
 hw/scsi/vhost-scsi.c  |   2 +
 hw/scsi/vhost-user-scsi.c |  24 +++
 hw/scsi/virtio-scsi.c |  19 +-
 hw/virtio/vhost-user.c|   8 +-
 hw/virtio/virtio-balloon.c|   7 +
 hw/virtio/virtio-mmio.c   |  17 +-
 hw/virtio/virtio-pci.c|  14 +-
 hw/virtio/virtio.c|  64 +--
 tests/bios-tables-test.c  |  44 +
 tests/numa-test.c | 213 +
 docs/interop/vhost-user.rst   |  32 
 hw/acpi/Kconfig  

[PULL v3 04/32] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

[Michael S. Tsirkin]

From: Pan Nengyuan 

ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in
virtio_serial_device_unrealize, the memory leak stack is as bellow:

Direct leak of 1290240 byte(s) in 180 object(s) allocated from:
#0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7fc9bed6f015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x5650e02b83e7 in virtio_add_queue hw/virtio/virtio.c:2327
#3 0x5650e02847b5 in virtio_serial_device_realize 
hw/char/virtio-serial-bus.c:1089
#4 0x5650e02b56a7 in virtio_device_realize hw/virtio/virtio.c:3504
#5 0x5650e03bf031 in device_set_realized hw/core/qdev.c:876
#6 0x5650e0531efd in property_set_bool qom/object.c:2080
#7 0x5650e053650e in object_property_set_qobject qom/qom-qobject.c:26
#8 0x5650e0533e14 in object_property_set_bool qom/object.c:1338
#9 0x5650e04c0e37 in virtio_pci_realize hw/virtio/virtio-pci.c:1801

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
Cc: Laurent Vivier 
Cc: Amit Shah 
Cc: "Marc-André Lureau" 
Cc: Paolo Bonzini 
Message-Id: <1575444716-17632-3-git-send-email-pannengy...@huawei.com>
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Michael S. Tsirkin 
---
 hw/char/virtio-serial-bus.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 33259042a9..e1cbce3ba3 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -1126,9 +1126,17 @@ static void virtio_serial_device_unrealize(DeviceState 
*dev, Error **errp)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
 VirtIOSerial *vser = VIRTIO_SERIAL(dev);
+int i;
 
 QLIST_REMOVE(vser, next);
 
+virtio_delete_queue(vser->c_ivq);
+virtio_delete_queue(vser->c_ovq);
+for (i = 0; i < vser->bus.max_nr_ports; i++) {
+virtio_delete_queue(vser->ivqs[i]);
+virtio_delete_queue(vser->ovqs[i]);
+}
+
 g_free(vser->ivqs);
 g_free(vser->ovqs);
 g_free(vser->ports_map);
-- 
MST

[PULL v3 01/32] virtio: add ability to delete vq through a pointer

[Michael S. Tsirkin]

Devices tend to maintain vq pointers, allow deleting them trough a vq pointer.

Signed-off-by: Michael S. Tsirkin 
Reviewed-by: David Hildenbrand 
Reviewed-by: David Hildenbrand 
---
 include/hw/virtio/virtio.h |  2 ++
 hw/virtio/virtio.c | 15 ++-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index c32a815303..e18756d50d 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -183,6 +183,8 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int 
queue_size,
 
 void virtio_del_queue(VirtIODevice *vdev, int n);
 
+void virtio_delete_queue(VirtQueue *vq);
+
 void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
 unsigned int len);
 void virtqueue_flush(VirtQueue *vq, unsigned int count);
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 04716b5f6c..31dd140990 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2330,17 +2330,22 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int 
queue_size,
 return >vq[i];
 }
 
+void virtio_delete_queue(VirtQueue *vq)
+{
+vq->vring.num = 0;
+vq->vring.num_default = 0;
+vq->handle_output = NULL;
+vq->handle_aio_output = NULL;
+g_free(vq->used_elems);
+}
+
 void virtio_del_queue(VirtIODevice *vdev, int n)
 {
 if (n < 0 || n >= VIRTIO_QUEUE_MAX) {
 abort();
 }
 
-vdev->vq[n].vring.num = 0;
-vdev->vq[n].vring.num_default = 0;
-vdev->vq[n].handle_output = NULL;
-vdev->vq[n].handle_aio_output = NULL;
-g_free(vdev->vq[n].used_elems);
+virtio_delete_queue(>vq[n]);
 }
 
 static void virtio_set_isr(VirtIODevice *vdev, int value)
-- 
MST

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Michael S. Tsirkin]

On Sun, Jan 05, 2020 at 07:34:01AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:
> > According to ACPI spec, _ADR should be used for device which is on a
> > bus that has a standard enumeration algorithm. It does not make sense
> > to have a _ADR object for devices which already have _HID and will be
> > enumerated by OSPM.
> > 
> > Signed-off-by: Heyi Guo 
> 
> Are you sure? I would think this depends on the ID and the device
> really. E.g. PCI devices all are expected to have _ADR and some of them
> have a _HID.


To clarify I am not commenting on patches.
The spec says this:
6.1.5 _HID (Hardware ID)

This object is used to supply OSPM with the device’s PNP ID or ACPI ID. 
1

When describing a platform, use of any _HID objects is optional. 
However, a _HID object must be

used to describe any device that will be enumerated by OSPM. OSPM only 
enumerates a device

when no bus enumerator can detect the device ID. For example, devices 
on an ISA bus are

enumerated by OSPM. Use the _ADR object to describe devices enumerated 
by bus enumerators

other than OSPM.


Note: "detect the device ID" not "enumerate the device" which I think
means there's a driver matching this vendor/device ID.

So it seems fine to have _ADR so device is enumerated, and still have
_HID e.g. so ACPI driver can be loaded as fallback if there's
no bus driver.


Note I am not saying the patch itself is not correct.
Maybe these devices are not on any standard bus and that
is why they should not have _ADR? I have not looked.

I am just saying that spec does not seem to imply _HID and _ADR
can't coexist.


> CC Corey who added a device with both HID and ADR to x86 recenly.
> 
> Apropos Corey, why was HID APP0005 chosen?
> 
> > ---
> > Cc: Shannon Zhao 
> > Cc: Peter Maydell 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Igor Mammedov 
> > Cc: qemu-...@nongnu.org
> > Cc: qemu-devel@nongnu.org
> > ---
> >  hw/arm/virt-acpi-build.c  |   8 
> >  tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
> >  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
> >  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
> >  4 files changed, 8 deletions(-)
> > 
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 9f4c7d1889..be752c0ad8 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const 
> > MemMapEntry *uart_memmap,
> >   AML_EXCLUSIVE, _irq, 1));
> >  aml_append(dev, aml_name_decl("_CRS", crs));
> >  
> > -/* The _ADR entry is used to link this device to the UART described
> > - * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
> > - */
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
> > -
> >  aml_append(scope, dev);
> >  }
> >  
> > @@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
> > MemMapEntry *memmap,
> >  aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
> >  aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
> >  aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
> >  aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> > @@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const 
> > MemMapEntry *gpio_memmap,
> >  {
> >  Aml *dev = aml_device("GPO0");
> >  aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >  
> >  Aml *crs = aml_resource_template();
> > @@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
> >  {
> >  Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
> >  aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
> > -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >  aml_append(scope, dev);
> >  }
> > diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT
> 
> 
> Please do not include binary changes in acpi patches.
> 
> See comment at the top of tests/bios-tables-test.c for documentation
> on how to update these.
> 
> -- 
> MST

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Michael S. Tsirkin]

On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:
> According to ACPI spec, _ADR should be used for device which is on a
> bus that has a standard enumeration algorithm. It does not make sense
> to have a _ADR object for devices which already have _HID and will be
> enumerated by OSPM.
> 
> Signed-off-by: Heyi Guo 

Are you sure? I would think this depends on the ID and the device
really. E.g. PCI devices all are expected to have _ADR and some of them
have a _HID.

CC Corey who added a device with both HID and ADR to x86 recenly.

Apropos Corey, why was HID APP0005 chosen?

> ---
> Cc: Shannon Zhao 
> Cc: Peter Maydell 
> Cc: "Michael S. Tsirkin" 
> Cc: Igor Mammedov 
> Cc: qemu-...@nongnu.org
> Cc: qemu-devel@nongnu.org
> ---
>  hw/arm/virt-acpi-build.c  |   8 
>  tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
>  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
>  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
>  4 files changed, 8 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 9f4c7d1889..be752c0ad8 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const 
> MemMapEntry *uart_memmap,
>   AML_EXCLUSIVE, _irq, 1));
>  aml_append(dev, aml_name_decl("_CRS", crs));
>  
> -/* The _ADR entry is used to link this device to the UART described
> - * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
> - */
> -aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
> -
>  aml_append(scope, dev);
>  }
>  
> @@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
> MemMapEntry *memmap,
>  aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
>  aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
>  aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
> -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
>  aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
>  aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
>  aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> @@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const 
> MemMapEntry *gpio_memmap,
>  {
>  Aml *dev = aml_device("GPO0");
>  aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
> -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
>  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>  
>  Aml *crs = aml_resource_template();
> @@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
>  {
>  Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
>  aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
> -aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
>  aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>  aml_append(scope, dev);
>  }
> diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT


Please do not include binary changes in acpi patches.

See comment at the top of tests/bios-tables-test.c for documentation
on how to update these.

-- 
MST

Re: [PATCH 1/2] virtio: reset region cache when on queue deletion

[Michael S. Tsirkin]

On Thu, Dec 26, 2019 at 06:36:48AM +0200, Yuri Benditovich wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1708480
> Fix leak of region reference that prevents complete
> device deletion on hot unplug.
> 
> Signed-off-by: Yuri Benditovich 

I rebased this on top of my tree.

Got this:


commit f3dee6a062c1f4445768296ee39070bab9863372
Author: Yuri Benditovich 
Date:   Thu Dec 26 06:36:48 2019 +0200

virtio: reset region cache when on queue deletion

https://bugzilla.redhat.com/show_bug.cgi?id=1708480
Fix leak of region reference that prevents complete
device deletion on hot unplug.

Signed-off-by: Yuri Benditovich 
Message-Id: <20191226043649.14481-2-yuri.benditov...@daynix.com>

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 95d8ff8508..7b861e0ca0 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2344,6 +2344,7 @@ void virtio_delete_queue(VirtQueue *vq)
 vq->handle_aio_output = NULL;
 g_free(vq->used_elems);
 vq->used_elems = NULL;
+virtio_virtqueue_reset_region_cache(vq);
 }
 
 void virtio_del_queue(VirtIODevice *vdev, int n)

Can you confirm pls?

Re: [PATCH 1/2] virtio: reset region cache when on queue deletion

[Michael S. Tsirkin]

On Thu, Jan 02, 2020 at 09:09:04AM +0200, Yuri Benditovich wrote:
> 
> 
> On Thu, Jan 2, 2020 at 1:50 AM Michael S. Tsirkin  wrote:
> 
> On Thu, Dec 26, 2019 at 11:29:50AM +0200, Yuri Benditovich wrote:
> > On Thu, Dec 26, 2019 at 10:58 AM Jason Wang  wrote:
> > >
> > >
> > > On 2019/12/26 下午12:36, Yuri Benditovich wrote:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1708480
> > > > Fix leak of region reference that prevents complete
> > > > device deletion on hot unplug.
> > >
> > >
> > > More information is needed here, the bug said only q35 can meet this
> > > issue. What makes q35 different here?
> > >
> >
> > I do not have any ready answer, I did not dig into it too much.
> > Probably Michael Tsirkin or Paolo Bonzini can answer without digging.
> 
> 
> 
> > >
> > > >
> > > > Signed-off-by: Yuri Benditovich 
> > > > ---
> > > >   hw/virtio/virtio.c | 5 +
> > > >   1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > index 04716b5f6c..baadec8abc 100644
> > > > --- a/hw/virtio/virtio.c
> > > > +++ b/hw/virtio/virtio.c
> > > > @@ -2340,6 +2340,11 @@ void virtio_del_queue(VirtIODevice *vdev, int
> n)
> > > >       vdev->vq[n].vring.num_default = 0;
> > > >       vdev->vq[n].handle_output = NULL;
> > > >       vdev->vq[n].handle_aio_output = NULL;
> > > > +    /*
> > > > +     * with vring.num = 0 the queue will be ignored
> > > > +     * in later loops of region cache reset
> > > > +     */
> > >
> > >
> > > I can't get the meaning of this comment.
> > >
> > > Thanks
> > >
> > >
> > > > +    virtio_virtqueue_reset_region_cache(>vq[n]);
> 
> 
> Do we need to drop this from virtio_device_free_virtqueues then?
> 
> 
> 
> Not mandatory. Repetitive  virtio_virtqueue_reset_region_cache does not do
> anything bad.
> Some of virtio devices do not do 'virtio_del_queue' at all. Currently 
> virtio_device_free_virtqueues resets region cache for them.
> IMO, not calling 'virtio_del_queue' is a bug, but not in the scope of current
> series, I'll take care of that later.

Maybe we should just del all queues in virtio_device_unrealize?
Will allow us to drop some logic tracking which vqs were created.


> 
> > > >       g_free(vdev->vq[n].used_elems);
> > > >   }
> > > >
> > >
> 
> 

Re: [Qemu-devel] What should a virtual board emulate?

[BALATON Zoltan]

On Sat, 4 Jan 2020, Philippe Mathieu-Daudé wrote:
I insist this patch is incorrect for the particular case of the Fuloong2e 
board. I plan to revert it when I post the test.


I can only repeat my comment from when it last came up:

On Wed, 20 Mar 2019, BALATON Zoltan wrote:
Thanks, I did not know about this variable. Although the real hardware 
has the GPU soldered on the mainboard it makes sense to allow it to be 
disabled in QEMU especially at this stage when Linux kernel has some 
problem with it so this is a good idea.


I think the option is useful to boot Linux now until we improve rv100 
emulation enough to work with the Linux DRM driver so either way you'll 
have a problem: with -vga none not disabling soldered chip you can't boot 
normal Linux CDs without patching them, with -vga none obeyed you can't 
use PMON. But since PMON is not bundled in QEMU (we don't have the source 
of the actual board firmware, only a binary) it may be less of a problem 
than Linux install CDs not working. After install you could change Linux 
to use radeon framebuffer driver which probably works better. (Although 
I'm not sure if anyone actually tried to do that.)


But I don't really mind either way, go with what you prefer. I only care 
about the chip emulations used by this board not going away as I plan to 
use them for pegasos2 emulation but not the fulong board itself apart from 
using it for cross checking changes. I know about one problem with the 
via-ide part that I could reproduce with both:


https://osdn.net/projects/qmiga/ticket/38949

but I'm still not sure it's not missing irq emulation in my Marvel 
Discovery II emulation that's causing problem on pegasos2.



Reviewed-by: BALATON Zoltan 

When changing it you could also replace the -1 in pci_create with 
PCI_DEVFN(FULONG2E_ATI_SLOT, 0) to match the address the board has or 
should that be a separate patch?


Looks like this above comment was not considered last time, maybe if you 
change it now this could be fixed as well.


Regards,
BALATON Zoltan

[Bug 1839060] Re: HDA device non functional in Windows 10 1903

[Idar Lund]

Microsoft has fixed their hda driver

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  HDA device non functional in Windows 10 1903

Status in QEMU:
  Fix Released

Bug description:
  I made the update to 1903, and the HDA device stopped working.

  The driver says the device is working correctly, but it does not.
  When I try to open the Windows sound configuration, the dialog hangs and 
never shows it's content.

  Several people reported this back in May:

  https://windowsreport.com/windows-10-v1903-ich6-ich9-virtio/

  I can confirm I have exactly the same problem.

  Host is Arch Linux, current (5.2.5) kernel, QEMU 4.0.

  I enabled HDA debug output and compared an older, working Windows
  version to 1903, but could not see the difference. The driver seems to
  issue the same verbs.

  I am happy to provide additional information if needed.

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

[Bug 1839060] Re: HDA device non functional in Windows 10 1903

[Idar Lund]

Microsoft has updated their driver to 10.0.18362.356 and the sound is
now working with the audoidev hda.

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

Title:
  HDA device non functional in Windows 10 1903

Status in QEMU:
  Fix Released

Bug description:
  I made the update to 1903, and the HDA device stopped working.

  The driver says the device is working correctly, but it does not.
  When I try to open the Windows sound configuration, the dialog hangs and 
never shows it's content.

  Several people reported this back in May:

  https://windowsreport.com/windows-10-v1903-ich6-ich9-virtio/

  I can confirm I have exactly the same problem.

  Host is Arch Linux, current (5.2.5) kernel, QEMU 4.0.

  I enabled HDA debug output and compared an older, working Windows
  version to 1903, but could not see the difference. The driver seems to
  issue the same verbs.

  I am happy to provide additional information if needed.

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