Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> '
> On Tue, Mar 12, 2019 at 6:44 PM Markus Armbruster  wrote:
>>
>> Dear board code maintainers,
>>
>> This is a (rather late) follow-up to the last QEMU summit.  Minutes[*]:
>>
>>  * Deprecating unmaintained features (devices, targets, backends) in QEMU
>>
>>QEMU has a mechanism to deprecate features but there remains a lot of
>>old unmaintained code.  Refactoring is hindered by untested legacy
>>code, so there is a desire to deprecate unmaintained features more
>>often.
>>
>>[...]
>>
>>We should require at least a minimal test for each board; if nobody
>>cares enough to come up with one, that board should be deprecated.
>>
>>[...]
>>
>>Also see the qemu-devel discussion about deprecating code:
>>https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.
>>
>> That's a link to "Minutes of KVM Forum BoF on deprecating stuff".
>> Quote:
>>
>>  * One obvious class of candidates for removal is machines we don't know
>>how to boot, or can't boot, say because we lack required firmware
>>and/or OS.
>
> IIRC there is still a legal issue with some firmwares we don't have
> the sources. What is your idea here, ask the maintainer to run his
> tests and expect a manual confirmation, else deprecate?

Meaningful tests may require

(1) Parts we can distribute (i.e. they're free as in freedom)

(2) Parts we can download

(3) Parts only a privileged person (better be the maintainer) has

(4) Unobtanium

Tests requiring (1) or (2) can be automated.

For tests requiring (3), we can ask the privileged person to certify.
Whether the QEMU project is interested in maintaining such machines is
up to the project to decide.

Tests requiring (4) would be dead code.  The QEMU project maintaining
machines the project can't meaningfully test makes no sense.

>>Of course, "can boot" should be an automated test.  As a first step
>>towards that, we should at least document how to boot each machine.
>>We're going to ask machine maintainers to do that.
>>
>> Let's get going on this.
>>
>> I gathered the machine types, mapped them to source files, which I fed
>> to get_maintainer.pl.  Results are appended.  If you're cc'ed,
>> MAINTAINERS fingers you for at least one machine type's source file.
>> Please tell us for all of them how to to a "meaningful" boot test.
>
> This is a good start, but the -cpu option is important too.
>
> Example: nanoMIPS
>
> files:
> https://mipsdistros.mips.com/LinuxDistro/nanomips/buildroot/index.html
>
> qemu-system-mipsel -M malta -serial stdio -cpu I7200  -append
> "mem=256m@@0x0 rw console=ttyS0" -kernel
> generic_nano32r6el_page64k_dbg

One reason I asked for complete QEMU command lines :)

Covering the full cartesian product machine type × cpu type would be
better, but let's start small.

>> For now, what's "meaningful" is entirely up to you.  Booting Linux
>> certainly is.
>>
>> Make sure to include a complete QEMU command line.  If your QEMU command
>> line requires resources beyond the QEMU source tree and what we build
>> from it, please detail them, and provide download URLs as far as
>> possible.
>>
>> Goals for this exercise:
>>
>> * Gather information we need to cover more machines in our automated
>>   testing.
>>
>>   Related work:
>>   [PATCH v4 00/19] Acceptance Tests: target architecture support
>>   Message-Id: <20190312121150.8638-1-cr...@redhat.com>
>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html
>>
>> * Maybe identify a few machines we don't know how to boot anymore.
>>
>> Thanks in advance for your help!
[...]

Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error

[Fernando Casas Schössow]

Hi all,

Wanted to share one more update regarding this issue.
Since running the new package with the patch from Natanael, the issue never 
happen again.
It's been three weeks with all guests running on virtio-scsi and no issues at 
all so I guess we can consider this solved.

Thanks again to everyone that helped identifying and fixing this issue. Great 
work.

Cheers,

Fer

On jue, mar 7, 2019 at 8:14 AM, Fernando Casas Schössow 
 wrote:
After two weeks of running the new QEMU package everything is fine.
Moreover I migrated the rest of the guests (both Windows and Linux) to 
virtio-scsi and no issues so far.
I will monitor for another week but this issue seems pretty much fixed!

Kudos to each and everyone of you that helped finding and solving this issue.

Fer

[Qemu-devel] [Bug 1820247] Re: QEMU random crash caused by libspice-server

[Christian Ehrhardt ]

Hi Premysl,
this has similarities to [1] which was fixed long ago.
In case it is reproducible for you - as it was asked back then - it might be 
helpful attaching SPICE_DEBUG=1 log, using remote-viewer.

And if reproducible in general also worth a quick check to try with the
latest qemu version which atm is 3.1 that you have in Debian Buster.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8

** Bug watch added: Red Hat Bugzilla #980714
   https://bugzilla.redhat.com/show_bug.cgi?id=980714

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

Title:
  QEMU random crash caused by libspice-server

Status in QEMU:
  New

Bug description:
  Hi,

  One of our OpenStack instances crashed. It seems there was some
  problem related to SPICE. Attaching what we had in qemu log. Also
  sending our versions:

  Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6
  14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

  QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  
  root@pre-node1:~# cat /var/log/libvirt/qemu/instance-0038.log 
  2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), 
hostname: pre-node1
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name 
guest=instance-0038,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-0038/master-key.aes
 -machine pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off 
-cpu 
Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on
 -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-0038,share=yes,size=2147483648,host-nodes=0,policy=bind
 -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid 
3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual
 Machine' -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-0038/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive 
file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -add-fd set=0,fd=29 -chardev 
pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device 
isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on 
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
 -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
  2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev 
pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device redirected to 
/dev/pts/2 (label charserial0)
  inputs_channel_detach_tablet: 
  main_channel_link: add main channel client
  main_channel_client_handle_pong: net test: latency 32.76 ms, bitrate 
33384953 bps (31.838372 Mbps)
  red_qxl_set_cursor_peer: 
  inputs_connect: inputs channel client create

  (process:65324): Spice-WARNING **: 16:35:23.769: Failed to create channel 
client: Client 0x55e7c157e970: duplicate channel type 2 id 0
  red_qxl_set_cursor_peer: 

  (process:65324): Spice-WARNING **: 16:35:24.142: Failed to create
  channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0

  (process:65324): Spice-CRITICAL **: 16:35:24.142: 
cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed
  2019-03-13 15:35:31.785+: shutting down, reason=crashed


  
  I am also attaching some gdb information extracted from qemu crash dump file. 
These are backtraces of particular threads within the crashed QEMU process.

  
  Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)):
  #0  0x7f695f02d2b7 in __libc_write (fd=26, buf=0x7

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Bastian Koppelmann  writes:

> On 3/12/19 6:36 PM, Markus Armbruster wrote:
> [snip]
>>
>>  = hw/tricore/tricore_testboard.c =
>>  Bastian Koppelmann  (maintainer:TriCore)
>
>
> I created a patchset for tcg tests for this board
> (https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html)

That link takes me to my "Minutes of KVM Forum BoF on deprecating
stuff".  Pasto?

> but somehow it got lost in my daily work :). If this is what you want,
> I can make it camera ready for the next release.

I'd have to see what it is to know.

I'm looking for an "it boots" smoke test for full system emulation,
i.e. something of the form

0. Download this, create image that way, whatever it takes to enable:
1. Run qemu-system-tricore [arguments...] to boot a guest
2. Measure whether the boot succeeded

The longer term goal is to automate these tests.  But right now we're
just gathering information.

Re: [Qemu-devel] [PATCH 0/3] migration: add sztd compression

[Denis Plotnikov]

ping ping ping ping!

On 11.03.2019 11:20, Denis Plotnikov wrote:
> ping ping ping!
> 
> On 04.03.2019 18:10, Denis Plotnikov wrote:
>> ping!
>>
>> On 26.02.2019 16:15, Denis Plotnikov wrote:
>>> zstd date compression algorithm shows better performance on data 
>>> compression.
>>> It might be useful to employ the algorithm in VM migration to reduce CPU 
>>> usage.
>>> A user will be able to choose between those algorithms, therefor 
>>> compress-type
>>> migration parameter is added.
>>>
>>> Here are some results of performance comparison zstd vs gzip:
>>>
>>> host: i7-4790 8xCPU @ 3.60GHz, 16G RAM
>>> migration to the same host
>>> VM: 2xVCPU, 8G RAM total
>>> 5G RAM used, memory populated with postgreqsl data
>>> produced by pgbench performance benchmark
>>>
>>>
>>> Threads: 1 compress – 1 decompress
>>>
>>> zstd provides slightly less compression ratio with almost the same
>>> CPU usage but copes with RAM  compression roghly 2 times faster
>>>
>>> compression type  zlib   |  zstd
>>> -
>>> compression level  1   5 |   1   5
>>> compression ratio  6.927.05  |   6.696.89
>>> cpu idle, %82  83|   86  80
>>> time, sec  49  71|   26  31
>>> time diff to zlib, sec  -25 -41
>>>
>>>
>>> Threads: 8 compress – 2 decompress
>>>
>>> zstd provides the same migration time with less cpu consumption
>>>
>>> compression type none  |gzip(zlib)|  zstd
>>> --
>>> compression level- |  1  5   9|   1   5   15
>>> compression ratio- |  6.94   6.997.14 |   6.646.89
>>> 6.93
>>> time, sec154   |  22 23  27   |   23  23  25
>>> cpu idle, %  99|  45 30  12   |   70  52  23
>>> cpu idle diff to zlib  |  |  -25%-22%
>>> -11%
>>>
>>>
>>> Denis Plotnikov (3):
>>>  migration: rework compression code for adding more data compressors
>>>  hmp: add compress-type parameter to migration parameters
>>>  migration: add zstd compression
>>>
>>> configure |  26 
>>> hmp.c |   8 ++
>>> migration/migration.c |  45 ++-
>>> migration/migration.h |   1 +
>>> migration/qemu-file.c |  39 ++
>>> migration/qemu-file.h |  18 ++-
>>> migration/ram.c   | 291 ++
>>> qapi/migration.json   |  26 +++-
>>> 8 files changed, 369 insertions(+), 85 deletions(-)
>>>
>>
> 

-- 
Best,
Denis

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Michael Walle  writes:

> Am 2019-03-12 18:36, schrieb Markus Armbruster:
>> = hw/lm32/lm32_boards.c =
>> Michael Walle  (maintainer:LM32)
>>
>> = hw/lm32/milkymist.c =
>> Michael Walle  (maintainer:milkymist)
>>
>
> Hi folks,
>
> I guess it is time to pull the plug. Mainly, because I have no time
> for this anymore. I've always worked on this on my spare time and life
> changed. And secondly, I guess RISC-V is taking over ;) It has a far
> better ecosystem. Also, to my knowledge the only (public) user of LM32
> is milkymist and this project is dead for years now..
>
> So time to say goodbye. It was fun and I've learned a lot -
> technically and also how a huge open source project works. Thank you
> everyone for that :)

Thank *you* for your contribution!

> Basically everything still works and there are even TCG test cases
> which covers all instructions the processor has. But I doubt it makes
> any more sense to keep that architecture. If nobody wants to take over
> (I guess that is the case), I'll post my last and final commit to
> remove the lm32 architecture shortly..

We normally deprecate first, and remove only after a grace period,
commonly two releases.  If we deprecate right away (in 4.0), we'd remove
in 4.2, which I'd expect in December.  Would that work for you?

Re: [Qemu-devel] [PATCH] ati-vga: i2c fix

[Gerd Hoffmann]

  Hi,

> > A more correct model would probably be to create two i2c busses for
> > that, then hook up the ddc to one of them (possibly depending on a
> > config option).
> 
> Isn't it enough to only emulate the DVI port DDC then?

Well, strictly speaking the radion has 4 i2c busses and the most correct
way to emulate them is hooking up 4 busses.  But in practice it probably
doesn't matter much for the guest whenever we don't emulate the unused
busses or whenever we emulate a i2c bus with no devices connected ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2 08/12] pc-bios: add edk2 firmware binaries and variable store templates

[Gerd Hoffmann]

  Hi,

> > But that point is moot if we can get fully automated firmware builds
> > going, by using docker and a distro with cross compilers ...
> 
> The main problem would be that we target many different operating
> systems, but only Linux would be able to run the docker builds.
> So people on FreeBSD, macOS etc still need firmware binaries, or
> we would be forcing them to use Linux to build part of their system.

Sure, we should still provide firmware binaries, but that doesn't need
to be the git source tree then.  CI could provide firmware blobs for
download.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] spapr/irq: force XICS interrupt mode on non P9 machines

[Greg Kurz]

On Mon, 18 Mar 2019 07:27:59 +0100
Cédric Le Goater  wrote:

> On 3/18/19 2:52 AM, David Gibson wrote:
> > On Sun, Mar 17, 2019 at 09:33:42PM +0100, Cédric Le Goater wrote:  
> >> There is no need to propose the 'dual' interrupt mode interrupt device
> >> on POWER7/8 machines and the XIVE mode will not operate. Simply force
> >> XICS in this case.
> >>
> >> This makes the check in spapr_machine_init() redundant on XIVE-only
> >> machines.
> >>
> >> Signed-off-by: Cédric Le Goater   
> > 
> > This is not my preferred approach.  If the user explicitly selects
> > xive or dual mode with a POWER8 cpu, we should hard error, rather than
> > forcing a different mode from the one requested.  
> 
> I though so.
> 
> > We do need to make sure we default to xics mode with POWER8, even on
> > new machine types.  
> 
> That's the problem. 
> 
> When parsing the options, in the machine instance_init(), we don't 
> know the CPU type. 
> 

Yes but you still can have spapr_irq_init() to report an error, and
we have:

/* Set up Interrupt Controller before we create the VCPUs */
spapr_irq_init(spapr, &error_fatal);

Some remarks below.

> C. 
> 
> >> ---
> >>  hw/ppc/spapr_irq.c | 10 ++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> >> index f2ca1bb66c9d..d27ae68915a1 100644
> >> --- a/hw/ppc/spapr_irq.c
> >> +++ b/hw/ppc/spapr_irq.c
> >> @@ -16,6 +16,7 @@
> >>  #include "hw/ppc/spapr_xive.h"
> >>  #include "hw/ppc/xics.h"
> >>  #include "hw/ppc/xics_spapr.h"
> >> +#include "cpu-models.h"
> >>  #include "sysemu/kvm.h"
> >>  
> >>  #include "trace.h"
> >> @@ -655,6 +656,7 @@ SpaprIrq spapr_irq_dual = {
> >>  void spapr_irq_init(SpaprMachineState *spapr, Error **errp)
> >>  {
> >>  MachineState *machine = MACHINE(spapr);
> >> +Error *local_err = NULL;
> >>  
> >>  if (machine_kernel_irqchip_split(machine)) {
> >>  error_setg(errp, "kernel_irqchip split mode not supported on 
> >> pseries");
> >> @@ -667,6 +669,14 @@ void spapr_irq_init(SpaprMachineState *spapr, Error 
> >> **errp)
> >>  return;
> >>  }
> >>  
> >> +/* Force XICS on non P9 machines */
> >> +if (!ppc_type_check_compat(machine->cpu_type, 
> >> CPU_POWERPC_LOGICAL_3_00,
> >> +  0, spapr->max_compat_pvr)) {

This also takes into account a POWER9 (or newer) CPU running in architected
power8 (or less) mode, which is a good thing. Maybe this should be mentioned
in the changelog for clarity.

> >> +error_setg(&local_err, "forcing XICS interrupt controller");
> >> +warn_report_err(local_err);

BTW, at this point, local_err is a dangling pointer. If some future change
causes the variable to be passed again to error_setg(), QEMU will abort.
A better practice would be to set local_err to NULL if you don't return
right away.

Also, instead of doing error_setg()+warn_report_err(), you could just
call warn_report() directly, without involving an error variable.

Anyway, in the present case you just need to error_setg(errp) and return.

> >> +spapr->irq = &spapr_irq_xics;
> >> +}
> >> +
> >>  /* Initialize the MSI IRQ allocator. */
> >>  if (!SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
> >>  spapr_irq_msi_init(spapr, spapr->irq->nr_msis);  
> >   
> 

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Paolo Bonzini]

On 15/03/19 21:05, Alistair Francis wrote:
> Set msi_nonbroken as true for the PLIC.
> 
> According to the comment located here:
> https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> the msi_nonbroken variable should be set to true even if they don't
> support MSI. In this case that is what we are doing as we don't support
> MSI.
> 
> Signed-off-by: Alistair Francis 
> Reported-by: Andrea Bolognani 
> Reported-by: David Abdurachmanov 
> ---
> This should allow working pcie-root-ports in QEMU and allow libvirt
> to start using PCIe by default for RISC-V guests.
> 
> hw/riscv/sifive_plic.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> index d12ec3fc9a..4b0537c912 100644
> --- a/hw/riscv/sifive_plic.c
> +++ b/hw/riscv/sifive_plic.c
> @@ -22,6 +22,7 @@
>  #include "qemu/log.h"
>  #include "qemu/error-report.h"
>  #include "hw/sysbus.h"
> +#include "hw/pci/msi.h"
>  #include "target/riscv/cpu.h"
>  #include "hw/riscv/sifive_plic.h"
>  
> @@ -443,6 +444,8 @@ static void sifive_plic_realize(DeviceState *dev, Error 
> **errp)
>  plic->enable = g_new0(uint32_t, plic->bitfield_words * plic->num_addrs);
>  sysbus_init_mmio(SYS_BUS_DEVICE(dev), &plic->mmio);
>  qdev_init_gpio_in(dev, sifive_plic_irq_request, plic->num_sources);
> +
> +msi_nonbroken = true;
>  }
>  
>  static void sifive_plic_class_init(ObjectClass *klass, void *data)
> 

I can queue this patch, and add the "select MSI" to CONFIG_SIFIVE.

Paolo

Re: [Qemu-devel] [PATCH v5 00/20] Acceptance Tests: target architecture support

[Markus Armbruster]

I understand these tests could serve as "meaningful boot tests" in the
sense I used in "Maintainers, please tell us how to boot your
machines!"[*]  Which machine types do they cover?



[*] Message-ID: <87d0mwatbu@dusky.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2019-03/msg04177.html

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Peter Maydell  writes:

> On Tue, 12 Mar 2019 at 17:36, Markus Armbruster  wrote:
>> I gathered the machine types, mapped them to source files, which I fed
>> to get_maintainer.pl.  Results are appended.  If you're cc'ed,
>> MAINTAINERS fingers you for at least one machine type's source file.
>> Please tell us for all of them how to to a "meaningful" boot test.
>
> Note that I'm listed for a bunch of boards that are really
> in "odd fixes" status, which doesn't mean I'm the best person
> to say how to boot them...

That's okay.

Are there any machines where your MAINTAINERS entry should be adjusted
from maintainer to odd fixer?

[...]

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Markus Armbruster]

Alistair Francis  writes:

> Set msi_nonbroken as true for the PLIC.
>
> According to the comment located here:
> https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> the msi_nonbroken variable should be set to true even if they don't
> support MSI. In this case that is what we are doing as we don't support
> MSI.
>
> Signed-off-by: Alistair Francis 
> Reported-by: Andrea Bolognani 
> Reported-by: David Abdurachmanov 
> ---
> This should allow working pcie-root-ports in QEMU and allow libvirt
> to start using PCIe by default for RISC-V guests.

Lovely!  If more people reviewed and updated their interrupt controllers
this way, we'd be in better shape.

Re: [Qemu-devel] [PATCH 13/14] hw/hppa/Kconfig: Dino board requires e1000 network card

[Paolo Bonzini]

On 16/03/19 23:41, Philippe Mathieu-Daudé wrote:
> On 3/16/19 10:50 PM, Paolo Bonzini wrote:
>>> This fixes when configuring with --without-default-devices:
>>>
>>>   $ qemu-system-hppa
>>>   qemu-system-hppa: Unsupported NIC model: e1000
>>
>> This is intended.  --without-default-devices does not guarantee that you can 
>> start
>> the board except with --nodefaults.
> 
> Ah! Now I get it...

But actually it makes a lot of sense to add these as "imply" directives.
 This way, disabling CONFIG_PCI_DEVICES does result in a usable system.

Paolo

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Michael Walle]

[resend because my mobile client messed up the message and gmail 
rejected it]


Am 2019-03-18 09:15, schrieb Markus Armbruster:

Michael Walle  writes:


Am 2019-03-12 18:36, schrieb Markus Armbruster:

= hw/lm32/lm32_boards.c =
Michael Walle  (maintainer:LM32)

= hw/lm32/milkymist.c =
Michael Walle  (maintainer:milkymist)



Hi folks,

I guess it is time to pull the plug. Mainly, because I have no time
for this anymore. I've always worked on this on my spare time and life
changed. And secondly, I guess RISC-V is taking over ;) It has a far
better ecosystem. Also, to my knowledge the only (public) user of LM32
is milkymist and this project is dead for years now..

So time to say goodbye. It was fun and I've learned a lot -
technically and also how a huge open source project works. Thank you
everyone for that :)


Thank *you* for your contribution!


Basically everything still works and there are even TCG test cases
which covers all instructions the processor has. But I doubt it makes
any more sense to keep that architecture. If nobody wants to take over
(I guess that is the case), I'll post my last and final commit to
remove the lm32 architecture shortly..


We normally deprecate first, and remove only after a grace period,
commonly two releases.  If we deprecate right away (in 4.0), we'd 
remove

in 4.2, which I'd expect in December.  Would that work for you?


Sure, I reached out to some folks who still use lm32. One response is 
still pending. Is it possible to remove the depreciation again if 
someone steps in?


-michael

[Qemu-devel] [PATCH v15 18/24] replay: describe reverse debugging in docs/replay.txt

[Pavel Dovgalyuk]

This patch updates the documentation and describes usage of the reverse
debugging in QEMU+GDB.

Signed-off-by: Pavel Dovgalyuk 
---
 docs/replay.txt |   33 +
 1 file changed, 33 insertions(+)

diff --git a/docs/replay.txt b/docs/replay.txt
index ce97c3f72f..47b4f2d9f8 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -293,6 +293,39 @@ for recording and replaying must contain identical number 
of ports in record
 and replay modes, but their backends may differ.
 E.g., '-serial stdio' in record mode, and '-serial null' in replay mode.
 
+Reverse debugging
+-
+
+Reverse debugging allows "executing" the program in reverse direction.
+GDB remote protocol supports "reverse step" and "reverse continue"
+commands. The first one steps single instruction backwards in time,
+and the second one finds the last breakpoint in the past.
+
+Recorded executions may be used to enable reverse debugging. QEMU can't
+execute the code in backwards direction, but can load a snapshot and
+replay forward to find the desired position or breakpoint.
+
+The following GDB commands are supported:
+ - reverse-stepi (or rsi) - step one instruction backwards
+ - reverse-continue (or rc) - find last breakpoint in the past
+
+Reverse step loads the nearest snapshot and replays the execution until
+the required instruction is met.
+
+Reverse continue may include several passes of examining the execution
+between the snapshots. Each of the passes include the following steps:
+ 1. loading the snapshot
+ 2. replaying to examine the breakpoints
+ 3. if breakpoint or watchpoint was met
+- loading the snaphot again
+- replaying to the required breakpoint
+ 4. else
+- proceeding to the p.1 with the earlier snapshot
+
+Therefore usage of the reverse debugging requires at least one snapshot
+created in advance. See the "Snapshotting" section to learn about running
+record/replay and creating the snapshot in these modes.
+
 Replay log format
 -
 

[Qemu-devel] [PATCH v15 20/24] replay: document development rules

[Pavel Dovgalyuk]

This patch introduces docs/devel/replay.txt which describes the rules
that should be followed to make virtual devices usable in record/replay mode.

Signed-off-by: Pavel Dovgalyuk 

--

v9: fixed external virtual clock description (reported by Artem Pisarenko)
---
 docs/devel/replay.txt |   46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 docs/devel/replay.txt

diff --git a/docs/devel/replay.txt b/docs/devel/replay.txt
new file mode 100644
index 00..e641c35add
--- /dev/null
+++ b/docs/devel/replay.txt
@@ -0,0 +1,46 @@
+Record/replay mechanism, that could be enabled through icount mode, expects
+the virtual devices to satisfy the following requirements.
+
+The main idea behind this document is that everything that affects
+the guest state during execution in icount mode should be deterministic.
+
+Timers
+==
+
+All virtual devices should use virtual clock for timers that change the guest
+state. Virtual clock is deterministic, therefore such timers are deterministic
+too.
+
+Virtual devices can also use realtime clock for the events that do not change
+the guest state directly. When the clock ticking should depend on VM execution
+speed, use virtual clock with EXTERNAL attribute. It is not deterministic,
+but its speed depends on the guest execution. This clock is used by
+the virtual devices (e.g., slirp routing device) that lie outside the
+replayed guest.
+
+Bottom halves
+=
+
+Bottom half callbacks, that affect the guest state, should be invoked through
+replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions.
+Their invocations are saved in record mode and synchronized with the existing
+log in replay mode.
+
+Saving/restoring the VM state
+=
+
+All fields in the device state structure (including virtual timers)
+should be restored by loadvm to the same values they had before savevm.
+
+Avoid accessing other devices' state, because the order of saving/restoring
+is not defined. It means that you should not call functions like
+'update_irq' in post_load callback. Save everything explicitly to avoid
+the dependencies that may make restoring the VM state non-deterministic.
+
+Stopping the VM
+===
+
+Stopping the guest should not interfere with its state (with the exception
+of the network connections, that could be broken by the remote timeouts).
+VM can be stopped at any moment of replay by the user. Restarting the VM
+after that stop should not break the replay by the unneeded guest state change.

[Qemu-devel] [PATCH v15 24/24] icount: clean up cpu_can_io before jumping to the next block

[Pavel Dovgalyuk]

Most of IO instructions can be executed only at the end of the block in
icount mode. Therefore translator can set cpu_can_io flag when translating
the last instruction.
But when the blocks are chained, then this flag is not reset and may
remain set at the beginning of the next block.
This patch resets the flag before "chaining" the translation blocks.

Signed-off-by: Pavel Dovgalyuk 
---
 accel/tcg/tcg-runtime.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/accel/tcg/tcg-runtime.c b/accel/tcg/tcg-runtime.c
index d0d4484406..5871f5aba2 100644
--- a/accel/tcg/tcg-runtime.c
+++ b/accel/tcg/tcg-runtime.c
@@ -151,6 +151,8 @@ void *HELPER(lookup_tb_ptr)(CPUArchState *env)
 target_ulong cs_base, pc;
 uint32_t flags;
 
+/* We are going to jump to the next block. can_do_io should be reset */
+cpu->can_do_io = !use_icount;
 tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, curr_cflags());
 if (tb == NULL) {
 return tcg_ctx->code_gen_epilogue;

[Qemu-devel] [PATCH v15 17/24] gdbstub: add reverse continue support in replay mode

[Pavel Dovgalyuk]

This patch adds support of the reverse continue operation for gdbstub.
Reverse continue finds the last breakpoint that would happen in normal
execution from the beginning to the current moment.
Implementation of the reverse continue replays the execution twice:
to find the breakpoints that were hit and to seek to the last breakpoint.
Reverse continue loads the previous snapshot and tries to find the breakpoint
since that moment. If there are no such breakpoints, it proceeds to
the earlier snapshot, and so on. When no breakpoints or watchpoints were
hit at all, execution stops at the beginning of the replay log.

Signed-off-by: Pavel Dovgalyuk 
---
 cpus.c|5 +++
 exec.c|1 +
 gdbstub.c |   10 ++
 include/sysemu/replay.h   |8 +
 replay/replay-debugging.c |   71 +
 stubs/replay.c|5 +++
 6 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/cpus.c b/cpus.c
index 44d0b23435..ba4849861d 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1110,6 +1110,11 @@ static void cpu_handle_guest_debug(CPUState *cpu)
 cpu->stopped = true;
 } else {
 if (!cpu->singlestep_enabled) {
+/*
+ * Report about the breakpoint and
+ * make a single step to skip it
+ */
+replay_breakpoint();
 cpu_single_step(cpu, SSTEP_ENABLE);
 } else {
 cpu_single_step(cpu, 0);
diff --git a/exec.c b/exec.c
index 474d7bbe00..4f4351650a 100644
--- a/exec.c
+++ b/exec.c
@@ -2776,6 +2776,7 @@ static void check_watchpoint(int offset, int len, 
MemTxAttrs attrs, int flags)
  * Don't process the watchpoints when we are
  * in a reverse debugging operation.
  */
+replay_breakpoint();
 return;
 }
 if (flags == BP_MEM_READ) {
diff --git a/gdbstub.c b/gdbstub.c
index 9f987650ae..6e2dd9371f 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1444,6 +1444,14 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 put_packet(s, "E14");
 break;
 }
+case 'c':
+if (replay_reverse_continue()) {
+gdb_continue(s);
+return RS_IDLE;
+} else {
+put_packet(s, "E14");
+break;
+}
 default:
 goto unknown_command;
 }
@@ -1754,7 +1762,7 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 pstrcat(buf, sizeof(buf), ";multiprocess+");
 
 if (replay_mode == REPLAY_MODE_PLAY) {
-pstrcat(buf, sizeof(buf), ";ReverseStep+");
+pstrcat(buf, sizeof(buf), ";ReverseStep+;ReverseContinue+");
 }
 
 put_packet(s, buf);
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 533003f2b0..1d18c9b6ea 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -79,11 +79,19 @@ const char *replay_get_filename(void);
  * Returns true on success.
  */
 bool replay_reverse_step(void);
+/*
+ * Start searching the last breakpoint/watchpoint.
+ * Used by gdbstub for backwards debugging.
+ * Returns true if the process successfully started.
+ */
+bool replay_reverse_continue(void);
 /*
  * Returns true if replay module is processing
  * reverse_continue or reverse_step request
  */
 bool replay_running_debug(void);
+/* Called in reverse debugging mode to collect breakpoint information */
+void replay_breakpoint(void);
 
 /* Processing the instructions */
 
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index 3d94859b8f..abb5fe687f 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -22,6 +22,8 @@
 #include "migration/snapshot.h"
 
 static bool replay_is_debugging;
+static int64_t replay_last_breakpoint;
+static int64_t replay_last_snapshot;
 
 bool replay_running_debug(void)
 {
@@ -252,3 +254,72 @@ bool replay_reverse_step(void)
 
 return false;
 }
+
+static void replay_continue_end(void)
+{
+replay_is_debugging = false;
+vm_stop(RUN_STATE_DEBUG);
+replay_delete_break();
+}
+
+static void replay_continue_stop(void *opaque)
+{
+Error *err = NULL;
+if (replay_last_breakpoint != -1LL) {
+replay_seek(replay_last_breakpoint, replay_stop_vm_debug, &err);
+if (err) {
+error_free(err);
+replay_continue_end();
+}
+return;
+}
+/*
+ * No breakpoints since the last snapshot.
+ * Find previous snapshot and try again.
+ */
+if (replay_last_snapshot != 0) {
+replay_seek(replay_last_snapshot - 1, replay_continue_stop, &err);
+if (err) {
+error_free(err);
+replay_continue_end();
+}
+replay_last_snapshot = replay_get_current_step();
+ 

[Qemu-devel] [PATCH v15 21/24] util/qemu-timer: refactor deadline calculation for external timers

[Pavel Dovgalyuk]

icount-based record/replay uses qemu_clock_deadline_ns_all to measure
the period until vCPU may be interrupted.
This function takes in account the virtual timers, because they belong
to the virtual devices that may generate interrupt request or affect
the virtual machine state.
However, there are a subset of virtual timers, that are marked with
'external' flag. These do not change the virtual machine state and
only based on virtual clock. Calculating the deadling using the external
timers breaks the determinism, because they do not belong to the replayed
part of the virtual machine.
This patch fixes the deadline calculation for this case.

Signed-off-by: Pavel Dovgalyuk 

--

v15 changes:
 - fixed misprint in the test
---
 cpus.c|9 -
 include/qemu/timer.h  |7 +++
 qtest.c   |2 +-
 tests/ptimer-test-stubs.c |4 ++--
 tests/ptimer-test.c   |4 ++--
 util/qemu-timer.c |   41 +
 6 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/cpus.c b/cpus.c
index ba4849861d..2cad26f96c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -550,7 +550,7 @@ void qtest_clock_warp(int64_t dest)
 assert(qtest_enabled());
 aio_context = qemu_get_aio_context();
 while (clock < dest) {
-int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadline_ns();
 int64_t warp = qemu_soonest_timeout(dest - clock, deadline);
 
 seqlock_write_lock(&timers_state.vm_clock_seqlock,
@@ -610,7 +610,7 @@ void qemu_start_warp_timer(void)
 
 /* We want to use the earliest deadline from ALL vm_clocks */
 clock = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT);
-deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+deadline = virtual_clock_deadline_ns();
 if (deadline < 0) {
 static bool notified;
 if (!icount_sleep && !notified) {
@@ -1356,7 +1356,7 @@ static int64_t tcg_get_icount_limit(void)
 int64_t deadline;
 
 if (replay_mode != REPLAY_MODE_PLAY) {
-deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+deadline = virtual_clock_deadline_ns();
 
 /* Maintain prior (possibly buggy) behaviour where if no deadline
  * was set (as there is no QEMU_CLOCK_VIRTUAL timer) or it is more than
@@ -1377,8 +1377,7 @@ static void handle_icount_deadline(void)
 {
 assert(qemu_in_vcpu_thread());
 if (use_icount) {
-int64_t deadline =
-qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadline_ns();
 
 if (deadline == 0) {
 /* Wake up other AioContexts.  */
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index a86330c987..cfc77450f2 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -176,16 +176,15 @@ bool qemu_clock_expired(QEMUClockType type);
 bool qemu_clock_use_for_deadline(QEMUClockType type);
 
 /**
- * qemu_clock_deadline_ns_all:
- * @type: the clock type
+ * virtual_clock_deadline_ns:
  *
  * Calculate the deadline across all timer lists associated
- * with a clock (as opposed to just the default one)
+ * with virtual clock (excluding external timers)
  * in nanoseconds, or -1 if no timer is set to expire.
  *
  * Returns: time until expiry in nanoseconds or -1
  */
-int64_t qemu_clock_deadline_ns_all(QEMUClockType type);
+int64_t virtual_clock_deadline_ns(void);
 
 /**
  * qemu_clock_get_main_loop_timerlist:
diff --git a/qtest.c b/qtest.c
index 527141785f..8000ee0714 100644
--- a/qtest.c
+++ b/qtest.c
@@ -655,7 +655,7 @@ static void qtest_process_command(CharBackend *chr, gchar 
**words)
 int ret = qemu_strtoi64(words[1], NULL, 0, &ns);
 g_assert(ret == 0);
 } else {
-ns = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+ns = virtual_clock_deadline_ns();
 }
 qtest_clock_warp(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + ns);
 qtest_send_prefix(chr);
diff --git a/tests/ptimer-test-stubs.c b/tests/ptimer-test-stubs.c
index 54b3fd26f6..49acfed76f 100644
--- a/tests/ptimer-test-stubs.c
+++ b/tests/ptimer-test-stubs.c
@@ -88,9 +88,9 @@ int64_t qemu_clock_get_ns(QEMUClockType type)
 return ptimer_test_time_ns;
 }
 
-int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
+int64_t virtual_clock_deadline_ns(void)
 {
-QEMUTimerList *timer_list = main_loop_tlg.tl[type];
+QEMUTimerList *timer_list = main_loop_tlg.tl[QEMU_CLOCK_VIRTUAL];
 QEMUTimer *t = timer_list->active_timers.next;
 int64_t deadline = -1;
 
diff --git a/tests/ptimer-test.c b/tests/ptimer-test.c
index b30aad0737..338a4e0c10 100644
--- a/tests/ptimer-test.c
+++ b/tests/ptimer-test.c
@@ -50,13 +50,13 @@ static void ptimer_test_set_qemu_time_ns(int64_t ns)
 
 static void qemu_clock_step(uint64_t ns)
 {
-int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadlin

[Qemu-devel] [PATCH v15 19/24] replay: add BH oneshot event for block layer

[Pavel Dovgalyuk]

Replay is capable of recording normal BH events, but sometimes
there are single use callbacks scheduled with aio_bh_schedule_oneshot
function. This patch enables recording and replaying such callbacks.
Block layer uses these events for calling the completion function.
Replaying these calls makes the execution deterministic.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 

--

v6:
 - moved stub function to the separate file for fixing linux-user build
v10:
 - replaced all block layer aio_bh_schedule_oneshot calls
---
 block/block-backend.c|8 +---
 block/io.c   |4 ++--
 block/iscsi.c|5 +++--
 block/nfs.c  |5 +++--
 block/null.c |4 +++-
 block/nvme.c |6 --
 block/rbd.c  |5 +++--
 block/vxhs.c |5 +++--
 include/sysemu/replay.h  |3 +++
 replay/replay-events.c   |   16 
 replay/replay-internal.h |1 +
 replay/replay.c  |2 +-
 stubs/Makefile.objs  |1 +
 stubs/replay-user.c  |9 +
 14 files changed, 57 insertions(+), 17 deletions(-)
 create mode 100644 stubs/replay-user.c

diff --git a/block/block-backend.c b/block/block-backend.c
index edad02a0f2..5b200bc660 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -17,6 +17,7 @@
 #include "block/throttle-groups.h"
 #include "sysemu/blockdev.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/replay.h"
 #include "qapi/error.h"
 #include "qapi/qapi-events-block.h"
 #include "qemu/id.h"
@@ -1284,7 +1285,8 @@ BlockAIOCB *blk_abort_aio_request(BlockBackend *blk,
 acb->blk = blk;
 acb->ret = ret;
 
-aio_bh_schedule_oneshot(blk_get_aio_context(blk), error_callback_bh, acb);
+replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
+ error_callback_bh, acb);
 return &acb->common;
 }
 
@@ -1340,8 +1342,8 @@ static BlockAIOCB *blk_aio_prwv(BlockBackend *blk, 
int64_t offset, int bytes,
 
 acb->has_returned = true;
 if (acb->rwco.ret != NOT_DONE) {
-aio_bh_schedule_oneshot(blk_get_aio_context(blk),
-blk_aio_complete_bh, acb);
+replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
+ blk_aio_complete_bh, acb);
 }
 
 return &acb->common;
diff --git a/block/io.c b/block/io.c
index 866fd70d96..d2308655fd 100644
--- a/block/io.c
+++ b/block/io.c
@@ -340,8 +340,8 @@ static void coroutine_fn 
bdrv_co_yield_to_drain(BlockDriverState *bs,
 if (bs) {
 bdrv_inc_in_flight(bs);
 }
-aio_bh_schedule_oneshot(bdrv_get_aio_context(bs),
-bdrv_co_drain_bh_cb, &data);
+replay_bh_schedule_oneshot_event(bdrv_get_aio_context(bs),
+ bdrv_co_drain_bh_cb, &data);
 
 qemu_coroutine_yield();
 /* If we are resumed from some other event (such as an aio completion or a
diff --git a/block/iscsi.c b/block/iscsi.c
index f31c612d53..f896793a57 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -38,6 +38,7 @@
 #include "qemu/iov.h"
 #include "qemu/option.h"
 #include "qemu/uuid.h"
+#include "sysemu/replay.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-misc.h"
 #include "qapi/qmp/qdict.h"
@@ -279,8 +280,8 @@ iscsi_co_generic_cb(struct iscsi_context *iscsi, int status,
 
 out:
 if (iTask->co) {
-aio_bh_schedule_oneshot(iTask->iscsilun->aio_context,
- iscsi_co_generic_bh_cb, iTask);
+replay_bh_schedule_oneshot_event(iTask->iscsilun->aio_context,
+ iscsi_co_generic_bh_cb, iTask);
 } else {
 iTask->complete = 1;
 }
diff --git a/block/nfs.c b/block/nfs.c
index 531903610b..f9b5eafa9c 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -36,6 +36,7 @@
 #include "qemu/uri.h"
 #include "qemu/cutils.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/replay.h"
 #include "qapi/qapi-visit-block-core.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qstring.h"
@@ -256,8 +257,8 @@ nfs_co_generic_cb(int ret, struct nfs_context *nfs, void 
*data,
 if (task->ret < 0) {
 error_report("NFS Error: %s", nfs_get_error(nfs));
 }
-aio_bh_schedule_oneshot(task->client->aio_context,
-nfs_co_generic_bh_cb, task);
+replay_bh_schedule_oneshot_event(task->client->aio_context,
+ nfs_co_generic_bh_cb, task);
 }
 
 static int coroutine_fn nfs_co_preadv(BlockDriverState *bs, uint64_t offset,
diff --git a/block/null.c b/block/null.c
index a322929478..5701b4b945 100644
--- a/block/null.c
+++ b/block/null.c
@@ -16,6 +16,7 @@
 #include "qapi/qmp/qstring.h"
 #include "qemu/option.h"
 #include "block/block_int.h"
+#include "sysemu/replay.h"
 
 #define NULL_OPT_LATENCY "latency-ns"
 #define NULL_OPT_ZEROES  "read-zeroes"
@@ -178,7 +179,8 @@ static inline BlockAIOCB *null_aio_common(BlockDriverState 
*bs,

[Qemu-devel] [PATCH v15 23/24] replay: rename step-related variables and functions

[Pavel Dovgalyuk]

This patch renames replay_get_current_step() and related variables
to make these names consistent with hmp/qmp commands.

Signed-off-by: Pavel Dovgalyuk 
---
 blockdev.c|2 +-
 include/sysemu/replay.h   |2 +-
 migration/savevm.c|2 +-
 replay/replay-debugging.c |   30 --
 replay/replay-events.c|4 ++--
 replay/replay-internal.c  |   10 +-
 replay/replay-internal.h  |   10 +-
 replay/replay-snapshot.c  |6 +++---
 replay/replay-time.c  |2 +-
 replay/replay.c   |   26 +-
 10 files changed, 48 insertions(+), 46 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 183fd3f7f6..83eb7c1833 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1454,7 +1454,7 @@ static void internal_snapshot_prepare(BlkActionState 
*common,
 sn->date_nsec = tv.tv_usec * 1000;
 sn->vm_clock_nsec = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
 if (replay_mode != REPLAY_MODE_NONE) {
-sn->icount = replay_get_current_step();
+sn->icount = replay_get_current_icount();
 } else {
 sn->icount = -1ULL;
 }
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index b7394a1f5c..057a458463 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -96,7 +96,7 @@ void replay_breakpoint(void);
 /* Processing the instructions */
 
 /*! Returns number of executed instructions. */
-uint64_t replay_get_current_step(void);
+uint64_t replay_get_current_icount(void);
 /*! Returns number of instructions to execute in replay mode. */
 int replay_get_instructions(void);
 /*! Updates instructions counter in replay mode. */
diff --git a/migration/savevm.c b/migration/savevm.c
index 6a0ebacfed..74351fffeb 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2597,7 +2597,7 @@ int save_snapshot(const char *name, Error **errp)
 sn->date_nsec = tv.tv_usec * 1000;
 sn->vm_clock_nsec = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
 if (replay_mode != REPLAY_MODE_NONE) {
-sn->icount = replay_get_current_step();
+sn->icount = replay_get_current_icount();
 } else {
 sn->icount = -1ULL;
 }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index abb5fe687f..b2275612c7 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -38,7 +38,7 @@ void hmp_info_replay(Monitor *mon, const QDict *qdict)
 monitor_printf(mon,
 "%s execution '%s': instruction count = %"PRId64"\n",
 replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
-replay_get_filename(), replay_get_current_step());
+replay_get_filename(), replay_get_current_icount());
 }
 }
 
@@ -51,7 +51,7 @@ ReplayInfo *qmp_query_replay(Error **errp)
 retval->filename = g_strdup(replay_get_filename());
 retval->has_filename = true;
 }
-retval->icount = replay_get_current_step();
+retval->icount = replay_get_current_icount();
 return retval;
 }
 
@@ -59,7 +59,7 @@ static void replay_break(uint64_t icount, QEMUTimerCB 
callback, void *opaque)
 {
 assert(replay_mode == REPLAY_MODE_PLAY);
 assert(replay_mutex_locked());
-assert(replay_break_icount >= replay_get_current_step());
+assert(replay_break_icount >= replay_get_current_icount());
 assert(callback);
 
 replay_break_icount = icount;
@@ -94,7 +94,7 @@ static void replay_stop_vm(void *opaque)
 void qmp_replay_break(int64_t icount, Error **errp)
 {
 if (replay_mode == REPLAY_MODE_PLAY) {
-if (icount >= replay_get_current_step()) {
+if (icount >= replay_get_current_icount()) {
 replay_break(icount, replay_stop_vm, NULL);
 } else {
 error_setg(errp,
@@ -196,14 +196,14 @@ static void replay_seek(int64_t icount, QEMUTimerCB 
callback, Error **errp)
 
 snapshot = replay_find_nearest_snapshot(icount, &snapshot_icount);
 if (snapshot) {
-if (icount < replay_get_current_step()
-|| replay_get_current_step() < snapshot_icount) {
+if (icount < replay_get_current_icount()
+|| replay_get_current_icount() < snapshot_icount) {
 vm_stop(RUN_STATE_RESTORE_VM);
 load_snapshot(snapshot, errp);
 }
 g_free(snapshot);
 }
-if (replay_get_current_step() <= icount) {
+if (replay_get_current_icount() <= icount) {
 replay_break(icount, callback, NULL);
 vm_start();
 } else {
@@ -242,8 +242,9 @@ bool replay_reverse_step(void)
 
 assert(replay_mode == REPLAY_MODE_PLAY);
 
-if (replay_get_current_step() != 0) {
-replay_seek(replay_get_current_step() - 1, replay_stop_vm_debug, &err);
+if (replay_get_current_icount() != 0) {
+replay_seek(replay_get_current_icount() - 1,
+replay_stop_vm_debug, &err);
 if (err) {
 error_free(err);
 return false;
@@ -283,7 +284,7 @@ static void replay_con

[Qemu-devel] [PATCH v15 16/24] gdbstub: add reverse step support in replay mode

[Pavel Dovgalyuk]

GDB remote protocol supports two reverse debugging commands:
reverse step and reverse continue.
This patch adds support of the first one to the gdbstub.
Reverse step is intended to step one instruction in the backwards
direction. This is not possible in regular execution.
But replayed execution is deterministic, therefore we can load one of
the prior snapshots and proceed to the desired step. It is equivalent
to stepping one instruction back.
There should be at least one snapshot preceding the debugged part of
the replay log.

Signed-off-by: Pavel Dovgalyuk 
---
 accel/tcg/translator.c|1 +
 cpus.c|   14 +++---
 exec.c|7 +++
 gdbstub.c |   44 +---
 include/sysemu/replay.h   |   11 +++
 replay/replay-debugging.c |   33 +
 stubs/replay.c|5 +
 7 files changed, 109 insertions(+), 6 deletions(-)

diff --git a/accel/tcg/translator.c b/accel/tcg/translator.c
index afd0a49ea6..33a543e82f 100644
--- a/accel/tcg/translator.c
+++ b/accel/tcg/translator.c
@@ -17,6 +17,7 @@
 #include "exec/gen-icount.h"
 #include "exec/log.h"
 #include "exec/translator.h"
+#include "sysemu/replay.h"
 
 /* Pairs with tcg_clear_temp_count.
To be called by #TranslatorOps.{translate_insn,tb_stop} if
diff --git a/cpus.c b/cpus.c
index 5ff61fbf53..44d0b23435 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1104,9 +1104,17 @@ static bool cpu_can_run(CPUState *cpu)
 
 static void cpu_handle_guest_debug(CPUState *cpu)
 {
-gdb_set_stop_cpu(cpu);
-qemu_system_debug_request();
-cpu->stopped = true;
+if (!replay_running_debug()) {
+gdb_set_stop_cpu(cpu);
+qemu_system_debug_request();
+cpu->stopped = true;
+} else {
+if (!cpu->singlestep_enabled) {
+cpu_single_step(cpu, SSTEP_ENABLE);
+} else {
+cpu_single_step(cpu, 0);
+}
+}
 }
 
 #ifdef CONFIG_LINUX
diff --git a/exec.c b/exec.c
index 86a38d3b3b..474d7bbe00 100644
--- a/exec.c
+++ b/exec.c
@@ -2771,6 +2771,13 @@ static void check_watchpoint(int offset, int len, 
MemTxAttrs attrs, int flags)
 QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
 if (cpu_watchpoint_address_matches(wp, vaddr, len)
 && (wp->flags & flags)) {
+if (replay_running_debug()) {
+/*
+ * Don't process the watchpoints when we are
+ * in a reverse debugging operation.
+ */
+return;
+}
 if (flags == BP_MEM_READ) {
 wp->flags |= BP_WATCHPOINT_HIT_READ;
 } else {
diff --git a/gdbstub.c b/gdbstub.c
index bc774ae992..9f987650ae 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -39,6 +39,7 @@
 #include "sysemu/kvm.h"
 #include "exec/semihost.h"
 #include "exec/exec-all.h"
+#include "sysemu/replay.h"
 
 #ifdef CONFIG_USER_ONLY
 #define GDB_ATTACHED "0"
@@ -344,6 +345,20 @@ typedef struct GDBState {
  */
 static int sstep_flags = SSTEP_ENABLE|SSTEP_NOIRQ|SSTEP_NOTIMER;
 
+/* Retrieves flags for single step mode. */
+static int get_sstep_flags(void)
+{
+/*
+ * In replay mode all events written into the log should be replayed.
+ * That is why NOIRQ flag is removed in this mode.
+ */
+if (replay_mode != REPLAY_MODE_NONE) {
+return SSTEP_ENABLE;
+} else {
+return sstep_flags;
+}
+}
+
 static GDBState *gdbserver_state;
 
 bool gdb_has_xml;
@@ -434,7 +449,7 @@ static int gdb_continue_partial(GDBState *s, char 
*newstates)
 CPU_FOREACH(cpu) {
 if (newstates[cpu->cpu_index] == 's') {
 trace_gdbstub_op_stepping(cpu->cpu_index);
-cpu_single_step(cpu, sstep_flags);
+cpu_single_step(cpu, get_sstep_flags());
 }
 }
 s->running_state = 1;
@@ -453,7 +468,7 @@ static int gdb_continue_partial(GDBState *s, char 
*newstates)
 break; /* nothing to do here */
 case 's':
 trace_gdbstub_op_stepping(cpu->cpu_index);
-cpu_single_step(cpu, sstep_flags);
+cpu_single_step(cpu, get_sstep_flags());
 cpu_resume(cpu);
 flag = 1;
 break;
@@ -1414,9 +1429,28 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 addr = strtoull(p, (char **)&p, 16);
 gdb_set_cpu_pc(s, addr);
 }
-cpu_single_step(s->c_cpu, sstep_flags);
+cpu_single_step(s->c_cpu, get_sstep_flags());
 gdb_continue(s);
 return RS_IDLE;
+case 'b':
+/* Backward debugging commands */
+if (replay_mode == REPLAY_MODE_PLAY) {
+switch (*p) {
+case 's':
+if (replay_reverse_step()) {
+gdb_continue(s);
+return RS_IDLE;
+} else {
+put_packet(s, "E14");
+

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Palmer Dabbelt]

On Mon, 18 Mar 2019 01:39:46 PDT (-0700), pbonz...@redhat.com wrote:

On 15/03/19 21:05, Alistair Francis wrote:

Set msi_nonbroken as true for the PLIC.

According to the comment located here:
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
the msi_nonbroken variable should be set to true even if they don't
support MSI. In this case that is what we are doing as we don't support
MSI.

Signed-off-by: Alistair Francis 
Reported-by: Andrea Bolognani 
Reported-by: David Abdurachmanov 
---
This should allow working pcie-root-ports in QEMU and allow libvirt
to start using PCIe by default for RISC-V guests.

hw/riscv/sifive_plic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
index d12ec3fc9a..4b0537c912 100644
--- a/hw/riscv/sifive_plic.c
+++ b/hw/riscv/sifive_plic.c
@@ -22,6 +22,7 @@
 #include "qemu/log.h"
 #include "qemu/error-report.h"
 #include "hw/sysbus.h"
+#include "hw/pci/msi.h"
 #include "target/riscv/cpu.h"
 #include "hw/riscv/sifive_plic.h"

@@ -443,6 +444,8 @@ static void sifive_plic_realize(DeviceState *dev, Error 
**errp)
 plic->enable = g_new0(uint32_t, plic->bitfield_words * plic->num_addrs);
 sysbus_init_mmio(SYS_BUS_DEVICE(dev), &plic->mmio);
 qdev_init_gpio_in(dev, sifive_plic_irq_request, plic->num_sources);
+
+msi_nonbroken = true;
 }

 static void sifive_plic_class_init(ObjectClass *klass, void *data)



I can queue this patch, and add the "select MSI" to CONFIG_SIFIVE.


Works for me.  Thanks!

[Qemu-devel] [PATCH v15 22/24] replay: fix replay shutdown

[Pavel Dovgalyuk]

This patch fixes shutdown of the replay process, which is terminated with
the assert when shutdown event is read from the log.
replay_finish_event reads new data_kind and therefore the value of data_kind
should be preserved to be valid at qemu_system_shutdown_request call.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/replay/replay.c b/replay/replay.c
index e578958659..8f2e17c8cb 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -49,14 +49,14 @@ bool replay_next_event_is(int event)
 }
 
 while (true) {
-if (event == replay_state.data_kind) {
+unsigned int data_kind = replay_state.data_kind;
+if (event == data_kind) {
 res = true;
 }
-switch (replay_state.data_kind) {
+switch (data_kind) {
 case EVENT_SHUTDOWN ... EVENT_SHUTDOWN_LAST:
 replay_finish_event();
-qemu_system_shutdown_request(replay_state.data_kind -
- EVENT_SHUTDOWN);
+qemu_system_shutdown_request(data_kind - EVENT_SHUTDOWN);
 break;
 default:
 /* clock, time_t, checkpoint and other events */

[Qemu-devel] [PATCH v15 12/24] replay: introduce breakpoint at the specified step

[Pavel Dovgalyuk]

This patch introduces replay_break, replay_delete_break
qmp and hmp commands.
These commands allow stopping at the specified instruction.
It may be useful for debugging when there are some known
events that should be investigated.
replay_break command has one argument - number of instructions
executed since the start of the replay.
replay_delete_break removes previously set breakpoint.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - renamed replay_break qmp command into replay-break
   (suggested by Eric Blake)
v7:
 - introduces replay_delete_break command
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the description
   (suggested by Markus Armbruster)
v10:
 - updated descriptions (suggested by Markus Armbruster)
---
 hmp-commands.hx   |   34 ++
 hmp.h |2 +
 qapi/replay.json  |   36 +++
 replay/replay-debugging.c |   86 +
 replay/replay-internal.h  |4 ++
 replay/replay.c   |   17 +
 6 files changed, 179 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 9b4035965c..1eb07e7bcc 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1911,6 +1911,40 @@ ETEXI
 STEXI
 @item qom-set @var{path} @var{property} @var{value}
 Set QOM property @var{property} of object at location @var{path} to value 
@var{value}
+ETEXI
+
+{
+.name   = "replay_break",
+.args_type  = "icount:i",
+.params = "icount",
+.help   = "set breakpoint at the specified instruction count",
+.cmd= hmp_replay_break,
+},
+
+STEXI
+@item replay_break @var{icount}
+@findex replay_break
+Set replay breakpoint at instruction count @var{icount}.
+Execution stops when the specified instruction is reached.
+There can be at most one breakpoint. When breakpoint is set, any prior
+one is removed.  The breakpoint may be set only in replay mode and only
+"in the future", i.e. at instruction counts greater than the current one.
+The current instruction count can be observed with 'info replay'.
+ETEXI
+
+{
+.name   = "replay_delete_break",
+.args_type  = "",
+.params = "",
+.help   = "removes replay breakpoint",
+.cmd= hmp_replay_delete_break,
+},
+
+STEXI
+@item replay_delete_break
+@findex replay_delete_break
+Remove replay breakpoint which was previously set with replay_break.
+The command is ignored when there are no replay breakpoints.
 ETEXI
 
 {
diff --git a/hmp.h b/hmp.h
index c53e14e917..c3e7354dd3 100644
--- a/hmp.h
+++ b/hmp.h
@@ -151,5 +151,7 @@ void hmp_info_vm_generation_id(Monitor *mon, const QDict 
*qdict);
 void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
 void hmp_info_sev(Monitor *mon, const QDict *qdict);
 void hmp_info_replay(Monitor *mon, const QDict *qdict);
+void hmp_replay_break(Monitor *mon, const QDict *qdict);
+void hmp_replay_delete_break(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/replay.json b/qapi/replay.json
index 4206150544..84c148cc4e 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -63,3 +63,39 @@
 ##
 { 'command': 'query-replay',
   'returns': 'ReplayInfo' }
+
+##
+# @replay-break:
+#
+# Set replay breakpoint at instruction count @icount.
+# Execution stops when the specified instruction is reached.
+# There can be at most one breakpoint. When breakpoint is set, any prior
+# one is removed.  The breakpoint may be set only in replay mode and only
+# "in the future", i.e. at instruction counts greater than the current one.
+# The current instruction count can be observed with @query-replay.
+#
+# @icount: instruction count to stop at
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-break", "data": { "icount": 220414 } }
+#
+##
+{ 'command': 'replay-break', 'data': { 'icount': 'int' } }
+
+##
+# @replay-delete-break:
+#
+# Remove replay breakpoint which was set with @replay-break.
+# The command is ignored when there are no replay breakpoints.
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-delete-break" }
+#
+##
+{ 'command': 'replay-delete-break' }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index 51f1c4d82d..a94685e437 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -16,6 +16,8 @@
 #include "hmp.h"
 #include "monitor/monitor.h"
 #include "qapi/qapi-commands-replay.h"
+#include "qapi/qmp/qdict.h"
+#include "qemu/timer.h"
 
 void hmp_info_replay(Monitor *mon, const QDict *qdict)
 {
@@ -41,3 +43,87 @@ ReplayInfo *qmp_query_replay(Error **errp)
 retval->icount = replay_get_current_step();
 return retval;
 }
+
+static void replay_break(uint64_t icount, QEMUTimerCB callback, void *opaque)
+{
+assert(replay_mode == REPLAY_MODE_PLAY);
+assert(replay_mutex_locked());
+assert(replay_break_icount >= replay_get_current_step());
+assert

[Qemu-devel] [PATCH v15 13/24] replay: implement replay-seek command

[Pavel Dovgalyuk]

This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
the execution to the specified instruction count.
The command automatically loads nearest snapshot and replays the execution
to find the desired instruction count.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - renamed replay_seek qmp command into replay-seek
   (suggested by Eric Blake)
v7:
 - small fixes related to Markus Armbruster's review
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the description
   (suggested by Markus Armbruster)
v10:
 - updated the descriptions
---
 hmp-commands.hx   |   19 +
 hmp.h |1 
 qapi/replay.json  |   20 ++
 replay/replay-debugging.c |   92 +
 4 files changed, 132 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 1eb07e7bcc..88a2d32110 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1945,6 +1945,25 @@ STEXI
 @findex replay_delete_break
 Remove replay breakpoint which was previously set with replay_break.
 The command is ignored when there are no replay breakpoints.
+ETEXI
+
+{
+.name   = "replay_seek",
+.args_type  = "icount:i",
+.params = "icount",
+.help   = "replay execution to the specified instruction count",
+.cmd= hmp_replay_seek,
+},
+
+STEXI
+@item replay_seek @var{icount}
+@findex replay_seek
+Automatically proceed to the instruction count @var{icount}, when
+replaying the execution. The command automatically loads nearest
+snapshot and replays the execution to find the desired instruction.
+When there is no preceding snapshot or the execution is not replayed,
+then the command fails.
+icount for the reference may be observed with 'info replay' command.
 ETEXI
 
 {
diff --git a/hmp.h b/hmp.h
index c3e7354dd3..c67a911f2e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -153,5 +153,6 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict);
 void hmp_info_replay(Monitor *mon, const QDict *qdict);
 void hmp_replay_break(Monitor *mon, const QDict *qdict);
 void hmp_replay_delete_break(Monitor *mon, const QDict *qdict);
+void hmp_replay_seek(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/replay.json b/qapi/replay.json
index 84c148cc4e..550fb2e6cf 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -99,3 +99,23 @@
 #
 ##
 { 'command': 'replay-delete-break' }
+
+##
+# @replay-seek:
+#
+# Automatically proceed to the instruction count @icount, when
+# replaying the execution. The command automatically loads nearest
+# snapshot and replays the execution to find the desired instruction.
+# When there is no preceding snapshot or the execution is not replayed,
+# then the command fails.
+# icount for the reference may be obtained with @query-replay command.
+#
+# @icount: target instruction count
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-seek", "data": { "icount": 220414 } }
+##
+{ 'command': 'replay-seek', 'data': { 'icount': 'int' } }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index a94685e437..e3821ab1ba 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -18,6 +18,8 @@
 #include "qapi/qapi-commands-replay.h"
 #include "qapi/qmp/qdict.h"
 #include "qemu/timer.h"
+#include "block/snapshot.h"
+#include "migration/snapshot.h"
 
 void hmp_info_replay(Monitor *mon, const QDict *qdict)
 {
@@ -127,3 +129,93 @@ void hmp_replay_delete_break(Monitor *mon, const QDict 
*qdict)
 return;
 }
 }
+
+static char *replay_find_nearest_snapshot(int64_t icount,
+  int64_t *snapshot_icount)
+{
+BlockDriverState *bs;
+QEMUSnapshotInfo *sn_tab;
+QEMUSnapshotInfo *nearest = NULL;
+char *ret = NULL;
+int nb_sns, i;
+AioContext *aio_context;
+
+*snapshot_icount = -1;
+
+bs = bdrv_all_find_vmstate_bs();
+if (!bs) {
+goto fail;
+}
+aio_context = bdrv_get_aio_context(bs);
+
+aio_context_acquire(aio_context);
+nb_sns = bdrv_snapshot_list(bs, &sn_tab);
+aio_context_release(aio_context);
+
+for (i = 0; i < nb_sns; i++) {
+if (bdrv_all_find_snapshot(sn_tab[i].name, &bs) == 0) {
+if (sn_tab[i].icount != -1ULL
+&& sn_tab[i].icount <= icount
+&& (!nearest || nearest->icount < sn_tab[i].icount)) {
+nearest = &sn_tab[i];
+}
+}
+}
+if (nearest) {
+ret = g_strdup(nearest->name);
+*snapshot_icount = nearest->icount;
+}
+g_free(sn_tab);
+
+fail:
+return ret;
+}
+
+static void replay_seek(int64_t icount, QEMUTimerCB callback, Error **errp)
+{
+char *snapshot = NULL;
+int64_t snapshot_icount;
+
+if (replay_mode != REPLAY_MODE_PLAY) {
+error_setg(errp, "replay must be enabled to seek");
+return;
+}
+if (!replay_snapshot) {
+err

[Qemu-devel] [PATCH v15 15/24] replay: flush rr queue before loading the vmstate

[Pavel Dovgalyuk]

Non-empty record/replay queue prevents saving and loading the VM state,
because it includes pending bottom halves and block coroutines.
But when the new VM state is loaded, we don't have to preserve the consistency
of the current state anymore. Therefore this patch just flushes the queue
allowing the coroutines to finish.

Signed-off-by: Pavel Dovgalyuk 
---
 include/sysemu/replay.h  |2 ++
 migration/savevm.c   |6 ++
 replay/replay-internal.h |2 --
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 3fe14b5f57..d7e859d915 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -140,6 +140,8 @@ void replay_disable_events(void);
 void replay_enable_events(void);
 /*! Returns true when saving events is enabled */
 bool replay_events_enabled(void);
+/* Flushes events queue */
+void replay_flush_events(void);
 /*! Adds bottom half event to the queue */
 void replay_bh_schedule_event(QEMUBH *bh);
 /*! Adds input event to the queue */
diff --git a/migration/savevm.c b/migration/savevm.c
index 468a5a6c90..6a0ebacfed 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2788,6 +2788,12 @@ int load_snapshot(const char *name, Error **errp)
 return -EINVAL;
 }
 
+/*
+ * Flush the record/replay queue. Now the VM state is going
+ * to change. Therefore we don't need to preserve its consistency
+ */
+replay_flush_events();
+
 /* Flush all IO requests so they don't interfere with the new state.  */
 bdrv_drain_all_begin();
 
diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index 8c15a41350..945802361b 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -146,8 +146,6 @@ void replay_read_next_clock(unsigned int kind);
 void replay_init_events(void);
 /*! Clears internal data structures for events handling */
 void replay_finish_events(void);
-/*! Flushes events queue */
-void replay_flush_events(void);
 /*! Returns true if there are any unsaved events in the queue */
 bool replay_has_events(void);
 /*! Saves events from queue into the file */

[Qemu-devel] [PATCH v15 01/24] replay: add missing fix for internal function

[Pavel Dovgalyuk]

From: pbonz...@redhat.com 

This is a fix which was missed by patch
74c0b816adfc6aa1b01b4426fdf385e32e35cbac, which added current_step
parameter to the replay_advance_current_step function.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay-internal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/replay/replay-internal.c b/replay/replay-internal.c
index 8f87e9b957..7e6de03182 100644
--- a/replay/replay-internal.c
+++ b/replay/replay-internal.c
@@ -229,7 +229,7 @@ void replay_mutex_unlock(void)
 
 void replay_advance_current_step(uint64_t current_step)
 {
-int diff = (int)(replay_get_current_step() - replay_state.current_step);
+int diff = (int)(current_step - replay_state.current_step);
 
 /* Time can only go forward */
 assert(diff >= 0);

[Qemu-devel] [PATCH v15 09/24] replay: provide an accessor for rr filename

[Pavel Dovgalyuk]

This patch adds an accessor function for the name of the record/replay
log file. Adding an accessor instead of making variable global,
prevents accidental modification of this variable by other modules.

Signed-off-by: Pavel Dovgalyuk 
---
 include/sysemu/replay.h |2 ++
 replay/replay.c |5 +
 2 files changed, 7 insertions(+)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 3a7c58e423..b3f593f2f0 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -71,6 +71,8 @@ void replay_start(void);
 void replay_finish(void);
 /*! Adds replay blocker with the specified error description */
 void replay_add_blocker(Error *reason);
+/* Returns name of the replay log file */
+const char *replay_get_filename(void);
 
 /* Processing the instructions */
 
diff --git a/replay/replay.c b/replay/replay.c
index b75820a1c1..aa534116b5 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -394,3 +394,8 @@ void replay_add_blocker(Error *reason)
 {
 replay_blockers = g_slist_prepend(replay_blockers, reason);
 }
+
+const char *replay_get_filename(void)
+{
+return replay_filename;
+}

[Qemu-devel] [PATCH v15 07/24] qcow2: introduce icount field for snapshots

[Pavel Dovgalyuk]

This patch introduces the icount field for saving within the snapshot.
It is required for navigation between the snapshots in record/replay mode.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 

--

v2:
 - documented format changes in docs/interop/qcow2.txt
   (suggested by Eric Blake)
v10:
 - updated the documentation
---
 block/qcow2-snapshot.c |7 +++
 block/qcow2.h  |2 ++
 docs/interop/qcow2.txt |4 
 3 files changed, 13 insertions(+)

diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index a6ffae89a6..52b535425a 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -103,6 +103,12 @@ int qcow2_read_snapshots(BlockDriverState *bs)
 sn->disk_size = bs->total_sectors * BDRV_SECTOR_SIZE;
 }
 
+if (extra_data_size >= 24) {
+sn->icount = be64_to_cpu(extra.icount);
+} else {
+sn->icount = -1ULL;
+}
+
 /* Read snapshot ID */
 sn->id_str = g_malloc(id_str_size + 1);
 ret = bdrv_pread(bs->file, offset, sn->id_str, id_str_size);
@@ -209,6 +215,7 @@ static int qcow2_write_snapshots(BlockDriverState *bs)
 memset(&extra, 0, sizeof(extra));
 extra.vm_state_size_large = cpu_to_be64(sn->vm_state_size);
 extra.disk_size = cpu_to_be64(sn->disk_size);
+extra.icount = cpu_to_be64(sn->icount);
 
 id_str_size = strlen(sn->id_str);
 name_size = strlen(sn->name);
diff --git a/block/qcow2.h b/block/qcow2.h
index fdee297f33..7838dcbcea 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -160,6 +160,7 @@ typedef struct QEMU_PACKED QCowSnapshotHeader {
 typedef struct QEMU_PACKED QCowSnapshotExtraData {
 uint64_t vm_state_size_large;
 uint64_t disk_size;
+uint64_t icount;
 } QCowSnapshotExtraData;
 
 
@@ -173,6 +174,7 @@ typedef struct QCowSnapshot {
 uint32_t date_sec;
 uint32_t date_nsec;
 uint64_t vm_clock_nsec;
+uint64_t icount;
 } QCowSnapshot;
 
 struct Qcow2Cache;
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index af5711e533..aa9d447cda 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -584,6 +584,10 @@ Snapshot table entry:
 
 Byte 48 - 55:   Virtual disk size of the snapshot in bytes
 
+Byte 56 - 63:   icount value which corresponds to
+the record/replay instruction count
+when the snapshot was taken
+
 Version 3 images must include extra data at least up to
 byte 55.
 

[Qemu-devel] [PATCH v15 14/24] replay: refine replay-time module

[Pavel Dovgalyuk]

This patch removes refactoring artifacts from the replay/replay-time.c

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay-time.c |   36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/replay/replay-time.c b/replay/replay-time.c
index 0df1693337..60f47b73a7 100644
--- a/replay/replay-time.c
+++ b/replay/replay-time.c
@@ -15,18 +15,19 @@
 #include "replay-internal.h"
 #include "qemu/error-report.h"
 
-int64_t replay_save_clock(ReplayClockKind kind, int64_t clock, int64_t 
raw_icount)
+int64_t replay_save_clock(ReplayClockKind kind, int64_t clock,
+  int64_t raw_icount)
 {
-if (replay_file) {
-g_assert(replay_mutex_locked());
+g_assert(replay_file);
+g_assert(replay_mutex_locked());
 
-/* Due to the caller's locking requirements we get the icount from it
- * instead of using replay_save_instructions().
- */
-replay_advance_current_step(raw_icount);
-replay_put_event(EVENT_CLOCK + kind);
-replay_put_qword(clock);
-}
+/*
+ * Due to the caller's locking requirements we get the icount from it
+ * instead of using replay_save_instructions().
+ */
+replay_advance_current_step(raw_icount);
+replay_put_event(EVENT_CLOCK + kind);
+replay_put_qword(clock);
 
 return clock;
 }
@@ -48,20 +49,15 @@ void replay_read_next_clock(ReplayClockKind kind)
 /*! Reads next clock event from the input. */
 int64_t replay_read_clock(ReplayClockKind kind)
 {
+int64_t ret;
 g_assert(replay_file && replay_mutex_locked());
 
 replay_account_executed_instructions();
 
-if (replay_file) {
-int64_t ret;
-if (replay_next_event_is(EVENT_CLOCK + kind)) {
-replay_read_next_clock(kind);
-}
-ret = replay_state.cached_clock[kind];
-
-return ret;
+if (replay_next_event_is(EVENT_CLOCK + kind)) {
+replay_read_next_clock(kind);
 }
+ret = replay_state.cached_clock[kind];
 
-error_report("REPLAY INTERNAL ERROR %d", __LINE__);
-exit(1);
+return ret;
 }

[Qemu-devel] [PATCH v15 03/24] replay: disable default snapshot for record/replay

[Pavel Dovgalyuk]

From: Pavel Dovgalyuk 

This patch disables setting '-snapshot' option on by default
in record/replay mode. This is needed for creating vmstates in record
and replay modes.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 
---
 vl.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index c1d5484e12..ace6230b05 100644
--- a/vl.c
+++ b/vl.c
@@ -1222,7 +1222,7 @@ static void configure_blockdev(BlockdevOptionsQueue 
*bdo_queue,
 qapi_free_BlockdevOptions(bdo->bdo);
 g_free(bdo);
 }
-if (snapshot || replay_mode != REPLAY_MODE_NONE) {
+if (snapshot) {
 qemu_opts_foreach(qemu_find_opts("drive"), drive_enable_snapshot,
   NULL, NULL);
 }
@@ -3179,7 +3179,13 @@ int main(int argc, char **argv, char **envp)
 drive_add(IF_PFLASH, -1, optarg, PFLASH_OPTS);
 break;
 case QEMU_OPTION_snapshot:
-snapshot = 1;
+{
+Error *blocker = NULL;
+snapshot = 1;
+error_setg(&blocker, QERR_REPLAY_NOT_SUPPORTED,
+   "-snapshot");
+replay_add_blocker(blocker);
+}
 break;
 case QEMU_OPTION_numa:
 opts = qemu_opts_parse_noisily(qemu_find_opts("numa"),

[Qemu-devel] [PATCH v15 10/24] qapi: introduce replay.json for record/replay-related stuff

[Pavel Dovgalyuk]

This patch adds replay.json file. It will be
used for adding record/replay-related data structures and commands.

Signed-off-by: Pavel Dovgalyuk 
Reviewed-by: Markus Armbruster 

--

v10:
 - minor changes
v13:
 - rebased to the new QAPI files
---
 MAINTAINERS |1 +
 include/sysemu/replay.h |2 +-
 qapi/Makefile.objs  |2 +-
 qapi/misc.json  |   18 --
 qapi/qapi-schema.json   |1 +
 qapi/replay.json|   26 ++
 6 files changed, 30 insertions(+), 20 deletions(-)
 create mode 100644 qapi/replay.json

diff --git a/MAINTAINERS b/MAINTAINERS
index 0e7baa9aa2..46972af469 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2186,6 +2186,7 @@ F: net/filter-replay.c
 F: include/sysemu/replay.h
 F: docs/replay.txt
 F: stubs/replay.c
+F: qapi/replay.json
 
 IOVA Tree
 M: Peter Xu 
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index b3f593f2f0..3fe14b5f57 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -13,7 +13,7 @@
  */
 
 #include "sysemu.h"
-#include "qapi/qapi-types-misc.h"
+#include "qapi/qapi-types-replay.h"
 #include "qapi/qapi-types-ui.h"
 
 /* replay clock kinds */
diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs
index 729e5185c5..ee77aac9b9 100644
--- a/qapi/Makefile.objs
+++ b/qapi/Makefile.objs
@@ -6,7 +6,7 @@ util-obj-y += qmp-event.o
 util-obj-y += qapi-util.o
 
 QAPI_COMMON_MODULES = audio authz block-core block char common crypto
-QAPI_COMMON_MODULES += introspect job migration misc net rdma rocker
+QAPI_COMMON_MODULES += introspect job migration misc net rdma replay rocker
 QAPI_COMMON_MODULES += run-state sockets tpm trace transaction ui
 QAPI_TARGET_MODULES = target
 QAPI_MODULES = $(QAPI_COMMON_MODULES) $(QAPI_TARGET_MODULES)
diff --git a/qapi/misc.json b/qapi/misc.json
index 8b3ca4fdd3..00cf0e0bba 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -2876,24 +2876,6 @@
 { 'event': 'ACPI_DEVICE_OST',
  'data': { 'info': 'ACPIOSTInfo' } }
 
-##
-# @ReplayMode:
-#
-# Mode of the replay subsystem.
-#
-# @none: normal execution mode. Replay or record are not enabled.
-#
-# @record: record mode. All non-deterministic data is written into the
-#  replay log.
-#
-# @play: replay mode. Non-deterministic data required for system execution
-#is read from the log.
-#
-# Since: 2.5
-##
-{ 'enum': 'ReplayMode',
-  'data': [ 'none', 'record', 'play' ] }
-
 ##
 # @xen-load-devices-state:
 #
diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
index 4bd1223637..3bd5bc1320 100644
--- a/qapi/qapi-schema.json
+++ b/qapi/qapi-schema.json
@@ -97,6 +97,7 @@
 { 'include': 'transaction.json' }
 { 'include': 'trace.json' }
 { 'include': 'introspect.json' }
+{ 'include': 'replay.json' }
 { 'include': 'misc.json' }
 { 'include': 'target.json' }
 { 'include': 'audio.json' }
diff --git a/qapi/replay.json b/qapi/replay.json
new file mode 100644
index 00..9e13551d20
--- /dev/null
+++ b/qapi/replay.json
@@ -0,0 +1,26 @@
+# -*- Mode: Python -*-
+#
+
+##
+# = Record/replay
+##
+
+{ 'include': 'common.json' }
+
+##
+# @ReplayMode:
+#
+# Mode of the replay subsystem.
+#
+# @none: normal execution mode. Replay or record are not enabled.
+#
+# @record: record mode. All non-deterministic data is written into the
+#  replay log.
+#
+# @play: replay mode. Non-deterministic data required for system execution
+#is read from the log.
+#
+# Since: 2.5
+##
+{ 'enum': 'ReplayMode',
+  'data': [ 'none', 'record', 'play' ] }

[Qemu-devel] [PATCH v15 11/24] replay: introduce info hmp/qmp command

[Pavel Dovgalyuk]

This patch introduces 'info replay' monitor command and
corresponding qmp request.
These commands request the current record/replay mode, replay log file
name, and the instruction count (number of recorded/replayed
instructions).  The instruction count can be used with the
replay_seek/replay_break commands added in the next two patches.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Dr. David Alan Gilbert 
Acked-by: Markus Armbruster 

--

v2:
 - renamed info_replay qmp into query-replay (suggested by Eric Blake)
v7:
 - added empty line (suggested by Markus Armbruster)
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the descriptions
   (suggested by Markus Armbruster)
v10:
 - updated descriptions and messages for rr stuff
---
 hmp-commands-info.hx  |   14 ++
 hmp.h |1 +
 qapi/block-core.json  |3 ++-
 qapi/replay.json  |   39 +++
 replay/Makefile.objs  |3 ++-
 replay/replay-debugging.c |   43 +++
 6 files changed, 101 insertions(+), 2 deletions(-)
 create mode 100644 replay/replay-debugging.c

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index c59444c461..0b3b7aff95 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -930,6 +930,20 @@ STEXI
 @item info sev
 @findex info sev
 Show SEV information.
+ETEXI
+
+{
+.name   = "replay",
+.args_type  = "",
+.params = "",
+.help   = "show record/replay information",
+.cmd= hmp_info_replay,
+},
+
+STEXI
+@item info replay
+@findex info replay
+Display the record/replay information: mode and the current icount.
 ETEXI
 
 STEXI
diff --git a/hmp.h b/hmp.h
index 43617f2646..c53e14e917 100644
--- a/hmp.h
+++ b/hmp.h
@@ -150,5 +150,6 @@ void hmp_hotpluggable_cpus(Monitor *mon, const QDict 
*qdict);
 void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
 void hmp_info_sev(Monitor *mon, const QDict *qdict);
+void hmp_info_replay(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/block-core.json b/qapi/block-core.json
index ecaf23bc2e..702807a45b 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -28,7 +28,8 @@
 #
 # @icount: Current instruction count. Appears when execution record/replay
 #  is enabled. Used for "time-traveling" to match the moment
-#  in the recorded execution with the snapshots. (since 4.0)
+#  in the recorded execution with the snapshots. This counter may
+#  be obtained through @query-replay command (since 4.0)
 #
 # Since: 1.3
 #
diff --git a/qapi/replay.json b/qapi/replay.json
index 9e13551d20..4206150544 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -24,3 +24,42 @@
 ##
 { 'enum': 'ReplayMode',
   'data': [ 'none', 'record', 'play' ] }
+
+##
+# @ReplayInfo:
+#
+# Record/replay information.
+#
+# @mode: current mode.
+#
+# @filename: name of the record/replay log file.
+#It is present only in record or replay modes, when the log
+#is recorded or replayed.
+#
+# @icount: current number of executed instructions.
+#
+# Since: 4.0
+#
+##
+{ 'struct': 'ReplayInfo',
+  'data': { 'mode': 'ReplayMode', '*filename': 'str', 'icount': 'int' } }
+
+##
+# @query-replay:
+#
+# Retrieve the record/replay information.
+# It includes current instruction count which may be used for
+# @replay-break and @replay-seek commands.
+#
+# Returns: record/replay information.
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "query-replay" }
+# <- { "return": { "mode": "play", "filename": "log.rr", "icount": 220414 } }
+#
+##
+{ 'command': 'query-replay',
+  'returns': 'ReplayInfo' }
diff --git a/replay/Makefile.objs b/replay/Makefile.objs
index cee6539a23..6694e3e2a2 100644
--- a/replay/Makefile.objs
+++ b/replay/Makefile.objs
@@ -6,4 +6,5 @@ common-obj-y += replay-input.o
 common-obj-y += replay-char.o
 common-obj-y += replay-snapshot.o
 common-obj-y += replay-net.o
-common-obj-y += replay-audio.o
\ No newline at end of file
+common-obj-y += replay-audio.o
+common-obj-y += replay-debugging.o
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
new file mode 100644
index 00..51f1c4d82d
--- /dev/null
+++ b/replay/replay-debugging.c
@@ -0,0 +1,43 @@
+/*
+ * replay-debugging.c
+ *
+ * Copyright (c) 2010-2018 Institute for System Programming
+ * of the Russian Academy of Sciences.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "sysemu/replay.h"
+#include "replay-internal.h"
+#include "hmp.h"
+#include "monitor/monitor.h"
+#include "qapi/qapi-commands-replay.h"
+
+void hmp_info_replay(Monitor *mon, const QDict *qdict)
+{
+if (replay_mod

[Qemu-devel] [PATCH v15 08/24] migration: introduce icount field for snapshots

[Pavel Dovgalyuk]

Saving icount as a parameters of the snapshot allows navigation between
them in the execution replay scenario.
This information can be used for finding a specific snapshot for proceeding
the recorded execution to the specific moment of the time.
E.g., 'reverse step' action (introduced in one of the following patches)
needs to load the nearest snapshot which is prior to the current moment
of time .

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - made icount in SnapshotInfo optional (suggested by Eric Blake)
v7:
 - added more comments for icount member (suggested by Markus Armbruster)
v9:
 - updated icount comment
v10:
 - updated icount comment again
---
 block/qapi.c |   18 ++
 block/qcow2-snapshot.c   |2 ++
 blockdev.c   |   10 ++
 include/block/snapshot.h |1 +
 migration/savevm.c   |5 +
 qapi/block-core.json |7 ++-
 qapi/block.json  |3 ++-
 7 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index 21edab34fc..d2cdd99946 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -212,6 +212,8 @@ int bdrv_query_snapshot_info_list(BlockDriverState *bs,
 info->date_nsec = sn_tab[i].date_nsec;
 info->vm_clock_sec  = sn_tab[i].vm_clock_nsec / 10;
 info->vm_clock_nsec = sn_tab[i].vm_clock_nsec % 10;
+info->icount= sn_tab[i].icount;
+info->has_icount= sn_tab[i].icount != -1ULL;
 
 info_list = g_new0(SnapshotInfoList, 1);
 info_list->value = info;
@@ -664,14 +666,15 @@ void bdrv_snapshot_dump(fprintf_function func_fprintf, 
void *f,
 QEMUSnapshotInfo *sn)
 {
 char buf1[128], date_buf[128], clock_buf[128];
+char icount_buf[128] = {0};
 struct tm tm;
 time_t ti;
 int64_t secs;
 
 if (!sn) {
 func_fprintf(f,
- "%-10s%-20s%7s%20s%15s",
- "ID", "TAG", "VM SIZE", "DATE", "VM CLOCK");
+ "%-10s%-18s%7s%20s%13s%11s",
+ "ID", "TAG", "VM SIZE", "DATE", "VM CLOCK", "ICOUNT");
 } else {
 ti = sn->date_sec;
 localtime_r(&ti, &tm);
@@ -684,13 +687,18 @@ void bdrv_snapshot_dump(fprintf_function func_fprintf, 
void *f,
  (int)((secs / 60) % 60),
  (int)(secs % 60),
  (int)((sn->vm_clock_nsec / 100) % 1000));
+if (sn->icount != -1ULL) {
+snprintf(icount_buf, sizeof(icount_buf),
+"%"PRId64, sn->icount);
+}
 func_fprintf(f,
- "%-10s%-20s%7s%20s%15s",
+ "%-10s%-18s%7s%20s%13s%11s",
  sn->id_str, sn->name,
  get_human_readable_size(buf1, sizeof(buf1),
  sn->vm_state_size),
  date_buf,
- clock_buf);
+ clock_buf,
+ icount_buf);
 }
 }
 
@@ -858,6 +866,8 @@ void bdrv_image_info_dump(fprintf_function func_fprintf, 
void *f,
 .date_nsec = elem->value->date_nsec,
 .vm_clock_nsec = elem->value->vm_clock_sec * 10ULL +
  elem->value->vm_clock_nsec,
+.icount = elem->value->has_icount ?
+  elem->value->icount : -1ULL,
 };
 
 pstrcpy(sn.id_str, sizeof(sn.id_str), elem->value->id);
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 52b535425a..e358a7581c 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -378,6 +378,7 @@ int qcow2_snapshot_create(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info)
 sn->date_sec = sn_info->date_sec;
 sn->date_nsec = sn_info->date_nsec;
 sn->vm_clock_nsec = sn_info->vm_clock_nsec;
+sn->icount = sn_info->icount;
 
 /* Allocate the L1 table of the snapshot and copy the current one there. */
 l1_table_offset = qcow2_alloc_clusters(bs, s->l1_size * sizeof(uint64_t));
@@ -709,6 +710,7 @@ int qcow2_snapshot_list(BlockDriverState *bs, 
QEMUSnapshotInfo **psn_tab)
 sn_info->date_sec = sn->date_sec;
 sn_info->date_nsec = sn->date_nsec;
 sn_info->vm_clock_nsec = sn->vm_clock_nsec;
+sn_info->icount = sn->icount;
 }
 *psn_tab = sn_tab;
 return s->nb_snapshots;
diff --git a/blockdev.c b/blockdev.c
index 53df2eb875..183fd3f7f6 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -57,6 +57,7 @@
 #include "block/trace.h"
 #include "sysemu/arch_init.h"
 #include "sysemu/qtest.h"
+#include "sysemu/replay.h"
 #include "qemu/cutils.h"
 #include "qemu/help_option.h"
 #include "qemu/throttle-options.h"
@@ -1241,6 +1242,10 @@ SnapshotInfo 
*qmp_blockdev_snapshot_delete_internal_sync(const char *device,
 info->vm_state_size = sn.vm_state_size;
 info->vm_clock_nsec = sn.vm_clock_nsec % 10;
 info->vm_clock_sec = 

[Qemu-devel] [PATCH v15 02/24] block: implement bdrv_snapshot_goto for blkreplay

[Pavel Dovgalyuk]

From: Pavel Dovgalyuk 

This patch enables making snapshots with blkreplay used in
block devices.
This function is required to make bdrv_snapshot_goto without
calling .bdrv_open which is not implemented.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 
---
 block/blkreplay.c |8 
 1 file changed, 8 insertions(+)

diff --git a/block/blkreplay.c b/block/blkreplay.c
index b5d9efdeca..142dfe3157 100644
--- a/block/blkreplay.c
+++ b/block/blkreplay.c
@@ -126,6 +126,12 @@ static int coroutine_fn 
blkreplay_co_flush(BlockDriverState *bs)
 return ret;
 }
 
+static int blkreplay_snapshot_goto(BlockDriverState *bs,
+   const char *snapshot_id)
+{
+return bdrv_snapshot_goto(bs->file->bs, snapshot_id, NULL);
+}
+
 static BlockDriver bdrv_blkreplay = {
 .format_name= "blkreplay",
 .instance_size  = 0,
@@ -140,6 +146,8 @@ static BlockDriver bdrv_blkreplay = {
 .bdrv_co_pwrite_zeroes  = blkreplay_co_pwrite_zeroes,
 .bdrv_co_pdiscard   = blkreplay_co_pdiscard,
 .bdrv_co_flush  = blkreplay_co_flush,
+
+.bdrv_snapshot_goto = blkreplay_snapshot_goto,
 };
 
 static void bdrv_blkreplay_init(void)

Re: [Qemu-devel] [PATCH] docs: reST-ify vhost-user documentation

[Jens Freimann]

On Fri, Mar 15, 2019 at 07:07:35PM +0100, Marc-André Lureau wrote:

Signed-off-by: Marc-André Lureau 
---
MAINTAINERS |2 +-
docs/interop/index.rst  |2 +-
docs/interop/vhost-user.rst | 1351 +++
docs/interop/vhost-user.txt | 1219 ---
4 files changed, 1353 insertions(+), 1221 deletions(-)
create mode 100644 docs/interop/vhost-user.rst
delete mode 100644 docs/interop/vhost-user.txt



Reviewed-by: Jens Freimann 

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Andrea Bolognani]

On Mon, 2019-03-18 at 09:39 +0100, Paolo Bonzini wrote:
> On 15/03/19 21:05, Alistair Francis wrote:
> > Set msi_nonbroken as true for the PLIC.
> > 
> > According to the comment located here:
> > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> > the msi_nonbroken variable should be set to true even if they don't
> > support MSI. In this case that is what we are doing as we don't support
> > MSI.
> > 
> > Signed-off-by: Alistair Francis 
> > Reported-by: Andrea Bolognani 
> > Reported-by: David Abdurachmanov 
> > ---
> > This should allow working pcie-root-ports in QEMU and allow libvirt
> > to start using PCIe by default for RISC-V guests.
> > 
> > hw/riscv/sifive_plic.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> > index d12ec3fc9a..4b0537c912 100644
> > --- a/hw/riscv/sifive_plic.c
> > +++ b/hw/riscv/sifive_plic.c
> > @@ -22,6 +22,7 @@
> >  #include "qemu/log.h"
> >  #include "qemu/error-report.h"
> >  #include "hw/sysbus.h"
> > +#include "hw/pci/msi.h"
> >  #include "target/riscv/cpu.h"
> >  #include "hw/riscv/sifive_plic.h"
> >  
> > @@ -443,6 +444,8 @@ static void sifive_plic_realize(DeviceState *dev, Error 
> > **errp)
> >  plic->enable = g_new0(uint32_t, plic->bitfield_words * 
> > plic->num_addrs);
> >  sysbus_init_mmio(SYS_BUS_DEVICE(dev), &plic->mmio);
> >  qdev_init_gpio_in(dev, sifive_plic_irq_request, plic->num_sources);
> > +
> > +msi_nonbroken = true;
> >  }
> >  
> >  static void sifive_plic_class_init(ObjectClass *klass, void *data)
> 
> I can queue this patch, and add the "select MSI" to CONFIG_SIFIVE.

The interrupt controller is used by the virt machine type too IIUC,
so the same should be added to CONFIG_RISCV_VIRT I think.

-- 
Andrea Bolognani / Red Hat / Virtualization

[Qemu-devel] [PATCH v15 06/24] replay: finish record/replay before closing the disks

[Pavel Dovgalyuk]

After recent updates block devices cannot be closed on qemu exit.
This happens due to the block request polling when replay is not finished.
Therefore now we stop execution recording before closing the block devices.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay.c |2 ++
 vl.c|1 +
 2 files changed, 3 insertions(+)

diff --git a/replay/replay.c b/replay/replay.c
index 8b172b2d1b..b75820a1c1 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -385,6 +385,8 @@ void replay_finish(void)
 g_free(replay_snapshot);
 replay_snapshot = NULL;
 
+replay_mode = REPLAY_MODE_NONE;
+
 replay_finish_events();
 }
 
diff --git a/vl.c b/vl.c
index ace6230b05..cb79be41ce 100644
--- a/vl.c
+++ b/vl.c
@@ -4603,6 +4603,7 @@ int main(int argc, char **argv, char **envp)
 
 /* No more vcpu or device emulation activity beyond this point */
 vm_shutdown();
+replay_finish();
 
 job_cancel_sync_all();
 bdrv_close_all();

Re: [Qemu-devel] [PATCH] hw/s390x: fix clang compilation on 32bit machines

[Christian Borntraeger]

On 16.03.19 12:09, Philippe Mathieu-Daudé wrote:
> Hi Marcel,
> 
> On 3/16/19 10:50 AM, Marcel Apfelbaum wrote:
>> Configuring QEMU with:
>> configure --cc=clang --target-list=s390x-softmmu
>> And compiling it using a 32 bit machine leads to:
> 
> Because there sizeof(ram_addr_t) = sizeof(uintptr_t) = 32.
> 
>> hw/s390x/s390-virtio-ccw.c:175:27: error: implicit conversion from
>>   'unsigned long long' to 'ram_addr_t' (aka 'unsigned int') changes value
>>   from 8796091973632 to 4293918720 [-Werror,-Wconstant-conversion]
>> chunk = MIN(size, KVM_SLOT_MAX_BYTES);
>>   ~ ~~^~~
> 
> The comment 1 line earlier is:
> 
> /* KVM does not allow memslots >= 8 TB */
> 
> Clang is correct, this KVM_SLOT_MAX_BYTES is incorrect on a 32bit s390,
> you need a 64bit system.

KVM is only supported on 64bit s390.
 



> Per Hacking:
> 
>   Use hwaddr for guest physical addresses except pcibus_t
>   for PCI addresses.  In addition, ram_addr_t is a QEMU internal address
>   space that maps guest RAM physical addresses into an intermediate
>   address space that can map to host virtual address spaces.  Generally
>   speaking, the size of guest memory can always fit into ram_addr_t but
>   it would not be correct to store an actual guest physical address in a
>   ram_addr_t.
> 
> My understanding is we should not use ram_addr_t with KVM but rather
> hwaddr, but I'm not sure.
> 
> I don't know about s390, if 32bit host is supported or supports KVM.
> If it is, maybe this could work:
> 
> I don't think the following is clean:
> 
> #if TARGET_LONG_BITS == 32
> # define KVM_SLOT_MAX_BYTES RAM_ADDR_MAX
> #else
> # define KVM_SLOT_MAX_BYTES \
>  ((KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE) & SEG_MSK)
> #endif
> 
> But checking ifdef CONFIG_KVM might be clever:
> 
> -- >8 --
> @@ -161,7 +161,7 @@ static void virtio_ccw_register_hcalls(void)
>  static void s390_memory_init(ram_addr_t mem_size)
>  {
>  MemoryRegion *sysmem = get_system_memory();
> -ram_addr_t chunk, offset = 0;
> +hwaddr offset = 0;
>  unsigned int number = 0;
>  gchar *name;
> 
> @@ -169,14 +169,16 @@ static void s390_memory_init(ram_addr_t mem_size)
>  name = g_strdup_printf("s390.ram");
>  while (mem_size) {
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
> -uint64_t size = mem_size;
> +uint64_t chunk_size = mem_size;
> 
> +#ifdef CONFIG_KVM
>  /* KVM does not allow memslots >= 8 TB */
> -chunk = MIN(size, KVM_SLOT_MAX_BYTES);
> -memory_region_allocate_system_memory(ram, NULL, name, chunk);
> +chunk_size = MIN(mem_size, KVM_SLOT_MAX_BYTES);
> +#endif
> +memory_region_allocate_system_memory(ram, NULL, name, chunk_size);
>  memory_region_add_subregion(sysmem, offset, ram);
> -mem_size -= chunk;
> -offset += chunk;
> +mem_size -= chunk_size;
> +offset += chunk_size;
>  g_free(name);
>  name = g_strdup_printf("s390.ram.%u", ++number);
>  }
> ---
> 
> Anyway s390x experts will figure that out ;)


I will have a look.

[Qemu-devel] [PATCH v15 05/24] replay: don't drain/flush bdrv queue while RR is working

[Pavel Dovgalyuk]

In record/replay mode bdrv queue is controlled by replay mechanism.
It does not allow saving or loading the snapshots
when bdrv queue is not empty. Stopping the VM is not blocked by nonempty
queue, but flushing the queue is still impossible there,
because it may cause deadlocks in replay mode.
This patch disables bdrv_drain_all and bdrv_flush_all in
record/replay mode.

Stopping the machine when the IO requests are not finished is needed
for the debugging. E.g., breakpoint may be set at the specified step,
and forcing the IO requests to finish may break the determinism
of the execution.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 
---
 block/io.c |   28 
 cpus.c |2 --
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index 2ba603c7bc..866fd70d96 100644
--- a/block/io.c
+++ b/block/io.c
@@ -32,6 +32,7 @@
 #include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
+#include "sysemu/replay.h"
 
 #define NOT_DONE 0x7fff /* used while emulated sync operation in progress 
*/
 
@@ -538,6 +539,15 @@ void bdrv_drain_all_begin(void)
 return;
 }
 
+/*
+ * bdrv queue is managed by record/replay,
+ * waiting for finishing the I/O requests may
+ * be infinite
+ */
+if (replay_events_enabled()) {
+return;
+}
+
 /* AIO_WAIT_WHILE() with a NULL context can only be called from the main
  * loop AioContext, so make sure we're in the main context. */
 assert(qemu_get_current_aio_context() == qemu_get_aio_context());
@@ -566,6 +576,15 @@ void bdrv_drain_all_end(void)
 {
 BlockDriverState *bs = NULL;
 
+/*
+ * bdrv queue is managed by record/replay,
+ * waiting for finishing the I/O requests may
+ * be endless
+ */
+if (replay_events_enabled()) {
+return;
+}
+
 while ((bs = bdrv_next_all_states(bs))) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 
@@ -1960,6 +1979,15 @@ int bdrv_flush_all(void)
 BlockDriverState *bs = NULL;
 int result = 0;
 
+/*
+ * bdrv queue is managed by record/replay,
+ * creating new flush request for stopping
+ * the VM may break the determinism
+ */
+if (replay_events_enabled()) {
+return result;
+}
+
 for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 int ret;
diff --git a/cpus.c b/cpus.c
index e83f72b48b..5ff61fbf53 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1078,7 +1078,6 @@ static int do_vm_stop(RunState state, bool send_stop)
 }
 
 bdrv_drain_all();
-replay_disable_events();
 ret = bdrv_flush_all();
 
 return ret;
@@ -2150,7 +2149,6 @@ int vm_prepare_start(void)
 /* We are sending this now, but the CPUs will be resumed shortly later */
 qapi_event_send_resume();
 
-replay_enable_events();
 cpu_enable_ticks();
 runstate_set(RUN_STATE_RUNNING);
 vm_state_notify(1, RUN_STATE_RUNNING);

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Peter Maydell]

On Mon, 18 Mar 2019 at 08:59, Markus Armbruster  wrote:
>
> Alistair Francis  writes:
>
> > Set msi_nonbroken as true for the PLIC.
> >
> > According to the comment located here:
> > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> > the msi_nonbroken variable should be set to true even if they don't
> > support MSI. In this case that is what we are doing as we don't support
> > MSI.
> >
> > Signed-off-by: Alistair Francis 
> > Reported-by: Andrea Bolognani 
> > Reported-by: David Abdurachmanov 
> > ---
> > This should allow working pcie-root-ports in QEMU and allow libvirt
> > to start using PCIe by default for RISC-V guests.
>
> Lovely!  If more people reviewed and updated their interrupt controllers
> this way, we'd be in better shape.

Why do we have a flag which each interrupt controller
has to set rather than just making the right thing the
default (and having the one or two interrupt controllers
that need the wrong thing for backwards compatibility reasons
be the ones that have to set the flag) ? This way round makes
it way to easy to add a new interrupt controller with this
bug without noticing it, I think.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Andrea Bolognani]

On Fri, 2019-03-15 at 20:05 +, Alistair Francis wrote:
> Set msi_nonbroken as true for the PLIC.
> 
> According to the comment located here:
> https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> the msi_nonbroken variable should be set to true even if they don't
> support MSI. In this case that is what we are doing as we don't support
> MSI.
> 
> Signed-off-by: Alistair Francis 
> Reported-by: Andrea Bolognani 
> Reported-by: David Abdurachmanov 
> ---
> This should allow working pcie-root-ports in QEMU and allow libvirt
> to start using PCIe by default for RISC-V guests.
> 
> hw/riscv/sifive_plic.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> index d12ec3fc9a..4b0537c912 100644
> --- a/hw/riscv/sifive_plic.c
> +++ b/hw/riscv/sifive_plic.c
> @@ -22,6 +22,7 @@
>  #include "qemu/log.h"
>  #include "qemu/error-report.h"
>  #include "hw/sysbus.h"
> +#include "hw/pci/msi.h"
>  #include "target/riscv/cpu.h"
>  #include "hw/riscv/sifive_plic.h"
>  
> @@ -443,6 +444,8 @@ static void sifive_plic_realize(DeviceState *dev, Error 
> **errp)
>  plic->enable = g_new0(uint32_t, plic->bitfield_words * plic->num_addrs);
>  sysbus_init_mmio(SYS_BUS_DEVICE(dev), &plic->mmio);
>  qdev_init_gpio_in(dev, sifive_plic_irq_request, plic->num_sources);
> +
> +msi_nonbroken = true;
>  }
>  
>  static void sifive_plic_class_init(ObjectClass *klass, void *data)

With this patch applied, I was able to bring up a riscv64/virt guest
with graphics, using PCIe devices only:

  https://imgur.com/a/taN06hE

Tested-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

[Qemu-devel] [PATCH v15 04/24] replay: update docs for record/replay with block devices

[Pavel Dovgalyuk]

This patch updates the description of the command lines for using
record/replay with attached block devices.

Signed-off-by: Pavel Dovgalyuk 
---
 docs/replay.txt |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/docs/replay.txt b/docs/replay.txt
index ee6aee9861..ce97c3f72f 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -27,7 +27,7 @@ Usage of the record/replay:
  * First, record the execution with the following command line:
 qemu-system-i386 \
  -icount shift=7,rr=record,rrfile=replay.bin \
- -drive file=disk.qcow2,if=none,id=img-direct \
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct \
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
  -device ide-hd,drive=img-blkreplay \
  -netdev user,id=net1 -device rtl8139,netdev=net1 \
@@ -35,7 +35,7 @@ Usage of the record/replay:
  * After recording, you can replay it by using another command line:
 qemu-system-i386 \
  -icount shift=7,rr=replay,rrfile=replay.bin \
- -drive file=disk.qcow2,if=none,id=img-direct \
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct \
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
  -device ide-hd,drive=img-blkreplay \
  -netdev user,id=net1 -device rtl8139,netdev=net1 \
@@ -223,7 +223,7 @@ Block devices record/replay module intercepts calls of
 bdrv coroutine functions at the top of block drivers stack.
 To record and replay block operations the drive must be configured
 as following:
- -drive file=disk.qcow2,if=none,id=img-direct
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay
  -device ide-hd,drive=img-blkreplay
 
@@ -252,6 +252,12 @@ This snapshot is created at start of recording and 
restored at start
 of replaying. It also can be loaded while replaying to roll back
 the execution.
 
+'snapshot' flag of the disk image must be removed to save the snapshots
+in the overlay (or original image) instead of using the temporary overlay.
+ -drive file=disk.ovl,if=none,id=img-direct
+ -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay
+ -device ide-hd,drive=img-blkreplay
+
 Use QEMU monitor to create additional snapshots. 'savevm ' command
 created the snapshot and 'loadvm ' restores it. To prevent corruption
 of the original disk image, use overlay files linked to the original images.

[Qemu-devel] [PATCH v15 00/24] Fix record/replay and add reverse debugging

[Pavel Dovgalyuk]

GDB remote protocol supports reverse debugging of the targets.
It includes 'reverse step' and 'reverse continue' operations.
The first one finds the previous step of the execution,
and the second one is intended to stop at the last breakpoint that
would happen when the program is executed normally.

Reverse debugging is possible in the replay mode, when at least
one snapshot was created at the record or replay phase.
QEMU can use these snapshots for travelling back in time with GDB.

Running the execution in replay mode allows using GDB reverse debugging
commands:
 - reverse-stepi (or rsi): Steps one instruction to the past.
   QEMU loads on of the prior snapshots and proceeds to the desired
   instruction forward. When that step is reaches, execution stops.
 - reverse-continue (or rc): Runs execution "backwards".
   QEMU tries to find breakpoint or watchpoint by loaded prior snapshot
   and replaying the execution. Then QEMU loads snapshots again and
   replays to the latest breakpoint. When there are no breakpoints in
   the examined section of the execution, QEMU finds one more snapshot
   and tries again. After the first snapshot is processed, execution
   stops at this snapshot.

The set of patches include the following modifications:
 - gdbstub update for reverse debugging support
 - functions that automatically perform reverse step and reverse
   continue operations
 - hmp/qmp commands for manipulating the replay process
 - improvement of the snapshotting for saving the execution step
   in the snapshot parameters
 - other record/replay fixes

The patches are available in the repository:
https://github.com/ispras/qemu/tree/rr-190315

v15 changes:
 - rebased to the new master
 - removed obsolete rtc patch
 - fixed misprint in the test

v14 changes:
 - rebased to the new master

v13 changes:
 - rebased to make QAPI stuff applicable
 - minor reverse step/reverse continue fix

v12 changes:
 - style fixes

v11 changes:
 - added can_do_io resetting before jumping to the next block in the chain
 - rebase to the latest master

v10 changes:
 - added patch for correct deadline calculation with external timers
 - updated icount-related documentation in json files
   (suggested by Markus Armbruster)
 - fixed replay shutdown
 - renamed some functions and variables to make them consistent with
   the documentation and displayed messages
 - minor changes

v9 changes:
 - moved rr qapi stuff to the separate file (suggested by Markus Armbruster)
 - minor coding style fixes

v8 changes:
 - rebased to the new master
 - added missing fix for prior rr patch
 - updated 'since' version number in json-related patches

v7 changes:
 - rebased to the new master with upstreamed patches from the series
 - several improvements in hmp/qmp commands handling (suggested by Markus 
Armbruster)
 - fixed record/replay with '-rtc base' option enabled
 - added document with virtual hardware requirements

v6 changes:
 - rebased to the new version of master
 - fixed build of linux-user configurations
 - added new clock for slirp and vnc timers

v5 changes:
 - multiple fixes of record/replay bugs appeared after QEMU core update
 - changed reverse debugging to 'since 3.1'

v4 changes:
 - changed 'since 2.13' to 'since 3.0' in json (as suggested by Eric Blake)

v3 changes:
 - Fixed PS/2 bug with save/load vm, which caused failures of the replay.
 - Rebased to the new code base.
 - Minor fixes.

v2 changes:
 - documented reverse debugging
 - fixed start vmstate loading in record mode
 - documented qcow2 changes (as suggested by Eric Blake)
 - made icount SnapshotInfo field optional (as suggested by Eric Blake)
 - renamed qmp commands (as suggested by Eric Blake)
 - minor changes

---

Pavel Dovgalyuk (23):
  block: implement bdrv_snapshot_goto for blkreplay
  replay: disable default snapshot for record/replay
  replay: update docs for record/replay with block devices
  replay: don't drain/flush bdrv queue while RR is working
  replay: finish record/replay before closing the disks
  qcow2: introduce icount field for snapshots
  migration: introduce icount field for snapshots
  replay: provide an accessor for rr filename
  qapi: introduce replay.json for record/replay-related stuff
  replay: introduce info hmp/qmp command
  replay: introduce breakpoint at the specified step
  replay: implement replay-seek command
  replay: refine replay-time module
  replay: flush rr queue before loading the vmstate
  gdbstub: add reverse step support in replay mode
  gdbstub: add reverse continue support in replay mode
  replay: describe reverse debugging in docs/replay.txt
  replay: add BH oneshot event for block layer
  replay: document development rules
  util/qemu-timer: refactor deadline calculation for external timers
  replay: fix replay shutdown
  replay: rename step-related variables and functions
  icount: clean up cpu_can_io before jumping to the next block

pb

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Michael Walle  writes:

> [resend because my mobile client messed up the message and gmail
> rejected it]
>
> Am 2019-03-18 09:15, schrieb Markus Armbruster:
>> Michael Walle  writes:
>>
>>> Am 2019-03-12 18:36, schrieb Markus Armbruster:
 = hw/lm32/lm32_boards.c =
 Michael Walle  (maintainer:LM32)

 = hw/lm32/milkymist.c =
 Michael Walle  (maintainer:milkymist)

>>>
>>> Hi folks,
>>>
>>> I guess it is time to pull the plug. Mainly, because I have no time
>>> for this anymore. I've always worked on this on my spare time and life
>>> changed. And secondly, I guess RISC-V is taking over ;) It has a far
>>> better ecosystem. Also, to my knowledge the only (public) user of LM32
>>> is milkymist and this project is dead for years now..
>>>
>>> So time to say goodbye. It was fun and I've learned a lot -
>>> technically and also how a huge open source project works. Thank you
>>> everyone for that :)
>>
>> Thank *you* for your contribution!
>>
>>> Basically everything still works and there are even TCG test cases
>>> which covers all instructions the processor has. But I doubt it makes
>>> any more sense to keep that architecture. If nobody wants to take over
>>> (I guess that is the case), I'll post my last and final commit to
>>> remove the lm32 architecture shortly..
>>
>> We normally deprecate first, and remove only after a grace period,
>> commonly two releases.  If we deprecate right away (in 4.0), we'd
>> remove
>> in 4.2, which I'd expect in December.  Would that work for you?
>
> Sure, I reached out to some folks who still use lm32. One response is
> still pending. Is it possible to remove the depreciation again if
> someone steps in?

Yes, it is.

When deprecation turns out to be a mistake, we simply revert the
mistake.  Even after removal, patches to bring it back would be
considered if backed by a use case and a maintainer.

That said, I'd recommend against going through a near-death experience
just to find a new maintainer :)

Re: [Qemu-devel] [PATCHv2] curses ui: always initialize all curses_line fields

[Gerd Hoffmann]

On Fri, Mar 15, 2019 at 02:09:32PM +0100, Samuel Thibault wrote:
> cchar_t can contain not only attr and chars fields, but also ext_color.
> Initialize the whole structure to zero instead of enumerating fields.
> 
> Spotted by Coverity: CID 1399711
> 
> Signed-off-by: Samuel Thibault 

Added to UI patch queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[David Abdurachmanov]

On Mon, Mar 18, 2019 at 10:22 AM Andrea Bolognani  wrote:
>
> On Mon, 2019-03-18 at 09:39 +0100, Paolo Bonzini wrote:
> > On 15/03/19 21:05, Alistair Francis wrote:
> > > Set msi_nonbroken as true for the PLIC.
> > >
> > > According to the comment located here:
> > > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> > > the msi_nonbroken variable should be set to true even if they don't
> > > support MSI. In this case that is what we are doing as we don't support
> > > MSI.
> > >
> > > Signed-off-by: Alistair Francis 
> > > Reported-by: Andrea Bolognani 
> > > Reported-by: David Abdurachmanov 
> > > ---
> > > This should allow working pcie-root-ports in QEMU and allow libvirt
> > > to start using PCIe by default for RISC-V guests.
> > >
> > > hw/riscv/sifive_plic.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> > > index d12ec3fc9a..4b0537c912 100644
> > > --- a/hw/riscv/sifive_plic.c
> > > +++ b/hw/riscv/sifive_plic.c
> > > @@ -22,6 +22,7 @@
> > >  #include "qemu/log.h"
> > >  #include "qemu/error-report.h"
> > >  #include "hw/sysbus.h"
> > > +#include "hw/pci/msi.h"
> > >  #include "target/riscv/cpu.h"
> > >  #include "hw/riscv/sifive_plic.h"
> > >
> > > @@ -443,6 +444,8 @@ static void sifive_plic_realize(DeviceState *dev, 
> > > Error **errp)
> > >  plic->enable = g_new0(uint32_t, plic->bitfield_words * 
> > > plic->num_addrs);
> > >  sysbus_init_mmio(SYS_BUS_DEVICE(dev), &plic->mmio);
> > >  qdev_init_gpio_in(dev, sifive_plic_irq_request, plic->num_sources);
> > > +
> > > +msi_nonbroken = true;
> > >  }
> > >
> > >  static void sifive_plic_class_init(ObjectClass *klass, void *data)
> >
> > I can queue this patch, and add the "select MSI" to CONFIG_SIFIVE.
>
> The interrupt controller is used by the virt machine type too IIUC,
> so the same should be added to CONFIG_RISCV_VIRT I think.

CONFIG_SIFIVE is selected by CONFIG_RISCV_VIRT thus we should be good.

>
> --
> Andrea Bolognani / Red Hat / Virtualization
>

Re: [Qemu-devel] Combining synchronous and asynchronous IO

[Kevin Wolf]

Am 17.03.2019 um 06:58 hat Fam Zheng geschrieben:
> > On Mar 15, 2019, at 01:31, Sergio Lopez  wrote:
> > 
> > Hi,
> > 
> > Our current AIO path does a great job at unloading the work from the VM,
> > and combined with IOThreads provides a good performance in most
> > scenarios. But it also comes with its costs, in both a longer execution
> > path and the need of the intervention of the scheduler at various
> > points.
> > 
> > There's one particular workload that suffers from this cost, and that's
> > when you have just 1 or 2 cores on the Guest issuing synchronous
> > requests. This happens to be a pretty common workload for some DBs and,
> > in a general sense, on small VMs.
> > 
> > I did a quick'n'dirty implementation on top of virtio-blk to get some
> > numbers. This comes from a VM with 4 CPUs running on an idle server,
> > with a secondary virtio-blk disk backed by a null_blk device with a
> > simulated latency of 30us.
> > 
> > - Average latency (us)
> > 
> > 
> > || AIO+iothread | SIO+iothread |
> > | 1 job  |  70  |  55  |
> > | 2 jobs |  83  |  82  |
> > | 4 jobs |  90  | 159  |
> > 
> > 
> > In this case the intuition matches the reality, and synchronous IO wins
> > when there's just 1 job issuing the requests, while it loses hard when
> > the are 4.
> > 
> > While my first thought was implementing this as a tunable, turns out we
> > have a hint about the nature of the workload in the number of the
> > requests in the VQ. So I updated the code to use SIO if there's just 1
> > request and AIO otherwise, with these results:
> > 
> > ---
> > || AIO+iothread | SIO+iothread | AIO+SIO+iothread |
> > | 1 job  |  70  |  55  |55|
> > | 2 jobs |  83  |  82  |78|
> > | 4 jobs |  90  | 159  |90|
> > ---
> > 
> > This data makes me think this is something worth pursuing, but I'd like
> > to hear your opinion on it.
> 
> Nice. In many cases coroutines just forward the raw read/write to the
> raw file (no qcow2 LBA translation, backup, throttling, etc. in the
> data path), being able to transparently (and dynamically, since the
> said condition can change any time for any request) bypass block layer
> will be a very interesting idea to explore. The challenge is how not
> to totally break existing features (e.g. live snapshot and
> everything).

Before jumping to conclusions, maybe we should first try to find out
what is the important part that we're bypassing. Is it really the
indirections through the block layer (And if so, which part of them?
Maybe some things can selectively be bypassed.) or is it bypassing the
thread pool or Linux AIO overhead? The latter could easily be
implemented inside file-posix.

Kevin

Re: [Qemu-devel] [PATCH v2] vnc: fix unalignment access in tight_pack24

[Gerd Hoffmann]

On Mon, Mar 18, 2019 at 09:04:42AM +0800, Li Qiang wrote:
> When adding '-fsanitize=undefined' in compiling configuration
> and connect VM with vnc, it reports following error:
> 
> ui/vnc-enc-tight.c:910:13: runtime error: load of
> misaligned address 0x621000466513 for type 'uint32_t',
> which requires 4 byte alignment
> 
> This patch fix this issue.

Added to ui patch queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCHv2] curses ui: add missing iconv_close calls

[Gerd Hoffmann]

On Thu, Mar 14, 2019 at 06:25:24PM +0100, Samuel Thibault wrote:
> The iconv_t are opened but never closed.
> 
> Spotted by Coverity: CID 1399708
> Spotted by Coverity: CID 1399709
> Spotted by Coverity: CID 1399713
> 
> Signed-off-by: Samuel Thibault 
> ---
> 
> Change since previous version: close all iconv_t, not only
> ucs_to_wchar_conv.

Added to UI patch queue.

thanks,
  Gerd

[Qemu-devel] [PATCH] Re-evaluate SVE vector length everytime ADDVL/RDVL is called

[Amir Charif]

In system emulation mode, the kernel may internally use 16-byte vectors.
If this size is saved in the DisasContext before entering a userspace app
that uses higher SVE sizes, the wrong size may be allocated on the stack
resulting in corruption (segfaults in user space).
This fix evaluates the vector size at runtime (as opposed to translation time)
to always allocate the correct size on the stack (when ADDVL is used).

Signed-off-by: Amir Charif 
---
 target/arm/translate-a64.c | 17 +
 target/arm/translate-a64.h |  1 +
 target/arm/translate-sve.c |  7 +--
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 1959046..ef3db4a 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -45,6 +45,9 @@ static TCGv_i64 cpu_pc;
 /* Load/store exclusive handling */
 static TCGv_i64 cpu_exclusive_high;
 
+/* Current value of the zcr_el[1] register */
+static TCGv_i64 cpu_zcr_el1;
+
 static const char *regnames[] = {
 "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
 "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
@@ -103,6 +106,9 @@ void a64_translate_init(void)
 
 cpu_exclusive_high = tcg_global_mem_new_i64(cpu_env,
 offsetof(CPUARMState, exclusive_high), "exclusive_high");
+
+cpu_zcr_el1 = tcg_global_mem_new_i64(cpu_env,
+offsetof(CPUARMState, vfp.zcr_el[1]), "zcr_el1");
 }
 
 static inline int get_a64_user_mem_index(DisasContext *s)
@@ -578,6 +584,17 @@ TCGv_i64 read_cpu_reg_sp(DisasContext *s, int reg, int sf)
 return v;
 }
 
+/* Get a temporary register containing the current vector length
+ */
+TCGv_i64 get_cpu_vec_len(DisasContext *s) {
+TCGv_i64 v = new_tmp_a64(s);
+tcg_gen_mov_i64(v, cpu_zcr_el1);
+tcg_gen_andi_i64(v, v, 0xf);
+tcg_gen_addi_i64(v, v, 1);
+tcg_gen_muli_i64(v, v, 16);
+return v;
+}
+
 /* Return the offset into CPUARMState of a slice (from
  * the least significant end) of FP register Qn (ie
  * Dn, Sn, Hn or Bn).
diff --git a/target/arm/translate-a64.h b/target/arm/translate-a64.h
index 63d958c..fcfbc90 100644
--- a/target/arm/translate-a64.h
+++ b/target/arm/translate-a64.h
@@ -35,6 +35,7 @@ TCGv_i64 cpu_reg(DisasContext *s, int reg);
 TCGv_i64 cpu_reg_sp(DisasContext *s, int reg);
 TCGv_i64 read_cpu_reg(DisasContext *s, int reg, int sf);
 TCGv_i64 read_cpu_reg_sp(DisasContext *s, int reg, int sf);
+TCGv_i64 get_cpu_vec_len(DisasContext *s);
 void write_fp_dreg(DisasContext *s, int reg, TCGv_i64 v);
 TCGv_ptr get_fpstatus_ptr(bool);
 bool logic_imm_decode_wmask(uint64_t *result, unsigned int immn,
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 3a2eb51..d5ad88b 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -945,7 +945,9 @@ static bool trans_ADDVL(DisasContext *s, arg_ADDVL *a)
 {
 TCGv_i64 rd = cpu_reg_sp(s, a->rd);
 TCGv_i64 rn = cpu_reg_sp(s, a->rn);
-tcg_gen_addi_i64(rd, rn, a->imm * vec_full_reg_size(s));
+TCGv_i64 ln = get_cpu_vec_len(s);
+tcg_gen_muli_i64(ln, ln, a->imm);
+tcg_gen_add_i64(rd, rn, ln);
 return true;
 }
 
@@ -960,7 +962,8 @@ static bool trans_ADDPL(DisasContext *s, arg_ADDPL *a)
 static bool trans_RDVL(DisasContext *s, arg_RDVL *a)
 {
 TCGv_i64 reg = cpu_reg(s, a->rd);
-tcg_gen_movi_i64(reg, a->imm * vec_full_reg_size(s));
+TCGv_i64 ln = get_cpu_vec_len(s);
+tcg_gen_muli_i64(reg, ln, a->imm);
 return true;
 }
 
-- 
2.7.4

Re: [Qemu-devel] Set up github repo for pmon sources

[Daniel P . Berrangé]

On Sat, Mar 16, 2019 at 10:39:49PM +0100, BALATON Zoltan wrote:
> On Sat, 16 Mar 2019, Eric Blake wrote:
> > On 3/15/19 9:06 PM, Andrew Randrianasulu wrote:
> > > https://github.com/Randrianasulu/pmon/commits/2014
> > > 
> > > hopefully it will stay this way.
> > > 
> > > Anyone know what license I must pick for this?
> > > 3-clause BSD? 4-clause BSD? (from Copyright file it lists 4 terms)
> > 
> > 4-clause BSD is incompatible with the GPL, and thus cannot be used for
> > qemu.  (2-clause and 3-clause are okay, though).
> 
> To clarify, this is the firmware of the mips_fulong2e board. So it's a
> separate project but would make the board work more like the real hardware.
> We don't use code from this firmware in QEMU itself but including the
> firmware binary would make it simpler to run the board. If we include a
> binary we should probably also provide the source (even if BSD license does
> not require that) for convenience in roms, mirrored from the above git repo
> like for other firmwares. Is it still incompatible for that? What should be
> the preferred way then? Can we put the binary and source on qemu.org
> somewhere and link to it so it's not distributed with QEMU but still easy to
> get?

As this is just a self-contained firmware whose build is completely separate
from the QEMU build, & produces standalone output file not linked / integrated
with QEMU except at runtime, it would not be considered a combined work with
main QEMU codebase. As such the GPL incompatiblity would not come into effect.

As the same time though, BSD-with-advertizing clause is an unpleasant
license, so on general principles I'd be against including it in the
QEMU git repo regardless of the GPL license compatibility point.

This kind of issue would be entirely avoided if all firmwares were
separate from QEMU.

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

Re: [Qemu-devel] [PATCH] hw/s390x: fix clang compilation on 32bit machines

[Marcel Apfelbaum]

Hi Christian,

On 3/18/19 11:27 AM, Christian Borntraeger wrote:


On 16.03.19 12:09, Philippe Mathieu-Daudé wrote:

Hi Marcel,

On 3/16/19 10:50 AM, Marcel Apfelbaum wrote:

Configuring QEMU with:
 configure --cc=clang --target-list=s390x-softmmu
And compiling it using a 32 bit machine leads to:

Because there sizeof(ram_addr_t) = sizeof(uintptr_t) = 32.


 hw/s390x/s390-virtio-ccw.c:175:27: error: implicit conversion from
   'unsigned long long' to 'ram_addr_t' (aka 'unsigned int') changes value
   from 8796091973632 to 4293918720 [-Werror,-Wconstant-conversion]
 chunk = MIN(size, KVM_SLOT_MAX_BYTES);
   ~ ~~^~~

The comment 1 line earlier is:

 /* KVM does not allow memslots >= 8 TB */

Clang is correct, this KVM_SLOT_MAX_BYTES is incorrect on a 32bit s390,
you need a 64bit system.

KVM is only supported on 64bit s390.
  


So maybe the fix I proposed is enough.





Per Hacking:

   Use hwaddr for guest physical addresses except pcibus_t
   for PCI addresses.  In addition, ram_addr_t is a QEMU internal address
   space that maps guest RAM physical addresses into an intermediate
   address space that can map to host virtual address spaces.  Generally
   speaking, the size of guest memory can always fit into ram_addr_t but
   it would not be correct to store an actual guest physical address in a
   ram_addr_t.

My understanding is we should not use ram_addr_t with KVM but rather
hwaddr, but I'm not sure.

I don't know about s390, if 32bit host is supported or supports KVM.
If it is, maybe this could work:

I don't think the following is clean:

#if TARGET_LONG_BITS == 32
# define KVM_SLOT_MAX_BYTES RAM_ADDR_MAX
#else
# define KVM_SLOT_MAX_BYTES \
  ((KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE) & SEG_MSK)
#endif

But checking ifdef CONFIG_KVM might be clever:

-- >8 --
@@ -161,7 +161,7 @@ static void virtio_ccw_register_hcalls(void)
  static void s390_memory_init(ram_addr_t mem_size)
  {
  MemoryRegion *sysmem = get_system_memory();
-ram_addr_t chunk, offset = 0;
+hwaddr offset = 0;
  unsigned int number = 0;
  gchar *name;

@@ -169,14 +169,16 @@ static void s390_memory_init(ram_addr_t mem_size)
  name = g_strdup_printf("s390.ram");
  while (mem_size) {
  MemoryRegion *ram = g_new(MemoryRegion, 1);
-uint64_t size = mem_size;
+uint64_t chunk_size = mem_size;

+#ifdef CONFIG_KVM
  /* KVM does not allow memslots >= 8 TB */
-chunk = MIN(size, KVM_SLOT_MAX_BYTES);
-memory_region_allocate_system_memory(ram, NULL, name, chunk);
+chunk_size = MIN(mem_size, KVM_SLOT_MAX_BYTES);
+#endif
+memory_region_allocate_system_memory(ram, NULL, name, chunk_size);
  memory_region_add_subregion(sysmem, offset, ram);
-mem_size -= chunk;
-offset += chunk;
+mem_size -= chunk_size;
+offset += chunk_size;
  g_free(name);
  name = g_strdup_printf("s390.ram.%u", ++number);
  }
---

Anyway s390x experts will figure that out ;)


I will have a look.



Appreciated, I just need to be able to compile QEMU with clang on a 
32bit machine.

Any fix would do.

Thanks,
Marcel

Re: [Qemu-devel] [PATCH] ati-vga: i2c fix

[BALATON Zoltan]

Hello,

On Mon, 18 Mar 2019, Gerd Hoffmann wrote:

A more correct model would probably be to create two i2c busses for
that, then hook up the ddc to one of them (possibly depending on a
config option).


Isn't it enough to only emulate the DVI port DDC then?


Well, strictly speaking the radion has 4 i2c busses and the most correct
way to emulate them is hooking up 4 busses.  But in practice it probably
doesn't matter much for the guest whenever we don't emulate the unused
busses or whenever we emulate a i2c bus with no devices connected ...


Right, emulating the ports and corresponding DDC as present but no monitor 
connected would be more correct. However we don't emulate the second 
display controller or flat panel and there may be cards without additional 
connectors so guests should cope with those not present. So unless this 
found to cause a problem for some guests I'd keep the code simple for now 
and not emulate empty ports. It's a complex enough device without that.


Does it work with the latest patch for you? I could not make Linux driver 
recognise the card yet so if you have some settings that's needed for this 
you could share those. It may also need changes to vgabios but I'm not 
familiar with that so I hope you can help with that. I've found the r128 X 
driver needs a VBE BIOS function to access DDC as mentioned in the commit 
message.


Regards,
BALATON Zoltan

Re: [Qemu-devel] [PATCH 1/2] tests: refactor file monitor test to make it more understandable

[Marc-André Lureau]

Hi

On Thu, Mar 14, 2019 at 4:26 PM Daniel P. Berrangé  wrote:
>
> The current file monitor unit tests are too clever for their own good
> making it hard to understand the desired output.
>
> Instead of trying to infer the expected events, explicitly list the
> events we expect in the operation sequence.
>
> Instead of dynamically building a matrix of tests, just have one giant
> operation sequence that validates all scenarios in a single test.
>
> Signed-off-by: Daniel P. Berrangé 


Reviewed-by: Marc-André Lureau 

> ---
>  tests/test-util-filemonitor.c | 534 +-
>  1 file changed, 208 insertions(+), 326 deletions(-)
>
> diff --git a/tests/test-util-filemonitor.c b/tests/test-util-filemonitor.c
> index 5d95cea5ee..ea3715a8f4 100644
> --- a/tests/test-util-filemonitor.c
> +++ b/tests/test-util-filemonitor.c
> @@ -26,6 +26,9 @@
>  #include 
>
>  enum {
> +QFILE_MONITOR_TEST_OP_ADD_WATCH,
> +QFILE_MONITOR_TEST_OP_DEL_WATCH,
> +QFILE_MONITOR_TEST_OP_EVENT,
>  QFILE_MONITOR_TEST_OP_CREATE,
>  QFILE_MONITOR_TEST_OP_APPEND,
>  QFILE_MONITOR_TEST_OP_TRUNC,
> @@ -38,20 +41,10 @@ typedef struct {
>  int type;
>  const char *filesrc;
>  const char *filedst;
> +int watchid;
> +int eventid;
>  } QFileMonitorTestOp;
>
> -typedef struct {
> -const char *file;
> -} QFileMonitorTestWatch;
> -
> -typedef struct {
> -gsize nwatches;
> -const QFileMonitorTestWatch *watches;
> -
> -gsize nops;
> -const QFileMonitorTestOp *ops;
> -} QFileMonitorTestPlan;
> -
>  typedef struct {
>  int id;
>  QFileMonitorEvent event;
> @@ -67,6 +60,7 @@ typedef struct {
>  static QemuMutex evlock;
>  static bool evstopping;
>  static bool evrunning;
> +static bool debug;
>
>  /*
>   * Main function for a background thread that is
> @@ -200,9 +194,125 @@ qemu_file_monitor_test_expect(QFileMonitorTestData 
> *data,
>
>
>  static void
> -test_file_monitor_events(const void *opaque)
> +test_file_monitor_events(void)
>  {
> -const QFileMonitorTestPlan *plan = opaque;
> +QFileMonitorTestOp ops[] = {
> +{ .type = QFILE_MONITOR_TEST_OP_ADD_WATCH,
> +  .filesrc = NULL, .watchid = 0 },
> +{ .type = QFILE_MONITOR_TEST_OP_ADD_WATCH,
> +  .filesrc = "one.txt", .watchid = 1 },
> +{ .type = QFILE_MONITOR_TEST_OP_ADD_WATCH,
> +  .filesrc = "two.txt", .watchid = 2 },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_CREATE,
> +  .filesrc = "one.txt", },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "one.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "one.txt", .watchid = 1,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_CREATE,
> +  .filesrc = "two.txt", },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 2,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_CREATE,
> +  .filesrc = "three.txt", },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "three.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_UNLINK,
> +  .filesrc = "three.txt", },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "three.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_DELETED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_RENAME,
> +  .filesrc = "one.txt", .filedst = "two.txt" },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "one.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_DELETED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "one.txt", .watchid = 1,
> +  .eventid = QFILE_MONITOR_EVENT_DELETED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 2,
> +  .eventid = QFILE_MONITOR_EVENT_CREATED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_APPEND,
> +  .filesrc = "two.txt", },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 0,
> +  .eventid = QFILE_MONITOR_EVENT_MODIFIED },
> +{ .type = QFILE_MONITOR_TEST_OP_EVENT,
> +  .filesrc = "two.txt", .watchid = 2,
> +  .eventid = QFILE_MONITOR_EVENT_MODIFIED },
> +
> +
> +{ .type = QFILE_MONITOR_TEST_OP_TOUCH,
> +  .filesrc = "two.txt", },
> +{ .type = QFILE_MON

Re: [Qemu-devel] [PULL] A Single RISC-V Patch for 4.0-rc0

[Peter Maydell]

On Mon, 18 Mar 2019 at 05:28, Palmer Dabbelt  wrote:
>
> The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
> staging (2019-03-17 14:10:52 +)
>
> are available in the Git repository at:
>
>   git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-4.0-rc0
>
> for you to fetch changes up to f330433b3633647b047cfa418c2ca4d18fda69c7:
>
>   target/riscv: Fix manually parsed 16 bit insn (2019-03-17 22:21:32 -0700)
>
> 
> A Single RISC-V Patch for 4.0-rc0
>
> There was a regression introduced by the decodetree conversion that has
> a fairly straight-forward fix.  Since this fixes bugs that everyone has
> hit I'd like to target it for rc0.
>
> 
> Bastian Koppelmann (1):
>   target/riscv: Fix manually parsed 16 bit insn
>
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths

[Peter Maydell]

On Fri, 15 Mar 2019 at 15:49, Bandan Das  wrote:
> usb_mtp_write_metadata() handles the sendobjectinfo phase where the
> initiator sends the metadata associated with the incoming object.
> For a file, the name and the size is sent and once the responder sends
> back OK, the initiator starts the sendobject phase. For a folder,
> the name of the folder is sent with size being 0, and
> no sendobject phase follows.

Thanks for the explanation.

> So, the reason I am sending back the return
> value is because for a folder, I want to send a success or a failure
> based on whether mkdir succeeded but for a file object, I want to return
> success so that the next phase can continue. Is this rewrite better ?
>
>  static void usb_mtp_object_delete(MTPState *s, uint32_t handle,
> @@ -1674,7 +1666,13 @@ static void usb_mtp_write_data(MTPState *s)
>  if (s->dataset.filename) {
>  path = g_strdup_printf("%s/%s", parent->path, 
> s->dataset.filename);
>  if (s->dataset.format == FMT_ASSOCIATION) {
> -d->fd = mkdir(path, mask);
> +if (mkdir(path, mask)) {
> +usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
> + 0, 0, 0, 0);
> +} else {
> +usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
> + 0, 0, 0, 0);
> +}

Presumably one of these should be RES_OK of some kind ?

>  goto free;
>  }

It does seem like a more consistent approach if we can say
"usb_mtp_write_data() will always queue an appropriate result"
rather than having it do that for some use cases and not others,
so I like this suggestion.

thanks
-- PMM

[Qemu-devel] [PULL 4/5] keymaps: use nodeadkeys variant for de and fr

[Gerd Hoffmann]

The reverse keymap code can't handle dead keys.  So use the nodeadkeys
variant of the keyboard layout for the german and french maps.

Signed-off-by: Gerd Hoffmann 
Message-id: 20190315110248.29208-2-kra...@redhat.com
---
 pc-bios/keymaps/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pc-bios/keymaps/Makefile b/pc-bios/keymaps/Makefile
index f0e44fd110c3..76217b068961 100644
--- a/pc-bios/keymaps/Makefile
+++ b/pc-bios/keymaps/Makefile
@@ -9,7 +9,7 @@ ar  : MAP_FLAGS :=  -l ar
 bepo   : MAP_FLAGS :=  -l fr -v dvorak
 cz : MAP_FLAGS :=  -l cz
 da : MAP_FLAGS :=  -l dk
-de : MAP_FLAGS :=  -l de
+de : MAP_FLAGS :=  -l de -v nodeadkeys
 de-ch  : MAP_FLAGS :=  -l ch
 en-us  : MAP_FLAGS :=  -l us
 en-gb  : MAP_FLAGS :=  -l gb
@@ -17,7 +17,7 @@ es: MAP_FLAGS :=  -l es
 et : MAP_FLAGS :=  -l et
 fi : MAP_FLAGS :=  -l fi
 fo : MAP_FLAGS :=  -l fo
-fr : MAP_FLAGS :=  -l fr
+fr : MAP_FLAGS :=  -l fr -v nodeadkeys
 fr-be  : MAP_FLAGS :=  -l be
 fr-ca  : MAP_FLAGS :=  -l ca -v fr
 fr-ch  : MAP_FLAGS :=  -l ch -v fr
-- 
2.18.1

[Qemu-devel] [PULL 3/5] curses ui: add missing iconv_close calls

[Gerd Hoffmann]

From: Samuel Thibault 

The iconv_t are opened but never closed.

Spotted by Coverity: CID 1399708
Spotted by Coverity: CID 1399709
Spotted by Coverity: CID 1399713

Signed-off-by: Samuel Thibault 
Message-Id: <20190314172524.9290-1-samuel.thiba...@ens-lyon.org>
Reviewed-by: Peter Maydell 
Signed-off-by: Gerd Hoffmann 
---
 ui/curses.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ui/curses.c b/ui/curses.c
index 4ef9b9c677ce..cc6d6da68463 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -519,6 +519,7 @@ static void font_setup(void)
 
 wchar_to_ucs_conv = iconv_open("UCS-2", "WCHAR_T");
 if (wchar_to_ucs_conv == (iconv_t) -1) {
+iconv_close(ucs_to_wchar_conv);
 fprintf(stderr, "Could not convert font glyphs to UCS-2: '%s'\n",
 strerror(errno));
 exit(1);
@@ -526,6 +527,8 @@ static void font_setup(void)
 
 font_conv = iconv_open("WCHAR_T", font_charset);
 if (font_conv == (iconv_t) -1) {
+iconv_close(ucs_to_wchar_conv);
+iconv_close(wchar_to_ucs_conv);
 fprintf(stderr, "Could not convert font glyphs from %s: '%s'\n",
 font_charset, strerror(errno));
 exit(1);
@@ -646,6 +649,9 @@ static void font_setup(void)
 }
 }
 }
+iconv_close(ucs_to_wchar_conv);
+iconv_close(wchar_to_ucs_conv);
+iconv_close(font_conv);
 }
 
 static void curses_setup(void)
-- 
2.18.1

[Qemu-devel] [PULL 2/5] curses ui: always initialize all curses_line fields

[Gerd Hoffmann]

From: Samuel Thibault 

cchar_t can contain not only attr and chars fields, but also ext_color.
Initialize the whole structure to zero instead of enumerating fields.

Spotted by Coverity: CID 1399711

Signed-off-by: Samuel Thibault 
Message-Id: <20190315130932.26094-1-samuel.thiba...@ens-lyon.org>
Reviewed-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Gerd Hoffmann 
---
 ui/curses.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ui/curses.c b/ui/curses.c
index 3a7e8649f3de..4ef9b9c677ce 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -75,9 +75,9 @@ static void curses_update(DisplayChangeListener *dcl,
 if (vga_to_curses[ch].chars[0]) {
 curses_line[x] = vga_to_curses[ch];
 } else {
-curses_line[x].chars[0] = ch;
-curses_line[x].chars[1] = 0;
-curses_line[x].attr = 0;
+curses_line[x] = (cchar_t) {
+.chars[0] = ch,
+};
 }
 curses_line[x].attr |= at;
 }
-- 
2.18.1

[Qemu-devel] [PULL 1/5] vnc: fix unalignment access in tight_pack24

[Gerd Hoffmann]

From: Li Qiang 

When adding '-fsanitize=undefined' in compiling configuration
and connect VM with vnc, it reports following error:

ui/vnc-enc-tight.c:910:13: runtime error: load of
misaligned address 0x621000466513 for type 'uint32_t',
which requires 4 byte alignment

This patch fix this issue.

Signed-off-by: Li Qiang 
Message-id: 20190318010442.14897-1-liq...@163.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc-enc-tight.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 0b4a5ac71f77..d20cd1d86dfe 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -886,11 +886,11 @@ static int tight_compress_data(VncState *vs, int 
stream_id, size_t bytes,
  */
 static void tight_pack24(VncState *vs, uint8_t *buf, size_t count, size_t *ret)
 {
-uint32_t *buf32;
+uint8_t *buf8;
 uint32_t pix;
 int rshift, gshift, bshift;
 
-buf32 = (uint32_t *)buf;
+buf8 = buf;
 
 if (1 /* FIXME */) {
 rshift = vs->client_pf.rshift;
@@ -907,10 +907,11 @@ static void tight_pack24(VncState *vs, uint8_t *buf, 
size_t count, size_t *ret)
 }
 
 while (count--) {
-pix = *buf32++;
+pix = ldl_he_p(buf8);
 *buf++ = (char)(pix >> rshift);
 *buf++ = (char)(pix >> gshift);
 *buf++ = (char)(pix >> bshift);
+buf8 += 4;
 }
 }
 
-- 
2.18.1

[Qemu-devel] [PULL 0/5] Ui 20190318 patches

[Gerd Hoffmann]

The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:

  Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
staging (2019-03-17 14:10:52 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/ui-20190318-pull-request

for you to fetch changes up to 0a87602268884f977ba67df8b51735bf5ac141ec:

  keymaps: regenerate keymaps (2019-03-18 12:06:04 +0100)


ui: fixes for 4.0 (vnc, curses, keymaps).



Gerd Hoffmann (2):
  keymaps: use nodeadkeys variant for de and fr
  keymaps: regenerate keymaps

Li Qiang (1):
  vnc: fix unalignment access in tight_pack24

Samuel Thibault (2):
  curses ui: always initialize all curses_line fields
  curses ui: add missing iconv_close calls

 ui/curses.c  | 12 ++---
 ui/vnc-enc-tight.c   |  7 +++---
 pc-bios/keymaps/Makefile |  4 +--
 pc-bios/keymaps/ar   | 53 
 pc-bios/keymaps/bepo | 10 ++--
 pc-bios/keymaps/cz   | 10 ++--
 pc-bios/keymaps/da   | 10 ++--
 pc-bios/keymaps/de   | 39 +++--
 pc-bios/keymaps/de-ch| 10 ++--
 pc-bios/keymaps/en-gb| 10 ++--
 pc-bios/keymaps/en-us| 10 ++--
 pc-bios/keymaps/es   | 10 ++--
 pc-bios/keymaps/et   | 10 ++--
 pc-bios/keymaps/fi   | 10 ++--
 pc-bios/keymaps/fo   | 10 ++--
 pc-bios/keymaps/fr   | 36 +++
 pc-bios/keymaps/fr-be| 10 ++--
 pc-bios/keymaps/fr-ca| 10 ++--
 pc-bios/keymaps/fr-ch| 10 ++--
 pc-bios/keymaps/hr   | 10 ++--
 pc-bios/keymaps/hu   | 10 ++--
 pc-bios/keymaps/is   | 10 ++--
 pc-bios/keymaps/it   | 10 ++--
 pc-bios/keymaps/ja   | 10 ++--
 pc-bios/keymaps/lt   | 10 ++--
 pc-bios/keymaps/lv   | 10 ++--
 pc-bios/keymaps/mk   | 10 ++--
 pc-bios/keymaps/nl   | 10 ++--
 pc-bios/keymaps/no   | 10 ++--
 pc-bios/keymaps/pl   | 10 ++--
 pc-bios/keymaps/pt   | 10 ++--
 pc-bios/keymaps/pt-br| 10 ++--
 pc-bios/keymaps/ru   | 10 ++--
 pc-bios/keymaps/th   | 10 ++--
 pc-bios/keymaps/tr   | 10 ++--
 35 files changed, 336 insertions(+), 105 deletions(-)

-- 
2.18.1

[Qemu-devel] [PULL 5/5] keymaps: regenerate keymaps

[Gerd Hoffmann]

Pick up the config updates.  Also add a few keys to the maps which
got a QKeyCode assigned since the last time we generated the maps
(Hiragana_Katakana, Muhenkan).  Sync with xkbcommon updates.

Signed-off-by: Gerd Hoffmann 
Message-id: 20190315110248.29208-3-kra...@redhat.com
---
 pc-bios/keymaps/ar| 53 +++
 pc-bios/keymaps/bepo  | 10 ++--
 pc-bios/keymaps/cz| 10 ++--
 pc-bios/keymaps/da| 10 ++--
 pc-bios/keymaps/de| 39 +++
 pc-bios/keymaps/de-ch | 10 ++--
 pc-bios/keymaps/en-gb | 10 ++--
 pc-bios/keymaps/en-us | 10 ++--
 pc-bios/keymaps/es| 10 ++--
 pc-bios/keymaps/et| 10 ++--
 pc-bios/keymaps/fi| 10 ++--
 pc-bios/keymaps/fo| 10 ++--
 pc-bios/keymaps/fr| 36 +
 pc-bios/keymaps/fr-be | 10 ++--
 pc-bios/keymaps/fr-ca | 10 ++--
 pc-bios/keymaps/fr-ch | 10 ++--
 pc-bios/keymaps/hr| 10 ++--
 pc-bios/keymaps/hu| 10 ++--
 pc-bios/keymaps/is| 10 ++--
 pc-bios/keymaps/it| 10 ++--
 pc-bios/keymaps/ja| 10 ++--
 pc-bios/keymaps/lt| 10 ++--
 pc-bios/keymaps/lv| 10 ++--
 pc-bios/keymaps/mk| 10 ++--
 pc-bios/keymaps/nl| 10 ++--
 pc-bios/keymaps/no| 10 ++--
 pc-bios/keymaps/pl| 10 ++--
 pc-bios/keymaps/pt| 10 ++--
 pc-bios/keymaps/pt-br | 10 ++--
 pc-bios/keymaps/ru| 10 ++--
 pc-bios/keymaps/th| 10 ++--
 pc-bios/keymaps/tr| 10 ++--
 32 files changed, 321 insertions(+), 97 deletions(-)

diff --git a/pc-bios/keymaps/ar b/pc-bios/keymaps/ar
index a763c9a02713..f62b297c54f4 100644
--- a/pc-bios/keymaps/ar
+++ b/pc-bios/keymaps/ar
@@ -36,50 +36,65 @@ Escape 0x01
 # evdev 2 (0x2), QKeyCode "1", number 0x2
 1 0x02
 exclam 0x02 shift
+Arabic_1 0x02 altgr
 
 # evdev 3 (0x3), QKeyCode "2", number 0x3
 2 0x03
 at 0x03 shift
+Arabic_2 0x03 altgr
 
 # evdev 4 (0x4), QKeyCode "3", number 0x4
 3 0x04
 numbersign 0x04 shift
+Arabic_3 0x04 altgr
 
 # evdev 5 (0x5), QKeyCode "4", number 0x5
 4 0x05
 dollar 0x05 shift
+Arabic_4 0x05 altgr
 
 # evdev 6 (0x6), QKeyCode "5", number 0x6
 5 0x06
 percent 0x06 shift
+Arabic_5 0x06 altgr
+U2030 0x06 shift altgr
 
 # evdev 7 (0x7), QKeyCode "6", number 0x7
 6 0x07
 asciicircum 0x07 shift
+Arabic_6 0x07 altgr
 
 # evdev 8 (0x8), QKeyCode "7", number 0x8
 7 0x08
 ampersand 0x08 shift
+Arabic_7 0x08 altgr
 
 # evdev 9 (0x9), QKeyCode "8", number 0x9
 8 0x09
 asterisk 0x09 shift
+Arabic_8 0x09 altgr
 
 # evdev 10 (0xa), QKeyCode "9", number 0xa
 9 0x0a
 parenright 0x0a shift
+Arabic_9 0x0a altgr
 
 # evdev 11 (0xb), QKeyCode "0", number 0xb
 0 0x0b
 parenleft 0x0b shift
+Arabic_0 0x0b altgr
 
 # evdev 12 (0xc), QKeyCode "minus", number 0xc
 minus 0x0c
 underscore 0x0c shift
+endash 0x0c altgr
+U2011 0x0c shift altgr
 
 # evdev 13 (0xd), QKeyCode "equal", number 0xd
 equal 0x0d
 plus 0x0d shift
+notequal 0x0d altgr
+approxeq 0x0d shift altgr
 
 # evdev 14 (0xe), QKeyCode "backspace", number 0xe
 BackSpace 0x0e
@@ -91,18 +106,22 @@ ISO_Left_Tab 0x0f shift
 # evdev 16 (0x10), QKeyCode "q", number 0x10
 Arabic_dad 0x10
 Arabic_fatha 0x10 shift
+U2066 0x10 shift altgr
 
 # evdev 17 (0x11), QKeyCode "w", number 0x11
 Arabic_sad 0x11
 Arabic_fathatan 0x11 shift
+U2067 0x11 shift altgr
 
 # evdev 18 (0x12), QKeyCode "e", number 0x12
 Arabic_theh 0x12
 Arabic_damma 0x12 shift
+U2068 0x12 shift altgr
 
 # evdev 19 (0x13), QKeyCode "r", number 0x13
 Arabic_qaf 0x13
 Arabic_dammatan 0x13 shift
+U2069 0x13 shift altgr
 
 # evdev 20 (0x14), QKeyCode "t", number 0x14
 Arabic_feh 0x14
@@ -112,14 +131,17 @@ Arabic_veh 0x14 altgr
 # evdev 21 (0x15), QKeyCode "y", number 0x15
 Arabic_ghain 0x15
 Arabic_hamzaunderalef 0x15 shift
+U202A 0x15 shift altgr
 
 # evdev 22 (0x16), QKeyCode "u", number 0x16
 Arabic_ain 0x16
 grave 0x16 shift
+U202B 0x16 shift altgr
 
 # evdev 23 (0x17), QKeyCode "i", number 0x17
 Arabic_ha 0x17
 division 0x17 shift
+U202C 0x17 shift altgr
 
 # evdev 24 (0x18), QKeyCode "o", number 0x18
 Arabic_khah 0x18
@@ -128,15 +150,18 @@ multiply 0x18 shift
 # evdev 25 (0x19), QKeyCode "p", number 0x19
 Arabic_hah 0x19
 Arabic_semicolon 0x19 shift
+U200E 0x19 shift altgr
 
 # evdev 26 (0x1a), QKeyCode "bracket_left", number 0x1a
 Arabic_jeem 0x1a
 less 0x1a shift
 Arabic_tcheh 0x1a altgr
+U200F 0x1a shift altgr
 
 # evdev 27 (0x1b), QKeyCode "bracket_right", number 0x1b
 Arabic_dal 0x1b
 greater 0x1b shift
+U061C 0x1b shift altgr
 
 # evdev 28 (0x1c), QKeyCode "ret", number 0x1c
 Return 0x1c
@@ -177,6 +202,7 @@ Arabic_tatweel 0x24 shift
 # evdev 37 (0x25), QKeyCode "k", number 0x25
 Arabic_noon 0x25
 Arabic_comma 0x25 shift
+U066B 0x25 altgr
 
 # evdev 38 (0x26), QKeyCode "l", number 0x26
 Arabic_meem 0x26
@@ -190,27 +216,35 @@ Arabic_gaf 0x27 altgr
 # evdev 40 (0x28), QKeyCode "apostrophe", number 0x28
 Arabic_tah 0x28
 quotedbl 0x28 shift
+U27E9 0x28 altgr
+U200D 0x28 shift altgr
 
 # evdev 41 (0x29), QK

[Qemu-devel] [PATCH for-4.0] include/qemu/bswap.h: Use __builtin_memcpy() in accessor functions

[Peter Maydell]

In the accessor functions ld*_he_p() and st*_he_p() we use memcpy()
to perform a load or store to a pointer which might not be aligned
for the size of the type. We rely on the compiler to optimize this
memcpy() into an efficient load or store instruction where possible.
This is required for good performance, but at the moment it is also
required for correct operation, because some users of these functions
require that the access is atomic if the pointer is aligned, which
will only be the case if the compiler has optimized out the memcpy().
(The particular example where we discovered this is the virtio
vring_avail_idx() which calls virtio_lduw_phys_cached() which
eventually ends up calling lduw_he_p().)

Unfortunately some compile environments, such as the fortify-source
setup used in Alpine Linux, define memcpy() to a wrapper function
in a way that inhibits this compiler optimization.

The correct long-term fix here is to add a set of functions for
doing atomic accesses into AddressSpaces (and to other relevant
families of accessor functions like the virtio_*_phys_cached()
ones), and make sure that callsites which want atomic behaviour
use the correct functions.

In the meantime, switch to using __builtin_memcpy() in the
bswap.h accessor functions. This will make us robust against things
like this fortify library in the short term. In the longer term
it will mean that we don't end up with these functions being really
badly-performing even if the semantics of the out-of-line memcpy()
are correct.

Reported-by: Fernando Casas Schössow 
Signed-off-by: Peter Maydell 
---
 include/qemu/bswap.h | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 5a70f78c0ba..2a9f3fe783e 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -316,51 +316,57 @@ static inline void stb_p(void *ptr, uint8_t v)
 *(uint8_t *)ptr = v;
 }
 
-/* Any compiler worth its salt will turn these memcpy into native unaligned
-   operations.  Thus we don't need to play games with packed attributes, or
-   inline byte-by-byte stores.  */
+/*
+ * Any compiler worth its salt will turn these memcpy into native unaligned
+ * operations.  Thus we don't need to play games with packed attributes, or
+ * inline byte-by-byte stores.
+ * Some compilation environments (eg some fortify-source implementations)
+ * may intercept memcpy() in a way that defeats the compiler optimization,
+ * though, so we use __builtin_memcpy() to give ourselves the best chance
+ * of good performance.
+ */
 
 static inline int lduw_he_p(const void *ptr)
 {
 uint16_t r;
-memcpy(&r, ptr, sizeof(r));
+__builtin_memcpy(&r, ptr, sizeof(r));
 return r;
 }
 
 static inline int ldsw_he_p(const void *ptr)
 {
 int16_t r;
-memcpy(&r, ptr, sizeof(r));
+__builtin_memcpy(&r, ptr, sizeof(r));
 return r;
 }
 
 static inline void stw_he_p(void *ptr, uint16_t v)
 {
-memcpy(ptr, &v, sizeof(v));
+__builtin_memcpy(ptr, &v, sizeof(v));
 }
 
 static inline int ldl_he_p(const void *ptr)
 {
 int32_t r;
-memcpy(&r, ptr, sizeof(r));
+__builtin_memcpy(&r, ptr, sizeof(r));
 return r;
 }
 
 static inline void stl_he_p(void *ptr, uint32_t v)
 {
-memcpy(ptr, &v, sizeof(v));
+__builtin_memcpy(ptr, &v, sizeof(v));
 }
 
 static inline uint64_t ldq_he_p(const void *ptr)
 {
 uint64_t r;
-memcpy(&r, ptr, sizeof(r));
+__builtin_memcpy(&r, ptr, sizeof(r));
 return r;
 }
 
 static inline void stq_he_p(void *ptr, uint64_t v)
 {
-memcpy(ptr, &v, sizeof(v));
+__builtin_memcpy(ptr, &v, sizeof(v));
 }
 
 static inline int lduw_le_p(const void *ptr)
-- 
2.20.1

Re: [Qemu-devel] [PATCH 1/2] Fix absolute input device grabbing issues on Mojave

[Peter Maydell]

On Fri, 15 Mar 2019 at 09:37, Chen Zhang  wrote:
>
>
> Signed-off-by: Chen Zhang 

Hi; thanks for this patch. I think a commit message for
the patch would be useful, containing the rationale for
why we make the change. I know you put that in the cover letter,
but that won't get into the git commit history.

If you know under what circumstances the event's window
pointer is NULL, that would also be useful to record.

> ---
>  ui/cocoa.m | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 420b2411c1..5d0a6599d9 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -405,6 +405,24 @@ QemuCocoaView *cocoaView;
>  return (p.x > -1 && p.x < screen.width && p.y > -1 && p.y < 
> screen.height);
>  }
>
> +/* Get location of event and convert to virtual screen coordinate */
> +- (CGPoint) screenLocationOfEvent:(NSEvent *)ev
> +{
> +NSWindow *eventWindow = [ev window];
> +if (!eventWindow) {
> +   return [self.window convertPointFromScreen:[ev locationInWindow]];
> +} else if ([self.window isEqual:eventWindow]) {
> +return [ev locationInWindow];
> +} else {
> +return [self.window convertPointFromScreen:[eventWindow 
> convertPointToScreen:[ev locationInWindow]]];
> +}
> +}
> +
> +- (BOOL) screenContainsPointOfEvent:(NSEvent *)ev
> +{
> +return [self screenContainsPoint:[self screenLocationOfEvent:ev]];
> +}

It looks like we pretty much always call
[self screenLocationOfEvent: event] after we call
[self screenContainsPoint:p], which will do the conversion
all over again. So I think it would be clearer to have
a method which did "return an NSPoint which is the location
of this event in the QEMU display window", and then just
call that where we currently do
 NSPoint p = [event locationInWindow];
Then we wouldn't need to change any of the following code or
the screenContainsPoint calls.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/2] ui/cocoa: fix grabbing issue in fullscreen mode

[Peter Maydell]

On Fri, 15 Mar 2019 at 09:37, Chen Zhang  wrote:
>
> Signed-off-by: Chen Zhang 

Again, it would be nice to see a commit message here
that explained what was being changed and why.

If you take my suggestion from my review of patch 1 this is
no longer relevant, but:

> @@ -881,7 +900,7 @@ QemuCocoaView *cocoaView;
>  break;
>  case NSEventTypeLeftMouseUp:
>  mouse_event = true;
> -if (!isMouseGrabbed && [self screenContainsPoint:p]) {
> +if (!isMouseGrabbed && [self screenContainsPointOfEvent:event]) {
>  if([[self window] isKeyWindow]) {
>  [self grabMouse];
>  }
> @@ -944,7 +963,7 @@ QemuCocoaView *cocoaView;
>  if (isMouseGrabbed) {
>  if (isAbsoluteEnabled) {
>  /* Note that the origin for Cocoa mouse coords is bottom 
> left, not top left.
> - * The check on screenContainsPoint is to avoid sending out 
> of range values for
> + * The check on screenContainsPointOfEvent is to avoid 
> sending out of range values for
>   * clicks in the titlebar.
>   */
>  if ([self screenContainsPointOfEvent:event]) {
> --
> 2.19.2

These two changes really belong in patch 1, not patch 2, don't they?

thanks
-- PMM

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Daniel P . Berrangé]

On Tue, Mar 12, 2019 at 11:50:54AM +0100, Markus Armbruster wrote:
> We have two separate type trees, object types rooted at TYPE_OBJECT, and
> interface types at TYPE_INTERFACE.
> 
> Object types are fore defining ultimately concrete types, i.e. any
> concrete type is a descendant of TYPE_OBJECT.  Interior nodes of the
> TYPE_OBJECT tree are commonly abstract, with a few exceptions.  Leaves
> need to be concrete to be of any use.
> 
> Interface types are for defining interfaces object types provide (by
> listing them in a type's .interfaces).  TYPE_INTERFACE and all its
> descendants are abstract.
> 
> Issue #1: INTERFACE_CLASS()
> 
> #define OBJECT_CLASS(class) \
> ((ObjectClass *)(class))
> 
> #define OBJECT_CLASS_CHECK(class_type, class, name) \
> ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), 
> (name), \
>__FILE__, __LINE__, 
> __func__))
> 
> #define INTERFACE_CLASS(klass) \
> OBJECT_CLASS_CHECK(InterfaceClass, klass, TYPE_INTERFACE)
> 
> Shouldn't INTERFACE_CLASS() be named INTERFACE_CLASS_CHECK() for
> consistency?

I actually wonder why we even need "OBJECT_CLASS" as it exists here
at all.

$ git grep 'OBJECT_CLASS\b' | wc -l
38
$ git grep 'OBJECT_CLASS_CHECK\b' | wc -l
196

There's no obvious pattern in why OBJECT_CLASS is being favoured.
The only compelling benefit of it is that it is faster since it
avoids checking anything.


What if we include sub-classes

  $ git grep '_CLASS('  | grep -v GET_CLASS | wc -l
  1946

It looks like ${FOO}_CLASS is the popular syntax, but this is misleading
as sub-classes don't follow the same convention - they all appear to make
their ${FOO}_CLASS macro call OBJECT_CLASS_CHECK, as this is what object.h
recommands as the pattern :-)

#define MACHINE_CLASS(klass) \
OBJECT_CLASS_CHECK(MachineClass, (klass), TYPE_MACHINE)


IOW, I think we could/should remove OBJECT_CLASS and rename
OBJECT_CLASS_CHECK to OBJECT_CLASS.

If there are some callers that absolutely need the performance
of doing a cast without safety checks, they can just do a
direct cast with normal C syntax - no need for a macro.


> Rename would be trivial, as there are no uses.

Renaming INTERFACE_CLASS becomes redundant if we fix OBJECT_CLASS

> 
> Issue #2: INTERFACE_CHECK()
> 
> #define OBJECT_CHECK(type, obj, name) \
> ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
> __FILE__, __LINE__, __func__))
> 
> #define INTERFACE_CHECK(interface, obj, name) \
> ((interface *)object_dynamic_cast_assert(OBJECT((obj)), (name), \
>  __FILE__, __LINE__, 
> __func__))
> 
> The two are identical (except the former lacks parenthesis around obj,
> which is a minor bug).
> 
> Obvious question: shouldn't we de-duplicate the code?
> 
> There's a more interesting question, however.  Since two two are
> identical, they can be used interchangeably.  And since we can, we do;
> for instance
> 
> #define QAUTHZ(obj) \
>  INTERFACE_CHECK(QAuthZ, (obj), \
>  TYPE_QAUTHZ)
> 
> even though TYPE_QAUTHZ is a sub-type of TYPE_OBJECT, not
> TYPE_INTERFACE.  Shouldn't we prevent that somehow?  Or maybe embrace
> they're the same and just get rid of INTERFACE_CHECK() entirely?

If we wanted to keep INTERFACE_CHECK then I agree we should make it fail
when not given an interface type, but i'm not really convinced it is
worth it. Code is inevitably going to get these mixed up, as this QAUTHZ
example shows. So doing a stronger check will just turn currently working
code into broken code at runtime.

I'd vote for removing INTERFACE_CHECK and using OBJECT_CHECK universally.

> Issue #3: Inconsistent naming (surprise, surprise)
> 
> The confusion between object and interface types is of course aggravated
> by our usual lack of discipline in naming.  I recognize no less than
> three naming conventions:
> 
> INTERFACE_CONVENTIONAL_PCI_DEVICE
> INTERFACE_PCIE_DEVICE

Definitely cull this convention - not having TYPE_ is a gratuitous
diversion from the norm.

> 
> TYPE_ACPI_DEVICE_IF
> TYPE_ARM_LINUX_BOOT_IF
> TYPE_TEST_IF
> TYPE_TPM_IF
> 
> TYPE_IDAU_INTERFACE
> TYPE_IPMI_INTERFACE
> TYPE_PNV_XSCOM_INTERFACE

I'm not so bothered by these, though they are pointless unless
perhaps it is to avoid clash with a similarly named object
type

> 
> Yet they're used for less than half of the interface names:
> 
> TYPE_FW_PATH_PROVIDER
> TYPE_HOTPLUG_HANDLER
> TYPE_INTERRUPT_STATS_PROVIDER
> TYPE_ISADMA
> TYPE_MEMORY_DEVICE
> TYPE_NMI
> TYPE_NVRAM
> TYPE_PPC_VIRTUAL_HYPERVISOR
> TYPE_STREAM_SLAVE
> TYPE_USER_CREATABLE
> TYPE_XICS_FABRIC
> TYPE_XIVE_NOTIFIER
> 
> Can we agree on one naming convention, and enforce it?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/pho

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Peter Maydell]

On Mon, 18 Mar 2019 at 11:54, Daniel P. Berrangé  wrote:
> > TYPE_ACPI_DEVICE_IF
> > TYPE_ARM_LINUX_BOOT_IF
> > TYPE_TEST_IF
> > TYPE_TPM_IF
> >
> > TYPE_IDAU_INTERFACE
> > TYPE_IPMI_INTERFACE
> > TYPE_PNV_XSCOM_INTERFACE
>
> I'm not so bothered by these, though they are pointless unless
> perhaps it is to avoid clash with a similarly named object
> type

For the ones of these that I'm responsible for, I was
partly following an existing example, but I find it useful
as a user of the APIs that it's clear that I'm dealing
with an interface and not an object. For instance if I
see a PROP_LINK that wants a TYPE_IDAU_INTERFACE I know
I need to implement an interface on some suitable object,
whereas if it were a TYPE_IDAU I'd be expecting to need
to create (or write a subclass of) a concrete object.
So I'd prefer us to settle on a convention that does
explicitly mark the interface-ness in the type name.

thanks
-- PMM

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Daniel P . Berrangé]

On Mon, Mar 18, 2019 at 11:59:43AM +, Peter Maydell wrote:
> On Mon, 18 Mar 2019 at 11:54, Daniel P. Berrangé  wrote:
> > > TYPE_ACPI_DEVICE_IF
> > > TYPE_ARM_LINUX_BOOT_IF
> > > TYPE_TEST_IF
> > > TYPE_TPM_IF
> > >
> > > TYPE_IDAU_INTERFACE
> > > TYPE_IPMI_INTERFACE
> > > TYPE_PNV_XSCOM_INTERFACE
> >
> > I'm not so bothered by these, though they are pointless unless
> > perhaps it is to avoid clash with a similarly named object
> > type
> 
> For the ones of these that I'm responsible for, I was
> partly following an existing example, but I find it useful
> as a user of the APIs that it's clear that I'm dealing
> with an interface and not an object. For instance if I
> see a PROP_LINK that wants a TYPE_IDAU_INTERFACE I know
> I need to implement an interface on some suitable object,
> whereas if it were a TYPE_IDAU I'd be expecting to need
> to create (or write a subclass of) a concrete object.
> So I'd prefer us to settle on a convention that does
> explicitly mark the interface-ness in the type name.

If we do want such a naming convention, then I think we'd want to have
checkpatch enforce it. eg in the .c file validate the TypeInfo struct:

static const TypeInfo acpi_dev_if_info = {
.name  = TYPE_ACPI_DEVICE_IF,
.parent= TYPE_INTERFACE,
.class_size = sizeof(AcpiDeviceIfClass),
};

If '.parent'  is a TYPE_INTERFACE, or another type ending in _IF, then
enforce the .name also ends in _IF  (or whatever name convention we
pick)

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

Re: [Qemu-devel] [PATCH V4 0/3] Fixes for PulseAudio driver

[Gerd Hoffmann]

On Fri, Mar 15, 2019 at 09:46:50AM +0100, Martin Schrodt wrote:
> Version 2 of the series added proper commit messages 
> and fixed a typo.
> 
> Version 3 fixes coding style problems
> 
> Version 4 reintroduces the check, whether PA support adjusting
> latency, and sets the default buffer_length to the constant value
> that was present beforehand (works well, and testing revealed that 
> having a longer buffer does not hurt, so it's propably better to 
> not make it artificially short when the user chooses shorter 
> timer periods)
> 
> Martin Schrodt (3):
>   audio/paaudio: fix ignored buffer_length setting
>   audio/paaudio: prolong and make latency configurable
>   audio/paaudio: fix microphone input being unusable

Added to audio queue.

thanks,
  Gerd

[Qemu-devel] [PULL 1/3] audio/paaudio: fix ignored buffer_length setting

[Gerd Hoffmann]

From: Martin Schrodt 

Audiodev configuration allows to set the length of the buffered data.
The setting was ignored and a constant value used instead.
This patch makes the code apply the setting properly, and uses the
previous default if nothing is supplied.

Signed-off-by: Martin Schrodt 
Message-id: 20190315084653.120020-2-mar...@schrodt.org
Signed-off-by: Gerd Hoffmann 
---
 audio/paaudio.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index 5d410ed73f50..ab2a37bbdba3 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -577,7 +577,8 @@ static int qpa_init_out(HWVoiceOut *hw, struct audsettings 
*as,
 
 audio_pcm_init_info (&hw->info, &obt_as);
 hw->samples = pa->samples = audio_buffer_samples(
-qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
+qapi_AudiodevPaPerDirectionOptions_base(ppdo),
+&obt_as, ppdo->buffer_length);
 pa->pcm_buf = audio_calloc(__func__, hw->samples, 1 << hw->info.shift);
 pa->rpos = hw->rpos;
 if (!pa->pcm_buf) {
@@ -637,7 +638,8 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 
 audio_pcm_init_info (&hw->info, &obt_as);
 hw->samples = pa->samples = audio_buffer_samples(
-qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
+qapi_AudiodevPaPerDirectionOptions_base(ppdo),
+&obt_as, ppdo->buffer_length);
 pa->pcm_buf = audio_calloc(__func__, hw->samples, 1 << hw->info.shift);
 pa->wpos = hw->wpos;
 if (!pa->pcm_buf) {
@@ -809,7 +811,16 @@ static int qpa_ctl_in (HWVoiceIn *hw, int cmd, ...)
 return 0;
 }
 
-/* common */
+static int qpa_validate_per_direction_opts(Audiodev *dev,
+   AudiodevPaPerDirectionOptions *pdo)
+{
+if (!pdo->has_buffer_length) {
+pdo->has_buffer_length = true;
+pdo->buffer_length = 46440;
+}
+return 1;
+}
+
 static void *qpa_audio_init(Audiodev *dev)
 {
 paaudio *g;
@@ -836,6 +847,13 @@ static void *qpa_audio_init(Audiodev *dev)
 g = g_malloc(sizeof(paaudio));
 server = popts->has_server ? popts->server : NULL;
 
+if (!qpa_validate_per_direction_opts(dev, popts->in)) {
+goto fail;
+}
+if (!qpa_validate_per_direction_opts(dev, popts->out)) {
+goto fail;
+}
+
 g->dev = dev;
 g->mainloop = NULL;
 g->context = NULL;
-- 
2.18.1

[Qemu-devel] [PULL 0/3] Audio 20190318 patches

[Gerd Hoffmann]

The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:

  Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
staging (2019-03-17 14:10:52 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/audio-20190318-pull-request

for you to fetch changes up to ade103011c6476353fbc2a707aa6ef1f1aa9e2fb:

  audio/paaudio: fix microphone input being unusable (2019-03-18 12:21:15 +0100)


audio: pulseaudio fixes for 4.0



Martin Schrodt (3):
  audio/paaudio: fix ignored buffer_length setting
  audio/paaudio: prolong and make latency configurable
  audio/paaudio: fix microphone input being unusable

 audio/paaudio.c | 44 ++--
 qapi/audio.json |  6 +-
 2 files changed, 39 insertions(+), 11 deletions(-)

-- 
2.18.1

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Joel Stanley]

On Tue, 12 Mar 2019 at 17:36, Markus Armbruster  wrote:

I regularly use the powernv and aspeed machines, but others have
contributed their command lines already.

> = hw/arm/microbit.c =
> Joel Stanley  (maintainer:NRF51)
> Peter Maydell  (maintainer:NRF51)
> qemu-...@nongnu.org (open list:NRF51)

This board can run many the BBC micro:bit firmwares. I have tested it
with micropython, which can be grabbed  from the microbit offical
port[1], built from upstream micropython[2] or downloaded from the
online editor[3]. For development I build it locally so I can use
Qemu's gdb stub to debug qemu models.

$ git clone --recurse-submodules https://github.com/micropython/micropython
$ cd micropthon/ports/nrf/
$ make BOARD=microbit
$ qemu-system-arm -M microbit -kernel build-microbit/firmware.elf
-serial stdio -s
MicroPython v1.10-228-gec6e62efc242 on 2019-03-18; micro:bit with NRF51822
Type "help()" for more information.
>>>

If you have a .hex file from one of the microbit development
environments (try it out on the web IDE at [3]) you can run it like
this:

$ wget https://ozlabs.org/~joel/microbit-micropython.hex
$ qemu-system-arm -M microbit -device
loader,file=microbit-micropython.hex -serial stdio
MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit v1.0.1 with nRF51822
Type "help()" for more information.
>>> print("Hello, Qemu!")
Hello, Qemu!
>>> [a*a for a in range(1, 10)]
[1, 4, 9, 16, 25, 36, 49, 64, 81]
>>>

[1] https://github.com/bbcmicrobit/micropython/
[2] https://github.com/micropython/micropython
[3] https://python.microbit.org/v/1.1

> = hw/lm32/lm32_boards.c =
> Michael Walle  (maintainer:LM32)
>
> = hw/lm32/milkymist.c =
> Michael Walle  (maintainer:milkymist)

I have a port to a lm32 board that is out of tree. A challenge I would
have to upstream that port is it is FPGA based, so it is hard to know
ahead of time the layout, availability and configuration of the
peripherals.

I have reached out to the project that was using it to see if they
still are using it, and if upstreaming would be worthwhile.

>
> = hw/ppc/ppc440_bamboo.c =
> David Gibson  (odd fixer:ppc4xx)
> qemu-...@nongnu.org (open list:ppc4xx)

I use this board to test powerpc 32-bit Linux kernels[4]. However, it
was chosen at random so I could switch to a different one.

  make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-  ppc44x_defconfig
  make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-

  qemu-system-ppc -M bamboo \
   -kernel arch/powerpc/boot/zImage \
   -dtb arch/powerpc/boot/dts/bamboo.dtb \
   -initrd ~/ppc32-440-rootfs.cpio \
   -nographic -serial stdio -monitor pty -append "console=ttyS0"

[4] 
https://github.com/ClangBuiltLinux/continuous-integration/blob/master/driver.sh#L108

On that note, I often refer to the buildroot tree for how to boot
Linux machines. They have a good collection of Qemu command lines:

$ git grep qemu-system- board/qemu/
board/qemu/aarch64-virt/readme.txt:  qemu-system-aarch64 -M virt -cpu
cortex-a53 -nographic -smp 1 -kernel output/images/Image -append
"root=/dev/vda console=ttyAMA0" -netdev user,id=eth0 -device
virtio-net-device,netdev=eth0 -drive
file=output/images/rootfs.ext4,if=none,format=raw,i
board/qemu/arm-versatile/readme.txt:  qemu-system-arm -M versatilepb
-kernel output/images/zImage -dtb output/images/versatile-pb.dtb
-drive file=output/images/rootfs.ext2,if=scsi,format=raw -append
"root=/dev/sda console=ttyAMA0,115200" -serial stdio -net
nic,model=rtl8139 -net user
board/qemu/arm-versatile/readme.txt:  qemu-system-arm -M versatilepb
-kernel output/images/zImage -dtb output/images/versatile-pb.dtb
-append "console=ttyAMA0,115200" -serial stdio -net user -net
nic,model=smc91c111
board/qemu/arm-vexpress/readme.txt:  qemu-system-arm -M vexpress-a9
-smp 1 -m 256 -kernel output/images/zImage -dtb
output/images/vexpress-v2p-ca9.dtb -drive
file=output/images/rootfs.ext2,if=sd,format=raw -append
"console=ttyAMA0,115200 root=/dev/mmcblk0" -serial stdio -net nic,mode
board/qemu/m68k-mcf5208/readme.txt: qemu-system-m68k -M mcf5208evb
-cpu m5208 -kernel output/images/vmlinux -nographic
board/qemu/m68k-q800/readme.txt: qemu-system-m68k -M q800 -kernel
output/images/vmlinux -nographic -drive
file=output/images/rootfs.ext2,format=raw -append "root=/dev/sda
console=ttyS0"
board/qemu/microblazebe-mmu/readme.txt: qemu-system-microblaze -M
petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio
board/qemu/microblazeel-mmu/readme.txt: qemu-system-microblazeel -M
petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio
board/qemu/mips32r2-malta/readme.txt: qemu-system-mips -M malta
-kernel output/images/vmlinux -serial stdio -drive
file=output/images/rootfs.ext2,format=raw -append "root=/dev/hda" -net
nic,model=pcnet -net user
board/qemu/mips32r2el-malta/readme.txt: qemu-system-mipsel -M malta
-kernel output/images/vmlinux -serial stdio -drive
file=output/images/rootfs.ext2,format=raw -append "

[Qemu-devel] [PULL 3/3] audio/paaudio: fix microphone input being unusable

[Gerd Hoffmann]

From: Martin Schrodt 

The current code does not specify the metrics of the buffers for the
input device. This makes PulseAudio choose very bad defaults, which
causes input to be unusable: Audio put in gets out 30 seconds later.
This patch fixes that and makes the latency configurable as well.

Signed-off-by: Martin Schrodt 
Message-id: 20190315084653.120020-4-mar...@schrodt.org
Signed-off-by: Gerd Hoffmann 
---
 audio/paaudio.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index be27c73f094a..45295b4e5ecb 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -605,6 +605,7 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 {
 int error;
 pa_sample_spec ss;
+pa_buffer_attr ba;
 struct audsettings obt_as = *as;
 PAVoiceIn *pa = (PAVoiceIn *) hw;
 paaudio *g = pa->g = drv_opaque;
@@ -615,6 +616,11 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 ss.channels = as->nchannels;
 ss.rate = as->freq;
 
+ba.fragsize = pa_usec_to_bytes(ppdo->latency, &ss);
+ba.maxlength = -1;
+ba.minreq = -1;
+ba.prebuf = -1;
+
 obt_as.fmt = pa_to_audfmt (ss.format, &obt_as.endianness);
 
 pa->stream = qpa_simple_new (
@@ -624,7 +630,7 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 ppdo->has_name ? ppdo->name : NULL,
 &ss,
 NULL,   /* channel map */
-NULL,   /* buffering attributes */
+&ba,/* buffering attributes */
 &error
 );
 if (!pa->stream) {
-- 
2.18.1

[Qemu-devel] [PULL 2/3] audio/paaudio: prolong and make latency configurable

[Gerd Hoffmann]

From: Martin Schrodt 

The latency of a connection to the PulseAudio server is determined by
the tlength parameter. This was hardcoded to 10ms, which is a bit too
tight on my machine, causing audio on host and guest to malfunction.
A setting of 15ms works fine here. To allow tweaking, I also made the
setting configurable via the new -audiodev config. This allows to squeeze out 
better timings in scenarios where the emulation allows it.

I also removed setting of the minreq parameter to (seemingly arbitrary) half 
the latency, since it showed worse audio quality during my tests. Allowing 
PulseAudio to request smaller chunks helped.

Signed-off-by: Martin Schrodt 
Message-id: 20190315084653.120020-3-mar...@schrodt.org
Signed-off-by: Gerd Hoffmann 
---
 audio/paaudio.c | 12 ++--
 qapi/audio.json |  6 +-
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index ab2a37bbdba3..be27c73f094a 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -549,12 +549,8 @@ static int qpa_init_out(HWVoiceOut *hw, struct audsettings 
*as,
 ss.channels = as->nchannels;
 ss.rate = as->freq;
 
-/*
- * qemu audio tick runs at 100 Hz (by default), so processing
- * data chunks worth 10 ms of sound should be a good fit.
- */
-ba.tlength = pa_usec_to_bytes (10 * 1000, &ss);
-ba.minreq = pa_usec_to_bytes (5 * 1000, &ss);
+ba.tlength = pa_usec_to_bytes(ppdo->latency, &ss);
+ba.minreq = -1;
 ba.maxlength = -1;
 ba.prebuf = -1;
 
@@ -818,6 +814,10 @@ static int qpa_validate_per_direction_opts(Audiodev *dev,
 pdo->has_buffer_length = true;
 pdo->buffer_length = 46440;
 }
+if (!pdo->has_latency) {
+pdo->has_latency = true;
+pdo->latency = 15000;
+}
 return 1;
 }
 
diff --git a/qapi/audio.json b/qapi/audio.json
index 97aee3728835..9fefdf5186dd 100644
--- a/qapi/audio.json
+++ b/qapi/audio.json
@@ -206,12 +206,16 @@
 #
 # @name: name of the sink/source to use
 #
+# @latency: latency you want PulseAudio to achieve in microseconds
+#   (default 15000)
+#
 # Since: 4.0
 ##
 { 'struct': 'AudiodevPaPerDirectionOptions',
   'base': 'AudiodevPerDirectionOptions',
   'data': {
-'*name': 'str' } }
+'*name': 'str',
+'*latency': 'uint32' } }
 
 ##
 # @AudiodevPaOptions:
-- 
2.18.1

Re: [Qemu-devel] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

[Markus Armbruster]

Peter Maydell  writes:

> On Mon, 18 Mar 2019 at 08:59, Markus Armbruster  wrote:
>>
>> Alistair Francis  writes:
>>
>> > Set msi_nonbroken as true for the PLIC.
>> >
>> > According to the comment located here:
>> > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
>> > the msi_nonbroken variable should be set to true even if they don't
>> > support MSI. In this case that is what we are doing as we don't support
>> > MSI.
>> >
>> > Signed-off-by: Alistair Francis 
>> > Reported-by: Andrea Bolognani 
>> > Reported-by: David Abdurachmanov 
>> > ---
>> > This should allow working pcie-root-ports in QEMU and allow libvirt
>> > to start using PCIe by default for RISC-V guests.
>>
>> Lovely!  If more people reviewed and updated their interrupt controllers
>> this way, we'd be in better shape.
>
> Why do we have a flag which each interrupt controller
> has to set rather than just making the right thing the
> default (and having the one or two interrupt controllers
> that need the wrong thing for backwards compatibility reasons
> be the ones that have to set the flag) ? This way round makes
> it way to easy to add a new interrupt controller with this
> bug without noticing it, I think.

This is ultimately a question for Michael (cc'ed).  However, I can
provide a bit of context right away.

The problem is virtual interrupt controllers that claim to support MSI
when they don't.  The OS's probe returns "go ahead and use MSI", and the
system falls apart.

So we put in a lame work-around to masks these interrupt controller
bugs: if MSI is broken, mangle all PCI devices to make them deny MSI
capability.

The next problem is that we don't even know which of our interrupt
controllers have MSI working.  So we summarily declare them all broken,
then have the few we actually know declare themselves non-broken.

The next problem is having multiple interrupt controllers, some broken,
some not.  The work-around falls apart there.  We currently use the
ostrich algorithm to deal with that.

More information in the thread around
Message-ID: <87wppi1vol@blackfin.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00983.html

Re: [Qemu-devel] Combining synchronous and asynchronous IO

[Sergio Lopez]

Kevin Wolf writes:

> Am 15.03.2019 um 16:33 hat Sergio Lopez geschrieben:
>> 
>> Stefan Hajnoczi writes:
>> 
>> > On Thu, Mar 14, 2019 at 06:31:34PM +0100, Sergio Lopez wrote:
>> >> Our current AIO path does a great job at unloading the work from the VM,
>> >> and combined with IOThreads provides a good performance in most
>> >> scenarios. But it also comes with its costs, in both a longer execution
>> >> path and the need of the intervention of the scheduler at various
>> >> points.
>> >> 
>> >> There's one particular workload that suffers from this cost, and that's
>> >> when you have just 1 or 2 cores on the Guest issuing synchronous
>> >> requests. This happens to be a pretty common workload for some DBs and,
>> >> in a general sense, on small VMs.
>> >> 
>> >> I did a quick'n'dirty implementation on top of virtio-blk to get some
>> >> numbers. This comes from a VM with 4 CPUs running on an idle server,
>> >> with a secondary virtio-blk disk backed by a null_blk device with a
>> >> simulated latency of 30us.
>> >
>> > Can you describe the implementation in more detail?  Does "synchronous"
>> > mean that hw/block/virtio_blk.c makes a blocking preadv()/pwritev() call
>> > instead of calling blk_aio_preadv/pwritev()?  If so, then you are also
>> > bypassing the QEMU block layer (coroutines, request tracking, etc) and
>> > that might explain some of the latency.
>> 
>> The first implementation, the one I've used for getting these numbers,
>> it's just preadv/pwrite from virtio_blk.c, as you correctly guessed. I
>> know it's unfair, but I wanted to take a look at the best possible
>> scenario, and then measure the cost of the other layers.
>> 
>> I'm working now on writing non-coroutine counterparts for
>> blk_co_[preadv|pwrite], so we have SIO without bypassing the block layer.
>
> Maybe try to keep the change local to file-posix.c? I think you would
> only have to modify raw_thread_pool_submit() so that it doesn't go
> through the thread pool, but just calls func directly.

I already tried something similar, but I'd like to explore the
possibility of avoiding the coroutine/aio_poll dance to trim down
another ~10us.

If it's deemed to be too complex or hard to maintain, we can always fall
back to something simpler.

Thanks,
Sergio.

Re: [Qemu-devel] [PATCH v3] hw/acpi: extract acpi_add_rom_blob()

[Igor Mammedov]

On Fri, 15 Mar 2019 08:44:32 +0800
Wei Yang  wrote:

in subject: s/extract/generalize/

> arm and i386 has almost the same function acpi_add_rom_blob(), except
> giving different FWCfgCallback function.
> 
> This patch extract acpi_add_rom_blob() to utils.c by passing
 s/extract/moves/

> FWCfgCallback to it.
> 
> Signed-off-by: Wei Yang 

otherwise patch looks fine to me,
but checkpatch complains about comment style so that needs to be fixed as well

> 
> ---
> v3:
>   * put acpi_add_rom_blob() to hw/acpi/utils.c
> v2:
>   * remove unused header in original source file
> ---
>  hw/acpi/Makefile.objs|  2 +-
>  hw/acpi/utils.c  | 35 +++
>  hw/arm/virt-acpi-build.c | 26 ++
>  hw/i386/acpi-build.c | 26 ++
>  include/hw/acpi/utils.h  |  9 +
>  5 files changed, 65 insertions(+), 33 deletions(-)
>  create mode 100644 hw/acpi/utils.c
>  create mode 100644 include/hw/acpi/utils.h
> 
> diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
> index 2d46e3789a..ba93c5b64a 100644
> --- a/hw/acpi/Makefile.objs
> +++ b/hw/acpi/Makefile.objs
> @@ -10,7 +10,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
>  
>  common-obj-y += acpi_interface.o
>  common-obj-y += bios-linker-loader.o
> -common-obj-y += aml-build.o
> +common-obj-y += aml-build.o utils.o
>  common-obj-$(CONFIG_TPM) += tpm.o
>  
>  common-obj-$(CONFIG_IPMI) += ipmi.o
> diff --git a/hw/acpi/utils.c b/hw/acpi/utils.c
> new file mode 100644
> index 00..ab0e064a0e
> --- /dev/null
> +++ b/hw/acpi/utils.c
> @@ -0,0 +1,35 @@
> +/* Utilities for generating ACPI tables and passing them to Guests
> + *
> + * Copyright (C) 2019 Intel Corporation
> + * Copyright (C) 2019 Red Hat Inc
> + *
> + * Author: Wei Yang 
> + * Author: Igor Mammedov 
> + *
> + * 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 .
> + */
> +
> +#include "qemu/osdep.h"
> +#include 
> +#include "hw/acpi/aml-build.h"
> +#include "hw/acpi/utils.h"
> +
> +MemoryRegion *acpi_add_rom_blob(FWCfgCallback update, void *opaque,
> +GArray *blob, const char *name,
> +uint64_t max_size)
> +{
> +return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> +name, update, opaque, NULL, true);
> +}
> +
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 57679a89bf..a846f74a14 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -37,9 +37,9 @@
>  #include "hw/acpi/acpi.h"
>  #include "hw/nvram/fw_cfg.h"
>  #include "hw/acpi/bios-linker-loader.h"
> -#include "hw/loader.h"
>  #include "hw/hw.h"
>  #include "hw/acpi/aml-build.h"
> +#include "hw/acpi/utils.h"
>  #include "hw/pci/pcie_host.h"
>  #include "hw/pci/pci.h"
>  #include "hw/arm/virt.h"
> @@ -881,14 +881,6 @@ static void virt_acpi_build_reset(void *build_opaque)
>  build_state->patched = false;
>  }
>  
> -static MemoryRegion *acpi_add_rom_blob(AcpiBuildState *build_state,
> -   GArray *blob, const char *name,
> -   uint64_t max_size)
> -{
> -return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> -name, virt_acpi_build_update, build_state, NULL, 
> true);
> -}
> -
>  static const VMStateDescription vmstate_virt_acpi_build = {
>  .name = "virt_acpi_build",
>  .version_id = 1,
> @@ -920,20 +912,22 @@ void virt_acpi_setup(VirtMachineState *vms)
>  virt_acpi_build(vms, &tables);
>  
>  /* Now expose it all to Guest */
> -build_state->table_mr = acpi_add_rom_blob(build_state, tables.table_data,
> -   ACPI_BUILD_TABLE_FILE,
> -   ACPI_BUILD_TABLE_MAX_SIZE);
> +build_state->table_mr = acpi_add_rom_blob(virt_acpi_build_update,
> +  build_state, tables.table_data,
> +  ACPI_BUILD_TABLE_FILE,
> +  ACPI_BUILD_TABLE_MAX_SIZE);
>  assert(build_state->table_mr != NULL);
>  
>  build_state->linker_mr =
> -acpi_add_rom_blob(build_state, tables.linker->cmd_blob,
> -  "etc/table-lo

Re: [Qemu-devel] [PATCH v2 09/11] hw/acpi: Add ACPI Generic Event Device Support

[Igor Mammedov]

On Fri, 8 Mar 2019 11:42:16 +
Shameer Kolothum  wrote:

> From: Samuel Ortiz 
> 
> The ACPI Generic Event Device (GED) is a hardware-reduced specific
> device that handles all platform events, including the hotplug ones.
> This patch generate the AML code that defines GEDs.
> Platforms need to specify their own GedEvent array to describe what kind
> of events they want to support through GED. The build_ged_aml routine
> takes a GedEvent array that maps a specific GED event to an IRQ number.
> Then we use that array to build both the _CRS and the _EVT section
> of the GED device.

I'd this a part of "virtual ACPI device"

> This is in preparation for making use of GED for ARM/virt
> platform and for now supports only memory hotplug.
> 
> Signed-off-by: Samuel Ortiz 
> Signed-off-by: Sebastien Boeuf 
> Signed-off-by: Shameer Kolothum 
> ---
[...]

Re: [Qemu-devel] [PATCH for-4.0?] arm: Allow system registers for KVM guests to be changed by QEMU code

[Peter Maydell]

On Mon, 18 Mar 2019 at 12:34, gengdongjiu  wrote:
>
>
>
> On 2019/3/16 4:11, Philippe Mathieu-Daudé wrote:
> >> Signed-off-by: Peter Maydell 
> >> ---
> >> Should we try to put this in for rc1? Not sure... Testing
> >> definitely appreciated.
> > You might include it for rc1 and we still have rc2/rc3 to revert it.
>
> why we still have rc2/rc3 to revert it?

I think Philippe's point is that it's reasonably safe to
apply this patch in rc1 (ie now), because if we do do that
and then discover that we have some other bug in it, we
still have plenty of time to take the patch out again
before release.

(If we did discover another bug in this patch in future, I
would favour reverting it for the 4.0 release rather than
trying to fix whatever that bug was, because two unexpected
bugs in the patch means I clearly didn't understand
the code well enough to produce a reliable patch. The cases
that this patch fixes are pretty rare -- it does fix a bug
but only in handling of some cases of debugging a KVM guest;
but the patch potentially affects the behaviour of any
KVM guest, even if the user isn't trying to debug. So it's
riskier than some other kinds of change, and on balance
that means that when we're making a decision at rc2 or rc3
I'm more in favour of just reverting it rather than
applying what we hope is a fix.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] ati-vga: i2c fix

[Gerd Hoffmann]

  Hi,

> Does it work with the latest patch for you?

No (testing with radeonfb.ko).

> you could share those. It may also need changes to vgabios but I'm not
> familiar with that so I hope you can help with that. I've found the r128 X
> driver needs a VBE BIOS function to access DDC as mentioned in the commit
> message.

Can look into that but it's not top priority.

cheers,
  Gerd

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Tue, Mar 12, 2019 at 11:50:54AM +0100, Markus Armbruster wrote:
>> We have two separate type trees, object types rooted at TYPE_OBJECT, and
>> interface types at TYPE_INTERFACE.
>> 
>> Object types are fore defining ultimately concrete types, i.e. any
>> concrete type is a descendant of TYPE_OBJECT.  Interior nodes of the
>> TYPE_OBJECT tree are commonly abstract, with a few exceptions.  Leaves
>> need to be concrete to be of any use.
>> 
>> Interface types are for defining interfaces object types provide (by
>> listing them in a type's .interfaces).  TYPE_INTERFACE and all its
>> descendants are abstract.
>> 
>> Issue #1: INTERFACE_CLASS()
>> 
>> #define OBJECT_CLASS(class) \
>> ((ObjectClass *)(class))
>> 
>> #define OBJECT_CLASS_CHECK(class_type, class, name) \
>> ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), 
>> (name), \
>>__FILE__, __LINE__, 
>> __func__))
>> 
>> #define INTERFACE_CLASS(klass) \
>> OBJECT_CLASS_CHECK(InterfaceClass, klass, TYPE_INTERFACE)
>> 
>> Shouldn't INTERFACE_CLASS() be named INTERFACE_CLASS_CHECK() for
>> consistency?
>
> I actually wonder why we even need "OBJECT_CLASS" as it exists here
> at all.
>
> $ git grep 'OBJECT_CLASS\b' | wc -l
> 38
> $ git grep 'OBJECT_CLASS_CHECK\b' | wc -l
> 196
>
> There's no obvious pattern in why OBJECT_CLASS is being favoured.
> The only compelling benefit of it is that it is faster since it
> avoids checking anything.
>
> What if we include sub-classes
>
>   $ git grep '_CLASS('  | grep -v GET_CLASS | wc -l
>   1946
>
> It looks like ${FOO}_CLASS is the popular syntax, but this is misleading
> as sub-classes don't follow the same convention - they all appear to make
> their ${FOO}_CLASS macro call OBJECT_CLASS_CHECK, as this is what object.h
> recommands as the pattern :-)
>
> #define MACHINE_CLASS(klass) \
> OBJECT_CLASS_CHECK(MachineClass, (klass), TYPE_MACHINE)
>
>
> IOW, I think we could/should remove OBJECT_CLASS and rename
> OBJECT_CLASS_CHECK to OBJECT_CLASS.
>
> If there are some callers that absolutely need the performance
> of doing a cast without safety checks, they can just do a
> direct cast with normal C syntax - no need for a macro.

+1

Wrapping a macro around a type cast is in bad taste more often than not.
C is a simple language.  Not-so-simple things can require more
acrobatics than we'd like to, even macro acrobatics.  On the flip side,
truly simple things can be kept simple and obvious.  Hiding them behind
macros throws that away.

If abstraction is more dear to you than simplicity and obviousness, then
that's totally fair, except for your poor, poor choice of a programming
language ;)

>> Rename would be trivial, as there are no uses.
>
> Renaming INTERFACE_CLASS becomes redundant if we fix OBJECT_CLASS

Yes.

>> Issue #2: INTERFACE_CHECK()
>> 
>> #define OBJECT_CHECK(type, obj, name) \
>> ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
>> __FILE__, __LINE__, __func__))
>> 
>> #define INTERFACE_CHECK(interface, obj, name) \
>> ((interface *)object_dynamic_cast_assert(OBJECT((obj)), (name), \
>>  __FILE__, __LINE__, 
>> __func__))
>> 
>> The two are identical (except the former lacks parenthesis around obj,
>> which is a minor bug).
>> 
>> Obvious question: shouldn't we de-duplicate the code?
>> 
>> There's a more interesting question, however.  Since two two are
>> identical, they can be used interchangeably.  And since we can, we do;
>> for instance
>> 
>> #define QAUTHZ(obj) \
>>  INTERFACE_CHECK(QAuthZ, (obj), \
>>  TYPE_QAUTHZ)
>> 
>> even though TYPE_QAUTHZ is a sub-type of TYPE_OBJECT, not
>> TYPE_INTERFACE.  Shouldn't we prevent that somehow?  Or maybe embrace
>> they're the same and just get rid of INTERFACE_CHECK() entirely?
>
> If we wanted to keep INTERFACE_CHECK then I agree we should make it fail
> when not given an interface type, but i'm not really convinced it is
> worth it. Code is inevitably going to get these mixed up, as this QAUTHZ
> example shows. So doing a stronger check will just turn currently working
> code into broken code at runtime.
>
> I'd vote for removing INTERFACE_CHECK and using OBJECT_CHECK universally.

Slightly unclean, since interface types really aren't object types.
Tolerable.

>> Issue #3: Inconsistent naming (surprise, surprise)
>> 
>> The confusion between object and interface types is of course aggravated
>> by our usual lack of discipline in naming.  I recognize no less than
>> three naming conventions:
>> 
>> INTERFACE_CONVENTIONAL_PCI_DEVICE
>> INTERFACE_PCIE_DEVICE
>
> Definitely cull this convention - not having TYPE_ is a gratuitous
> diversion from the norm.
>
>> 
>> TYPE_ACPI_DEVICE_IF
>> TYPE_ARM_LINUX_BOOT_IF
>> TYPE_TEST_IF
>> TYPE_TPM_

Re: [Qemu-devel] [PATCH for-4.0?] arm: Allow system registers for KVM guests to be changed by QEMU code

[gengdongjiu]

On 2019/3/16 4:11, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Peter Maydell 
>> ---
>> Should we try to put this in for rc1? Not sure... Testing
>> definitely appreciated.
> You might include it for rc1 and we still have rc2/rc3 to revert it.

why we still have rc2/rc3 to revert it?
If we can find the root cause about the regression and fix it, we can apply it.
so we may need to debug this issue.

> 
>> ---
>>  target/arm/cpu.h |  9 -

Re: [Qemu-devel] [PATCH for-4.1 v2 02/13] tcg: Return bool success from tcg_out_mov

[Richard Henderson]

On 3/17/19 8:03 PM, Aleksandar Markovic wrote:
> This patch merely changes the interface, aborting on all failures,
> of which there are currently none.
> 
> 
> Why is this necessary?

See patch 6, in which tcg/ppc tcg_out_mov returns false for
moves between integer and vector registers.


r~

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Mon, Mar 18, 2019 at 11:59:43AM +, Peter Maydell wrote:
>> On Mon, 18 Mar 2019 at 11:54, Daniel P. Berrangé  wrote:
>> > > TYPE_ACPI_DEVICE_IF
>> > > TYPE_ARM_LINUX_BOOT_IF
>> > > TYPE_TEST_IF
>> > > TYPE_TPM_IF
>> > >
>> > > TYPE_IDAU_INTERFACE
>> > > TYPE_IPMI_INTERFACE
>> > > TYPE_PNV_XSCOM_INTERFACE
>> >
>> > I'm not so bothered by these, though they are pointless unless
>> > perhaps it is to avoid clash with a similarly named object
>> > type
>> 
>> For the ones of these that I'm responsible for, I was
>> partly following an existing example, but I find it useful
>> as a user of the APIs that it's clear that I'm dealing
>> with an interface and not an object.

Me too.

>>  For instance if I
>> see a PROP_LINK that wants a TYPE_IDAU_INTERFACE I know
>> I need to implement an interface on some suitable object,
>> whereas if it were a TYPE_IDAU I'd be expecting to need
>> to create (or write a subclass of) a concrete object.
>> So I'd prefer us to settle on a convention that does
>> explicitly mark the interface-ness in the type name.
>
> If we do want such a naming convention, then I think we'd want to have
> checkpatch enforce it. eg in the .c file validate the TypeInfo struct:
>
> static const TypeInfo acpi_dev_if_info = {
> .name  = TYPE_ACPI_DEVICE_IF,
> .parent= TYPE_INTERFACE,
> .class_size = sizeof(AcpiDeviceIfClass),
> };
>
> If '.parent'  is a TYPE_INTERFACE, or another type ending in _IF, then
> enforce the .name also ends in _IF  (or whatever name convention we
> pick)

Very nice to have.

In case teaching it to checkpatch turns out to be too onerous: perhaps
certain things would be easier to check in a program that looks at
sources rather than patches.  Other projects have that as "make
syntax-check".

Re: [Qemu-devel] [PATCH for-4.0] include/qemu/bswap.h: Use __builtin_memcpy() in accessor functions

[Richard Henderson]

On 3/18/19 4:29 AM, Peter Maydell wrote:
> In the meantime, switch to using __builtin_memcpy() in the
> bswap.h accessor functions. This will make us robust against things
> like this fortify library in the short term. In the longer term
> it will mean that we don't end up with these functions being really
> badly-performing even if the semantics of the out-of-line memcpy()
> are correct.
> 
> Reported-by: Fernando Casas Schössow 
> Signed-off-by: Peter Maydell 
> ---

Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [PULL 2/3] seabios: turn off CONFIG_ATA_DMA

[Gerd Hoffmann]

There have been regressions reported, when booting FreeDOS.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg593254.html

Signed-off-by: Gerd Hoffmann 
---
 roms/config.seabios-128k | 2 +-
 roms/config.seabios-256k | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/roms/config.seabios-128k b/roms/config.seabios-128k
index 35b5a07d8f1f..a17502ca0f61 100644
--- a/roms/config.seabios-128k
+++ b/roms/config.seabios-128k
@@ -2,7 +2,7 @@
 # need to turn off features (xhci,uas) to make it fit into 128k
 CONFIG_QEMU=y
 CONFIG_ROM_SIZE=128
-CONFIG_ATA_DMA=y
+CONFIG_ATA_DMA=n
 CONFIG_BOOTSPLASH=n
 CONFIG_XEN=n
 CONFIG_USB_OHCI=n
diff --git a/roms/config.seabios-256k b/roms/config.seabios-256k
index b14b614fcc70..d1bcc9453ca0 100644
--- a/roms/config.seabios-256k
+++ b/roms/config.seabios-256k
@@ -1,4 +1,4 @@
 # for qemu machine types 2.0 + newer
 CONFIG_QEMU=y
 CONFIG_ROM_SIZE=256
-CONFIG_ATA_DMA=y
+CONFIG_ATA_DMA=n
-- 
2.18.1

[Qemu-devel] [PULL 1/3] seabios: update submodule to 1.12.1

[Gerd Hoffmann]

git shortlog rel-1.12.0..rel-1.12.1
===

Kevin O'Connor (1):
  usb-ehci: Clear pipe token on pipe reallocate

Stephen Douthit (1):
  tpm: Check for TPM related ACPI tables before attempting hw probe

Signed-off-by: Gerd Hoffmann 
---
 roms/seabios | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/seabios b/roms/seabios
index a698c8995ffb..a5cab58e9a3f 16
--- a/roms/seabios
+++ b/roms/seabios
@@ -1 +1 @@
-Subproject commit a698c8995ffb2838296ec284fe3c4ad33dfca307
+Subproject commit a5cab58e9a3fb6e168aba919c5669bea406573b4
-- 
2.18.1

Re: [Qemu-devel] [PULL 0/3] Audio 20190318 patches

[Peter Maydell]

On Mon, 18 Mar 2019 at 12:11, Gerd Hoffmann  wrote:
>
> The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
> staging (2019-03-17 14:10:52 +)
>
> are available in the Git repository at:
>
>   git://git.kraxel.org/qemu tags/audio-20190318-pull-request
>
> for you to fetch changes up to ade103011c6476353fbc2a707aa6ef1f1aa9e2fb:
>
>   audio/paaudio: fix microphone input being unusable (2019-03-18 12:21:15 
> +0100)
>
> 
> audio: pulseaudio fixes for 4.0
>
> 

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

[Qemu-devel] [PULL 3/3] seabios: update binaries to 1.12.1

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
 pc-bios/bios.bin  | Bin 131072 -> 131072 bytes
 pc-bios/vgabios-bochs-display.bin | Bin 27648 -> 27648 bytes
 pc-bios/vgabios-cirrus.bin| Bin 38400 -> 38400 bytes
 pc-bios/vgabios-qxl.bin   | Bin 38912 -> 38912 bytes
 pc-bios/vgabios-ramfb.bin | Bin 28160 -> 28160 bytes
 pc-bios/vgabios-stdvga.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-virtio.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-vmware.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios.bin   | Bin 38400 -> 38400 bytes
 10 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/bios-256k.bin b/pc-bios/bios-256k.bin
index 
08ca873ab57ab6e14bb9a5cdf703c6501230f1d3..04671f160aefce48ad9aa201365dbca21537de2f
 100644
GIT binary patch
delta 46868
zcmZsE34D!5_y5euhHw*ZA|i<_mn0-41VKVbh+V9u_EtkJEpje$*o+hE2v1954L%>hmUZbKMb
z1iU<)v3esI3jrd59H3+*W0!$WFW`L?WA{fh)_W{tlYwQxZD7)P#-;+9K==ff#S$hk
z_Brs+L@+Xmv5$c7fGa@Xml)dz1ij4I!^w=Td4;j=Q<3&6V+VoG(-_+Y>;?9}#+d(X
z#+n1ufJ$KK8(f}j
zK-fVjB(Mc=FGqvGbYOV}V^4s(hoR8G9-!e!x3W2HXJd0+By5
z_9YN@jIjuy4bTY~00jNa*o&tygMdxIh+h~R1GGI2Mu8WAall64E1<=%=qOO{3}ZD}
zzhOFDWNiLr#v1(rjlROz!mErO0&IUm`Klo18;s@OWGvw}V~hWS*zPjc=Wo>e2W5c#
zdyMtC4`l<^0y7^nw)7EWSAkBC8H;|x*f}8ZDW)7S0a(vDy9H!D#2+R&YX*b>q7G;7
zKsXQ$8~{|Hr3+`VKxg2r8)uh*KY<%SygO&TfI+}ZzyhGqle51Yau#9W>?Gjg#aTaZ
z&b|X=BhWW;7GvaD>?J%DHvtiU&L#o5z)Jy~Z34`}ob3RP1EvtpvVm`a3Sep|XH`I0
z3(lqh9xXWw0^R_k!#Udqd<_%=dx6&?IJ*f1M}ig*0YpV+feSpu0r5ZrkOZUveSiT#
z8ZaD4Xpd)LX9}bO+yGcF&Wu0=kN~6slYvZNIj|1+4mbpy2V7D)^8;4&0b{_Pf%tO(
zI0XCv90yJT34Or`kOK4p1^^3zY#wFZRBs$(!+?pvOyJG&m|{Th31A%90koNfl?(VBC;_U0BUqSPy$tCA*MJWvqa(my
zS@`4f3MM)567UA_0l=m(HVRk_tOM==4Y8U90;7QBX_(j3VN3w;8CW1@Vu1i$W;134
z@_~nQz_=MUA_MP0=v>AI0@r}pc~}*Jte^46h?VO-U>#5lR021FnOMOV03QPHVf9iL
zpbSt7%*E=p6!-wx1ndHi09S#BfPE3hc`=3&3sK+_teU`ofVY4PK=hl8^?wuNzW@&_
zfK9+pKr;)>DBu9v=VI)DNx(P23E(_X_bpgI;27}ZQpQ^6VPOJ304@SP3Zw}v0X6^?
zz*)d^8DlBH9N+*j)Qa(Mu^ekRFgqVafKP$TK-k+5`Fk*%z)9db(Di*V0XSA-tUtrj
z2)w)jQUQv9l#Lh?AOolYN;hM;w!m8gs)5KaAYtG~AbTqq&cdG)K=7B0d2E9}0h|T0
zw?hE|2QcI-#y$hi0#^a=9Z)#nbs!h`8n_0u+KGmMOkfw#!|Oz*)c!JUNc>f9C{x
z0UQEO0gr)zlZ-_H34j80`x#;bDu7eKRbb&MEXAk6=&z6%5C^OPjsi76Y9(v}Fb7x!
zyaRj+dw9;{KeSEzyqN1U6^v90vP%?7zU#L
z!IT6J0M`L|4+|2o2e=RPzn{g}*!xf-Ah`w%0CgW=N&zQ;3qb5ch#mL@82t#o9?;`4
zqyqd6bb5lJ0n(nL3}6F(1ll@HVg(FxG{00=U=XtS>MYcm?QDA3gz4
z2{eVf)dP4N$odL@+#A5h0_Fg#fk%J~{IN*jO<)zU4cHAl1(M;TO#$Wt3xE~CO~3)P
zgYVW0cnw$rtOmXWP65||&hY8Xzy{!`H+;G)co+pI?`NQKW6nAPZvy`Squ}qo2kZb!
zfIuJ41_L{R9{?5b@Z~HNhzC-DQNS!#l)1}}KFV6Em0
zmcAl=MZxiDynS6!)la&bc^AG~CYgC~`%V4f{guYvTk;gT$Fk1m95$ae?6NDKCgr+P
zslJ75(#DK08}Y)(VM@93t9rUO_&8_{oLnqJGx@+&QwiD_&6PlU$UU6V#oA!?
zFaxtZXgsg2mQHVq%a3d5!}#Mmd{p^bYIw%4)&{|~b%RUfu1uaPJc|n)nS7lP2lmMI
z3%IZMl|2oaVOLy)HNj-qk?;wU4=vzv@gd1zA~3I@AyYc!(BHrn_*>z+5`XDmh3j(X
zQ*2399m^pHdSGqfQCtwWkPqO(v`41r8rBsfwPeF>IfNfCI49sp%;cUGZI8Q`w_B_uD*Gv1fR
zVS0(t6=S?9n~xO72goPc+)wNpAe$`Vefc~&X$cSDc?FA?@KjgRN{m?oH#bNS8KK#U
zOGvU+jbcljk7h4RqF;%$zr{NTj_d|*;!G7OCgR)K1y8*TU1ayAygB!m6PEH0;!2|Y
zU@4E}VX|Z?PvK_in#ZGgZ`nSNxAAR~i0;FVGFxMqSUBkmbEQDXKGN7M1a%l+(@>GnJuUjj@+$Nl;Uk
zldTc5e~lDvj;b^9l%L6Iieg5dGaK`VxhM~mg4Ovviuc<#(ZC31clFZ&=<3Zf@MP&q
z?{Cxl-xYO8@?*+kODu^SQ4kw-@9=$4Wv>-{Vpd}!8fqxmZ}W16yL%f0@)b;(_5B>Ql6%tZu2ieXD8WJr&dEBV
zY~(P@jRkxeUG=8Mkc}Xp!s57n{kt~rsaSqro%XUKdN4B%>R_Egl0C9bXx&3XVvC6
z9S(;pRfkZl!%Z&ATU1W@U^)HWw}SqDwUV+^OdiTxtH;W;_j$5ARVakH`RILq!IxeZ
z&B(V>MXN>o`~LE=^6iy;xBC^CShX}-rmf=PSx&?Hf2?TB>;}*W*BX>fPjnc_1|QPQ
zEC$nc13gx_{-7nmFFxQ|hIugrI_hF7qB&=a!kRFmm4N57awu!fB}YTb
z^Rh8WXy;J1k97Hfuj)bd?0-NA8ZBji;R;GP`CLLCC6ppTDJ@)1&)+|nxx84O{eTC<
z?mhZ|2Sid+W9*YrU<_0q3+&IRq_LKUG-_V?OF3JJ1wBb}-!`MLYBTfnB8Gn0=#O6Z
zm#1i~4C*)}KbumOI?APeTPDgJ$wQ6lA2nbjlu&D!tZ+?*sR##Qq)xr98lr@?}eDUd@9=+#dPCYQE4d9?PHlsr37h2gXN`
zqMpG7P(4wrDzJzw6zUv@2c!fki#?P(h3h7w{PiaeM{3n>%K|?#HeAm9kjHsel2Z3T
z4Ru|r-2NdS5<3wo>4m-d7)=|ylX;0zGCh>3F1hD2Tz5~yY*9veS_20_beKH@ie=l6
zcwaHRSpMfDo)qwyW;#uT=9xt3~BiAcs1*i!>K)Bv75ZKmN(@l`EV^C6cY!HBeeqcwJ7MCqv=5}P%
zPa*@;rnzk)aoL}^Y$DUvb0e=SUs=!7+ODQ_Y*v}N9FB$E1q~DtyWqZB?H>q{l0}I<
z3I7xq~Gx&{Lyr9VulJDf;FFDC{9emAAUFqddBiH}^gY&q1ju
zBBw*SgC#vwKHA9r$2GyG3B9|6T#)d#9Vhj|ykcr6kf?H3JHZ*N`VNy36?K-i>KCa4
zBp>aq6mL|$)(mTjdz#5NHu03Uju3m6(^Dfd)LZEnOswYnBb5LQF2)XrmSC>4o>
zRZ$)oc0EusBT%LdW(C-~q&AfkKIh3D8|z&4cCn5MP%15#c;^apOZ9t1ysd=VzCvuiBP&1WFV;_@LI0hYG04Qtyx9xm+JZP7V{5X}O4_(ZnA=$Ku6}|H
z(D1iuRWxP0+!>qm2BaqTiA3{EdoWv$niWYfJ&2rz9xkbo_&HOIHH3Vb&^KbMW_Z16nXW
z#*mY`;RY?mCTy
z)fYUT_mtPZ;7RTkCTgyOY_pXQX}5xGJ|ad;-A{_+uGrPr;7%!j)z-~J=%5NKU+sIQ
z{CX>o;N9ift=wN^ZjS;1P)P)A0
zKB^h%#q&Xm{L#Hpd&L7Rz71hru
z5=qA>sXhuRPfD+P7z%FY_i~`Vr}9vB14Z&DGP@WGZrSP)KdSnH7jfv~meIV3f*ZD`
zdU7iy#~!x%>u&*gqupH9Zsj2+hNrrl5)LXgI&*%xHw{wR!M(D&IjI?PcSHEf43h^G
z+{MY-WnwKo28yVev1*k{gF@#T*p-FwN%d~tqhj4r%sRm2S6h_gV$i#Vnjo5lqeLJP
z(zvZw|3U7u#`*oE-%cJdD2B3COx&^3LL6L%DY+4{>{qDs_`r=y@eQH<9(f=E0-)(eqz0hRYzHygF4F
zHWIqtqdzF~6fzCF2ADi+n=>`kgsQ4X>EWQ=i1}(c5I`;jE+yN$&jXW^C&(+_f
zG~XTX>9Xuw-d!BnEnU9jp?s_i|BgqxzebGz&|1EL7h``|u88Eiidh?n6_oY1T=^Z3
z4H$*^YW6}

[Qemu-devel] [PULL 0/3] Seabios 1.12.1 20190318 patches

[Gerd Hoffmann]

The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:

  Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
staging (2019-03-17 14:10:52 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/seabios-1.12.1-20190318-pull-request

for you to fetch changes up to 92b80ab1d628c47a517cd9c8664710508e4c20ad:

  seabios: update binaries to 1.12.1 (2019-03-18 14:07:06 +0100)


seabios update for 4.0



Gerd Hoffmann (3):
  seabios: update submodule to 1.12.1
  seabios: turn off CONFIG_ATA_DMA
  seabios: update binaries to 1.12.1

 pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
 pc-bios/bios.bin  | Bin 131072 -> 131072 bytes
 pc-bios/vgabios-bochs-display.bin | Bin 27648 -> 27648 bytes
 pc-bios/vgabios-cirrus.bin| Bin 38400 -> 38400 bytes
 pc-bios/vgabios-qxl.bin   | Bin 38912 -> 38912 bytes
 pc-bios/vgabios-ramfb.bin | Bin 28160 -> 28160 bytes
 pc-bios/vgabios-stdvga.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-virtio.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-vmware.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios.bin   | Bin 38400 -> 38400 bytes
 roms/config.seabios-128k  |   2 +-
 roms/config.seabios-256k  |   2 +-
 roms/seabios  |   2 +-
 13 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.18.1

Re: [Qemu-devel] [PULL 0/5] Ui 20190318 patches

[Peter Maydell]

On Mon, 18 Mar 2019 at 11:24, Gerd Hoffmann  wrote:
>
> The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
> staging (2019-03-17 14:10:52 +)
>
> are available in the Git repository at:
>
>   git://git.kraxel.org/qemu tags/ui-20190318-pull-request
>
> for you to fetch changes up to 0a87602268884f977ba67df8b51735bf5ac141ec:
>
>   keymaps: regenerate keymaps (2019-03-18 12:06:04 +0100)
>
> 
> ui: fixes for 4.0 (vnc, curses, keymaps).
>

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Daniel P . Berrangé]

On Mon, Mar 18, 2019 at 01:53:38PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé  writes:
> 
> >>  For instance if I
> >> see a PROP_LINK that wants a TYPE_IDAU_INTERFACE I know
> >> I need to implement an interface on some suitable object,
> >> whereas if it were a TYPE_IDAU I'd be expecting to need
> >> to create (or write a subclass of) a concrete object.
> >> So I'd prefer us to settle on a convention that does
> >> explicitly mark the interface-ness in the type name.
> >
> > If we do want such a naming convention, then I think we'd want to have
> > checkpatch enforce it. eg in the .c file validate the TypeInfo struct:
> >
> > static const TypeInfo acpi_dev_if_info = {
> > .name  = TYPE_ACPI_DEVICE_IF,
> > .parent= TYPE_INTERFACE,
> > .class_size = sizeof(AcpiDeviceIfClass),
> > };
> >
> > If '.parent'  is a TYPE_INTERFACE, or another type ending in _IF, then
> > enforce the .name also ends in _IF  (or whatever name convention we
> > pick)
> 
> Very nice to have.
> 
> In case teaching it to checkpatch turns out to be too onerous: perhaps
> certain things would be easier to check in a program that looks at
> sources rather than patches.  Other projects have that as "make
> syntax-check".

FWIW, I think most of what qemu's checkpatch does would be better
as checks against the source tree. The big pain with checkpatch
is that it never enforces that we clean up existing code. So any
time we introduce a new rule, it usually means that we end up having
2 different styles in the code forever.

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

Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Peter Maydell]

On Mon, 18 Mar 2019 at 13:17, Daniel P. Berrangé  wrote:
> On Mon, Mar 18, 2019 at 01:53:38PM +0100, Markus Armbruster wrote:
> > In case teaching it to checkpatch turns out to be too onerous: perhaps
> > certain things would be easier to check in a program that looks at
> > sources rather than patches.  Other projects have that as "make
> > syntax-check".
>
> FWIW, I think most of what qemu's checkpatch does would be better
> as checks against the source tree. The big pain with checkpatch
> is that it never enforces that we clean up existing code. So any
> time we introduce a new rule, it usually means that we end up having
> 2 different styles in the code forever.

The other big problem with checkpatch is that it's a huge perl
script that is doing fairly ad-hoc operations on textual source,
and certainly I find it almost impossible to understand to be
able to add any kind of new check to it.

If there was a good framework for writing project-specific static
syntax-and-style-checks that would be great; I don't know of one,
though.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v8 3/6] ui: add keycodemapdb repository as a GIT submodule

[Daniel P . Berrangé]

On Fri, Mar 15, 2019 at 06:35:59PM +, Peter Maydell wrote:
> On Fri, 29 Sep 2017 at 11:12, Daniel P. Berrange  wrote:
> >
> > The https://gitlab.com/keycodemap/keycodemapdb/ repo contains a
> > data file mapping between all the different scancode/keycode/keysym
> > sets that are known, and a tool to auto-generate lookup tables for
> > different combinations
> 
> Hi Dan; apologies for hauling up this commit from 2017, but
> I just noticed something while reading through configure:
> 
> > diff --git a/configure b/configure
> > index b324e057f1..eb420abc47 100755
> > --- a/configure
> > +++ b/configure
> > @@ -264,7 +264,13 @@ cc_i386=i386-pc-linux-gnu-gcc
> >  libs_qga=""
> >  debug_info="yes"
> >  stack_protector=""
> > -git_submodules=""
> > +
> > +if test -e "$source_path/.git"
> > +then
> > +git_submodules="ui/keycodemapdb"
> > +else
> > +git_submodules=""
> > +fi
> 
> Configure has a --source-path option, which overrides the
> default $source_path setting (of the directory where the
> configure script lives), but this commit (927128222b0a91f56c13a)
> added a use of $source_path before the part of configure that
> parses the option and updates $source_path accordingly.
> Could this lump of code (and the later enhancements to it) be moved
> further down in the file?
> 
> (Alternatively, we could drop the --source-path option entirely:
> I didn't even know it existed and I'm not sure it's very
> useful...)

I checked the history of this and it dates from 2003 when Fabrice
first created the 'configure' script.

Normally we find source path based on where 'configure' exists. I
can't think of a compelling case where 'configure' would not be in
the source path, so I agree we could just drop the option.

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

[Qemu-devel] [PULL 1/3] ati-vga: fix tracing

[Gerd Hoffmann]

HWADDR_PRIx can't be used in tracing, use PRIx64 instead.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Markus Armbruster 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefan Hajnoczi 
Message-id: 20190312081143.24850-1-kra...@redhat.com
---
 hw/display/trace-events | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/display/trace-events b/hw/display/trace-events
index 80993cc4d913..c09854314b03 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -140,5 +140,5 @@ sii9022_write_reg(uint8_t addr, uint8_t val) "addr 0x%02x, 
val 0x%02x"
 sii9022_switch_mode(const char *mode) "mode: %s"
 
 # hw/display/ati*.c
-ati_mm_read(unsigned int size, uint64_t addr, const char *name, uint64_t val) 
"%u 0x%"HWADDR_PRIx " %s -> 0x%"PRIx64
-ati_mm_write(unsigned int size, uint64_t addr, const char *name, uint64_t val) 
"%u 0x%"HWADDR_PRIx " %s <- 0x%"PRIx64
+ati_mm_read(unsigned int size, uint64_t addr, const char *name, uint64_t val) 
"%u 0x%"PRIx64 " %s -> 0x%"PRIx64
+ati_mm_write(unsigned int size, uint64_t addr, const char *name, uint64_t val) 
"%u 0x%"PRIx64 " %s <- 0x%"PRIx64
-- 
2.18.1

[Qemu-devel] [PULL 2/3] virtio-gpu: delay virglrenderer reset when blocked.

[Gerd Hoffmann]

If renderer_blocked is set do not call virtio_gpu_virgl_reset().
Instead set a flag indicating that virglrenderer needs a reset.
When renderer_blocked gets cleared do the actual reset call.

Without this we can trigger an assert in spice due to calling
spice_qxl_gl_scanout() while another operation is still running:

spice_qxl_gl_scanout: condition `qxl_state->gl_draw_cookie == 
GL_DRAW_COOKIE_INVALID' failed

Signed-off-by: Gerd Hoffmann 
Message-id: 20190314115358.26678-2-kra...@redhat.com
---
 include/hw/virtio/virtio-gpu.h |  1 +
 hw/display/virtio-gpu.c| 12 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index ce0ca7217175..60425c5d58dc 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -113,6 +113,7 @@ typedef struct VirtIOGPU {
 bool use_virgl_renderer;
 bool renderer_inited;
 int renderer_blocked;
+bool renderer_reset;
 QEMUTimer *fence_poll;
 QEMUTimer *print_stats;
 
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 4dbf48e42482..fbd8d908ad32 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1084,6 +1084,12 @@ static void virtio_gpu_gl_block(void *opaque, bool block)
 assert(g->renderer_blocked >= 0);
 
 if (g->renderer_blocked == 0) {
+#ifdef CONFIG_VIRGL
+if (g->renderer_reset) {
+g->renderer_reset = false;
+virtio_gpu_virgl_reset(g);
+}
+#endif
 virtio_gpu_process_cmdq(g);
 }
 }
@@ -1368,7 +1374,11 @@ static void virtio_gpu_reset(VirtIODevice *vdev)
 
 #ifdef CONFIG_VIRGL
 if (g->use_virgl_renderer) {
-virtio_gpu_virgl_reset(g);
+if (g->renderer_blocked) {
+g->renderer_reset = true;
+} else {
+virtio_gpu_virgl_reset(g);
+}
 g->use_virgl_renderer = 0;
 }
 #endif
-- 
2.18.1

[Qemu-devel] [PULL 0/3] Vga 20190318 patches

[Gerd Hoffmann]

The following changes since commit d4e65539e570d5872003710b5a1064489911d33d:

  Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190316' into 
staging (2019-03-17 14:10:52 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/vga-20190318-pull-request

for you to fetch changes up to dc84ed5b57cc6d06955e2f49ade9dca277e92cd4:

  virtio-gpu: clear command and fence queues on reset (2019-03-18 13:10:57 
+0100)


vga: fixes for 4.0 (ati trace, virtio-gpu reset).



Gerd Hoffmann (3):
  ati-vga: fix tracing
  virtio-gpu: delay virglrenderer reset when blocked.
  virtio-gpu: clear command and fence queues on reset

 include/hw/virtio/virtio-gpu.h |  1 +
 hw/display/virtio-gpu.c| 26 +-
 hw/display/trace-events|  4 ++--
 3 files changed, 28 insertions(+), 3 deletions(-)

-- 
2.18.1