Re: [PATCH] hw/ide: Remove status register read side effect

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200221065015.337915-1-jasper.low...@bt.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  TESTcheck-qtest-x86_64: tests/qtest/ide-test
  TESTcheck-unit: tests/test-iov
**
ERROR:/tmp/qemu-test/src/tests/qtest/ide-test.c:294:send_dma_request: assertion 
failed: (!qtest_get_irq(qts, IDE_PRIMARY_IRQ))
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/qtest/ide-test.c:294:send_dma_request: assertion 
failed: (!qtest_get_irq(qts, IDE_PRIMARY_IRQ))
make: *** [check-qtest-x86_64] Error 1
make: *** Waiting for unfinished jobs
  TESTcheck-unit: tests/test-bitmap
  TESTcheck-unit: tests/test-aio
---
  TESTiotest-qcow2: 283
Failures: 161
Failed 1 of 116 iotests
make: *** [check-tests/check-block.sh] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 664, in 
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=3349986ab83849d5b475dd101bed4f05', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-gw5__giy/src/docker-src.2020-02-21-02.54.48.27828:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=3349986ab83849d5b475dd101bed4f05
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-gw5__giy/src'
make: *** [docker-run-test-quick@centos7] Error 2

real13m27.186s
user0m9.054s


The full log is available at
http://patchew.org/logs/20200221065015.337915-1-jasper.low...@bt.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v2 0/2] docs: rstfy some s390 docs

[Cornelia Huck]

On Thu, 13 Feb 2020 17:29:40 +0100
Cornelia Huck  wrote:

> https://qemu.readthedocs.io/en/latest/index.html collects various
> documents from the QEMU docs/ subdirectory; however, none of the
> s390 files are currently included. Therefore, I set out to convert
> the existing files to rst and hook them up.
> 
> s390-dasd-ipl was straightforward enough; I also found a numbering
> issue.
> 
> vfio-ap was quite a bit more involved, but I hope I have produced
> something readable (more review can never hurt...) I also
> moved this into the system/ subdirectory; not sure if that is the
> best resting place, but it seemed to be the most reasonable one.
> 
> Tested via running 'make html' and inspecting the output.
> 
> Branch: https://github.com/cohuck/qemu rstfy-s390-v2
> 
> Changes v1->v2 (mostly addressing feedback from Peter; thanks!):
> - dasd ipl: fix some indentation
> - vfio-ap: autogenerate contents table
> - vfio-ap: use more literals
> - vfio-ap: convert some examples to tables
> - vfio-ap: various other formatting cleanups 
> 
> Cornelia Huck (2):
>   docs: rstfy s390 dasd ipl documentation
>   docs: rstfy vfio-ap documentation
> 
>  MAINTAINERS   |   4 +-
>  docs/devel/index.rst  |   1 +
>  .../{s390-dasd-ipl.txt => s390-dasd-ipl.rst}  | 119 +--
>  docs/system/index.rst |   1 +
>  docs/{vfio-ap.txt => system/vfio-ap.rst}  | 796 +-
>  5 files changed, 484 insertions(+), 437 deletions(-)
>  rename docs/devel/{s390-dasd-ipl.txt => s390-dasd-ipl.rst} (51%)
>  rename docs/{vfio-ap.txt => system/vfio-ap.rst} (55%)
> 
> 
> base-commit: 81f49abaaac2b88062bd1b07f451d9527ed1c9ce

Queued to s390-next.

Re: [PATCH] hw/char/pl011: Enable TxFIFO and async transmission

[Paolo Bonzini]

On 21/02/20 05:49, Gavin Shan wrote:
> @@ -306,6 +362,7 @@ static const VMStateDescription vmstate_pl011 = {
>  VMSTATE_UINT32(int_enabled, PL011State),
>  VMSTATE_UINT32(int_level, PL011State),
>  VMSTATE_UINT32_ARRAY(read_fifo, PL011State, 16),
> +VMSTATE_UINT8_ARRAY(write_fifo, PL011State, 16),
>  VMSTATE_UINT32(ilpr, PL011State),
>  VMSTATE_UINT32(ibrd, PL011State),
>  VMSTATE_UINT32(fbrd, PL011State),
> @@ -313,6 +370,7 @@ static const VMStateDescription vmstate_pl011 = {
>  VMSTATE_INT32(read_pos, PL011State),
>  VMSTATE_INT32(read_count, PL011State),
>  VMSTATE_INT32(read_trigger, PL011State),
> +VMSTATE_INT32(write_count, PL011State),

Hi Gavin, please add these two fields to a subsection, so that they are
emitted only if write_count > 0.

Thanks!

Paolo

>  VMSTATE_END_OF_LIST()
>  }
>  };
> diff --git a/include/hw/char/pl011.h b/include/hw/char/pl011.h
> index 14187165c6..aeaf332eca 100644
> --- a/include/hw/char/pl011.h
> +++ b/include/hw/char/pl011.h
> @@ -38,6 +38,7 @@ typedef struct PL011State {
>  uint32_t int_enabled;
>  uint32_t int_level;
>  uint32_t read_fifo[16];
> +uint8_t  write_fifo[16];
>  uint32_t ilpr;
>  uint32_t ibrd;
>  uint32_t fbrd;
> @@ -45,6 +46,7 @@ typedef struct PL011State {
>  int read_pos;
>  int read_count;
>  int read_trigger;
> +int write_count;
>  CharBackend chr;
>  qemu_irq irq[6];
>  const unsigned char *id;
> 

Re: [PATCH qemu v7 0/5] spapr: Kill SLOF

[Paolo Bonzini]

On 21/02/20 01:18, Alexey Kardashevskiy wrote:
> I am not quite sure I understood the request.  Write my own small
> firmware and replace GRUB with it? The firmware from 5/5 reads first 2
> sectors and the entire PReP, I could add there stuff if that helps (I
> have "work in progress" patch for the firmware with printk/etc borrowed
> from SLOF).

Okay, that's great!  I'll take a look next week.

Thanks,

Paolo

>>  (Also, I lost the pointer to your super-minimal
>> pSeries firmware).
>
> It is incorporated into these patches under /pc-bios/vof - 4/5 has the
> minimum (may be even too much), 5/5 has MBR+GPT+ELF.

Re: [PATCH v1 10/13] migrate/ram: Handle RAM block resizes during postcopy

[David Hildenbrand]

On 20.02.20 21:54, Peter Xu wrote:
> On Wed, Feb 19, 2020 at 05:17:22PM +0100, David Hildenbrand wrote:
>> Resizing while migrating is dangerous and does not work as expected.
>> The whole migration code works on the usable_length of ram blocks and does
>> not expect this to change at random points in time.
>>
>> In the case of postcopy, relying on used_length is racy as soon as the
>> guest is running. Also, when used_length changes we might leave the
>> uffd handler registered for some memory regions, reject valid pages
>> when migrating and fail when sending the recv bitmap to the source.
>>
>> Resizing can be trigger *after* (but not during) a reset in
>> ACPI code by the guest
>> - hw/arm/virt-acpi-build.c:acpi_ram_update()
>> - hw/i386/acpi-build.c:acpi_ram_update()
>>
>> Let's remember the original used_length in a separate variable and
>> use it in relevant postcopy code. Make sure to update it when we resize
>> during precopy, when synchronizing the RAM block sizes with the source.
>>
>> Cc: "Dr. David Alan Gilbert" 
>> Cc: Juan Quintela 
>> Cc: Eduardo Habkost 
>> Cc: Paolo Bonzini 
>> Cc: Igor Mammedov 
>> Cc: "Michael S. Tsirkin" 
>> Cc: Richard Henderson 
>> Cc: Shannon Zhao 
>> Cc: Alex Bennée 
>> Cc: Peter Xu 
>> Signed-off-by: David Hildenbrand 
>> ---
>>  include/exec/ramblock.h  |  9 +
>>  migration/postcopy-ram.c | 15 ---
>>  migration/ram.c  | 11 +--
>>  3 files changed, 30 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/exec/ramblock.h b/include/exec/ramblock.h
>> index 07d50864d8..0e9e9b346b 100644
>> --- a/include/exec/ramblock.h
>> +++ b/include/exec/ramblock.h
>> @@ -59,6 +59,15 @@ struct RAMBlock {
>>   */
>>  unsigned long *clear_bmap;
>>  uint8_t clear_bmap_shift;
>> +
>> +/*
>> + * RAM block used_length before the guest started running while postcopy
>> + * was active. Once the guest is running, used_length can change. Used 
>> to
>> + * register/unregister uffd handlers and as the size of the recv bitmap.
>> + * Receiving any page beyond this length will bail out, as it could not 
>> have
>> + * been valid on the source.
>> + */
>> +ram_addr_t postcopy_length;
>>  };
>>  #endif
>>  #endif
>> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
>> index a36402722b..c68caf4e42 100644
>> --- a/migration/postcopy-ram.c
>> +++ b/migration/postcopy-ram.c
>> @@ -17,6 +17,7 @@
>>   */
>>  
>>  #include "qemu/osdep.h"
>> +#include "qemu/rcu.h"
>>  #include "exec/target_page.h"
>>  #include "migration.h"
>>  #include "qemu-file.h"
>> @@ -31,6 +32,7 @@
>>  #include "qemu/error-report.h"
>>  #include "trace.h"
>>  #include "hw/boards.h"
>> +#include "exec/ramblock.h"
>>  
>>  /* Arbitrary limit on size of each discard command,
>>   * keeps them around ~200 bytes
>> @@ -456,6 +458,13 @@ static int init_range(RAMBlock *rb, void *opaque)
>>  ram_addr_t length = qemu_ram_get_used_length(rb);
>>  trace_postcopy_init_range(block_name, host_addr, offset, length);
>>  
>> +/*
>> + * Save the used_length before running the guest. In case we have to
>> + * resize RAM blocks when syncing RAM block sizes from the source during
>> + * precopy, we'll update it manually via the ram block notifier.
>> + */
>> +rb->postcopy_length = length;
>> +
>>  /*
>>   * We need the whole of RAM to be truly empty for postcopy, so things
>>   * like ROMs and any data tables built during init must be zero'd
>> @@ -478,7 +487,7 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
>>  const char *block_name = qemu_ram_get_idstr(rb);
>>  void *host_addr = qemu_ram_get_host_addr(rb);
>>  ram_addr_t offset = qemu_ram_get_offset(rb);
>> -ram_addr_t length = qemu_ram_get_used_length(rb);
>> +ram_addr_t length = rb->postcopy_length;
>>  MigrationIncomingState *mis = opaque;
>>  struct uffdio_range range_struct;
>>  trace_postcopy_cleanup_range(block_name, host_addr, offset, length);
>> @@ -600,7 +609,7 @@ static int nhp_range(RAMBlock *rb, void *opaque)
>>  const char *block_name = qemu_ram_get_idstr(rb);
>>  void *host_addr = qemu_ram_get_host_addr(rb);
>>  ram_addr_t offset = qemu_ram_get_offset(rb);
>> -ram_addr_t length = qemu_ram_get_used_length(rb);
>> +ram_addr_t length = rb->postcopy_length;
>>  trace_postcopy_nhp_range(block_name, host_addr, offset, length);
>>  
>>  /*
>> @@ -644,7 +653,7 @@ static int ram_block_enable_notify(RAMBlock *rb, void 
>> *opaque)
>>  struct uffdio_register reg_struct;
>>  
>>  reg_struct.range.start = (uintptr_t)qemu_ram_get_host_addr(rb);
>> -reg_struct.range.len = qemu_ram_get_used_length(rb);
>> +reg_struct.range.len = rb->postcopy_length;
>>  reg_struct.mode = UFFDIO_REGISTER_MODE_MISSING;
>>  
>>  /* Now tell our userfault_fd that it's responsible for this area */
>> diff --git a/migration/ram.c b/migration/ram.c
>> index ab1f5534cf..6d1dcb362c 100644
>> --

Re: [PATCH] maint: Include top-level *.rst files early in git diff

[Stefano Garzarella]

On Thu, Feb 20, 2020 at 10:22:13AM -0600, Eric Blake wrote:
> We are converting more doc files to *.rst rather than *.texi.  Most
> doc files are already listed early in diffs due to our catchall
> docs/*, but a few top-level files get missed by that glob.
> 
> Signed-off-by: Eric Blake 
> ---
> 
> Both *.texi and *.rst entries make sense while we are still converting
> things, but we'll need a followup to drop *.texi when the conversion
> is complete...
> 
>  scripts/git.orderfile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/git.orderfile b/scripts/git.orderfile
> index 1f747b583a9e..abd8a67a2b4e 100644
> --- a/scripts/git.orderfile
> +++ b/scripts/git.orderfile
> @@ -11,6 +11,7 @@
> 
>  # Documentation
>  docs/*
> +*.rst
>  *.texi
> 
>  # build system

Reviewed-by: Stefano Garzarella 

Re: [PATCH v3 08/20] Remove unnecessary cast when using the address_space API

[Cornelia Huck]

On Thu, 20 Feb 2020 14:05:36 +0100
Philippe Mathieu-Daudé  wrote:

> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
> 
> Two lines in hw/net/dp8393x.c that Coccinelle produced that
> were over 80 characters were re-wrapped by hand.
> 
> Suggested-by: Stefan Weil 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  scripts/coccinelle/exec_rw_const.cocci | 15 +-
>  target/i386/hvf/vmx.h  |  2 +-
>  hw/arm/boot.c  |  6 ++
>  hw/dma/rc4030.c|  4 ++--
>  hw/dma/xlnx-zdma.c |  2 +-
>  hw/net/cadence_gem.c   | 21 +--
>  hw/net/dp8393x.c   | 28 +-
>  hw/s390x/css.c |  4 ++--
>  qtest.c| 12 +--
>  target/i386/hvf/x86_mmu.c  |  2 +-
>  target/i386/whpx-all.c |  2 +-
>  target/s390x/mmu_helper.c  |  2 +-
>  12 files changed, 54 insertions(+), 46 deletions(-)
> 

> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> index 844caab408..f27f8c45a5 100644
> --- a/hw/s390x/css.c
> +++ b/hw/s390x/css.c
> @@ -875,7 +875,7 @@ static inline int ida_read_next_idaw(CcwDataStream *cds)
>  return -EINVAL; /* channel program check */
>  }
>  ret = address_space_rw(&address_space_memory, idaw_addr,
> -   MEMTXATTRS_UNSPECIFIED, (void *) &idaw.fmt2,
> +   MEMTXATTRS_UNSPECIFIED, &idaw.fmt2,
> sizeof(idaw.fmt2), false);
>  cds->cda = be64_to_cpu(idaw.fmt2);
>  } else {
> @@ -884,7 +884,7 @@ static inline int ida_read_next_idaw(CcwDataStream *cds)
>  return -EINVAL; /* channel program check */
>  }
>  ret = address_space_rw(&address_space_memory, idaw_addr,
> -   MEMTXATTRS_UNSPECIFIED, (void *) &idaw.fmt1,
> +   MEMTXATTRS_UNSPECIFIED, &idaw.fmt1,
> sizeof(idaw.fmt1), false);
>  cds->cda = be64_to_cpu(idaw.fmt1);
>  if (cds->cda & 0x8000) {

> diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
> index c9f3f34750..0be2f300bb 100644
> --- a/target/s390x/mmu_helper.c
> +++ b/target/s390x/mmu_helper.c
> @@ -106,7 +106,7 @@ static inline bool read_table_entry(CPUS390XState *env, 
> hwaddr gaddr,
>   * We treat them as absolute addresses and don't wrap them.
>   */
>  if (unlikely(address_space_read(cs->as, gaddr, MEMTXATTRS_UNSPECIFIED,
> -(uint8_t *)entry, sizeof(*entry)) !=
> +entry, sizeof(*entry)) !=
>   MEMTX_OK)) {
>  return false;
>  }

s390 parts
Acked-by: Cornelia Huck 

Re: [PATCH v1 10/13] migrate/ram: Handle RAM block resizes during postcopy

[David Hildenbrand]

On 21.02.20 09:35, David Hildenbrand wrote:
> On 20.02.20 21:54, Peter Xu wrote:
>> On Wed, Feb 19, 2020 at 05:17:22PM +0100, David Hildenbrand wrote:
>>> Resizing while migrating is dangerous and does not work as expected.
>>> The whole migration code works on the usable_length of ram blocks and does
>>> not expect this to change at random points in time.
>>>
>>> In the case of postcopy, relying on used_length is racy as soon as the
>>> guest is running. Also, when used_length changes we might leave the
>>> uffd handler registered for some memory regions, reject valid pages
>>> when migrating and fail when sending the recv bitmap to the source.
>>>
>>> Resizing can be trigger *after* (but not during) a reset in
>>> ACPI code by the guest
>>> - hw/arm/virt-acpi-build.c:acpi_ram_update()
>>> - hw/i386/acpi-build.c:acpi_ram_update()
>>>
>>> Let's remember the original used_length in a separate variable and
>>> use it in relevant postcopy code. Make sure to update it when we resize
>>> during precopy, when synchronizing the RAM block sizes with the source.
>>>
>>> Cc: "Dr. David Alan Gilbert" 
>>> Cc: Juan Quintela 
>>> Cc: Eduardo Habkost 
>>> Cc: Paolo Bonzini 
>>> Cc: Igor Mammedov 
>>> Cc: "Michael S. Tsirkin" 
>>> Cc: Richard Henderson 
>>> Cc: Shannon Zhao 
>>> Cc: Alex Bennée 
>>> Cc: Peter Xu 
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  include/exec/ramblock.h  |  9 +
>>>  migration/postcopy-ram.c | 15 ---
>>>  migration/ram.c  | 11 +--
>>>  3 files changed, 30 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/exec/ramblock.h b/include/exec/ramblock.h
>>> index 07d50864d8..0e9e9b346b 100644
>>> --- a/include/exec/ramblock.h
>>> +++ b/include/exec/ramblock.h
>>> @@ -59,6 +59,15 @@ struct RAMBlock {
>>>   */
>>>  unsigned long *clear_bmap;
>>>  uint8_t clear_bmap_shift;
>>> +
>>> +/*
>>> + * RAM block used_length before the guest started running while 
>>> postcopy
>>> + * was active. Once the guest is running, used_length can change. Used 
>>> to
>>> + * register/unregister uffd handlers and as the size of the recv 
>>> bitmap.
>>> + * Receiving any page beyond this length will bail out, as it could 
>>> not have
>>> + * been valid on the source.
>>> + */
>>> +ram_addr_t postcopy_length;
>>>  };
>>>  #endif
>>>  #endif
>>> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
>>> index a36402722b..c68caf4e42 100644
>>> --- a/migration/postcopy-ram.c
>>> +++ b/migration/postcopy-ram.c
>>> @@ -17,6 +17,7 @@
>>>   */
>>>  
>>>  #include "qemu/osdep.h"
>>> +#include "qemu/rcu.h"
>>>  #include "exec/target_page.h"
>>>  #include "migration.h"
>>>  #include "qemu-file.h"
>>> @@ -31,6 +32,7 @@
>>>  #include "qemu/error-report.h"
>>>  #include "trace.h"
>>>  #include "hw/boards.h"
>>> +#include "exec/ramblock.h"
>>>  
>>>  /* Arbitrary limit on size of each discard command,
>>>   * keeps them around ~200 bytes
>>> @@ -456,6 +458,13 @@ static int init_range(RAMBlock *rb, void *opaque)
>>>  ram_addr_t length = qemu_ram_get_used_length(rb);
>>>  trace_postcopy_init_range(block_name, host_addr, offset, length);
>>>  
>>> +/*
>>> + * Save the used_length before running the guest. In case we have to
>>> + * resize RAM blocks when syncing RAM block sizes from the source 
>>> during
>>> + * precopy, we'll update it manually via the ram block notifier.
>>> + */
>>> +rb->postcopy_length = length;
>>> +
>>>  /*
>>>   * We need the whole of RAM to be truly empty for postcopy, so things
>>>   * like ROMs and any data tables built during init must be zero'd
>>> @@ -478,7 +487,7 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
>>>  const char *block_name = qemu_ram_get_idstr(rb);
>>>  void *host_addr = qemu_ram_get_host_addr(rb);
>>>  ram_addr_t offset = qemu_ram_get_offset(rb);
>>> -ram_addr_t length = qemu_ram_get_used_length(rb);
>>> +ram_addr_t length = rb->postcopy_length;
>>>  MigrationIncomingState *mis = opaque;
>>>  struct uffdio_range range_struct;
>>>  trace_postcopy_cleanup_range(block_name, host_addr, offset, length);
>>> @@ -600,7 +609,7 @@ static int nhp_range(RAMBlock *rb, void *opaque)
>>>  const char *block_name = qemu_ram_get_idstr(rb);
>>>  void *host_addr = qemu_ram_get_host_addr(rb);
>>>  ram_addr_t offset = qemu_ram_get_offset(rb);
>>> -ram_addr_t length = qemu_ram_get_used_length(rb);
>>> +ram_addr_t length = rb->postcopy_length;
>>>  trace_postcopy_nhp_range(block_name, host_addr, offset, length);
>>>  
>>>  /*
>>> @@ -644,7 +653,7 @@ static int ram_block_enable_notify(RAMBlock *rb, void 
>>> *opaque)
>>>  struct uffdio_register reg_struct;
>>>  
>>>  reg_struct.range.start = (uintptr_t)qemu_ram_get_host_addr(rb);
>>> -reg_struct.range.len = qemu_ram_get_used_length(rb);
>>> +reg_struct.range.len = rb->postcopy_length;
>>>  reg_struct.mode = UFFDIO_REGISTER_MODE_MISSI

Re: [PATCH v3 19/20] Let cpu_[physical]_memory() calls pass a boolean 'is_write' argument

[Cornelia Huck]

On Thu, 20 Feb 2020 14:05:47 +0100
Philippe Mathieu-Daudé  wrote:

> Use an explicit boolean type.
> 
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  scripts/coccinelle/exec_rw_const.cocci | 14 ++
>  include/exec/cpu-common.h  |  4 ++--
>  hw/display/exynos4210_fimd.c   |  3 ++-
>  hw/display/milkymist-tmu2.c|  8 
>  hw/display/omap_dss.c  |  2 +-
>  hw/display/ramfb.c |  2 +-
>  hw/misc/pc-testdev.c   |  2 +-
>  hw/nvram/spapr_nvram.c |  4 ++--
>  hw/ppc/ppc440_uc.c |  6 --
>  hw/ppc/spapr_hcall.c   |  4 ++--
>  hw/s390x/ipl.c |  2 +-
>  hw/s390x/s390-pci-bus.c|  2 +-
>  hw/s390x/virtio-ccw.c  |  2 +-
>  hw/xen/xen_pt_graphics.c   |  2 +-
>  target/i386/hax-all.c  |  4 ++--
>  target/s390x/excp_helper.c |  2 +-
>  target/s390x/helper.c  |  6 +++---
>  17 files changed, 43 insertions(+), 26 deletions(-)
> 

> diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> index 7773499d7f..0817874b48 100644
> --- a/hw/s390x/ipl.c
> +++ b/hw/s390x/ipl.c
> @@ -626,7 +626,7 @@ static void s390_ipl_prepare_qipl(S390CPU *cpu)
>  uint8_t *addr;
>  uint64_t len = 4096;
>  
> -addr = cpu_physical_memory_map(cpu->env.psa, &len, 1);
> +addr = cpu_physical_memory_map(cpu->env.psa, &len, true);
>  if (!addr || len < QIPL_ADDRESS + sizeof(QemuIplParameters)) {
>  error_report("Cannot set QEMU IPL parameters");
>  return;
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 7c6a2b3c63..ed8be124da 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -641,7 +641,7 @@ static uint8_t set_ind_atomic(uint64_t ind_loc, uint8_t 
> to_be_set)
>  hwaddr len = 1;
>  uint8_t *ind_addr;
>  
> -ind_addr = cpu_physical_memory_map(ind_loc, &len, 1);
> +ind_addr = cpu_physical_memory_map(ind_loc, &len, true);
>  if (!ind_addr) {
>  s390_pci_generate_error_event(ERR_EVENT_AIRERR, 0, 0, 0, 0);
>  return -1;
> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> index 13f57e7b67..50cf95b781 100644
> --- a/hw/s390x/virtio-ccw.c
> +++ b/hw/s390x/virtio-ccw.c
> @@ -790,7 +790,7 @@ static uint8_t virtio_set_ind_atomic(SubchDev *sch, 
> uint64_t ind_loc,
>  hwaddr len = 1;
>  uint8_t *ind_addr;
>  
> -ind_addr = cpu_physical_memory_map(ind_loc, &len, 1);
> +ind_addr = cpu_physical_memory_map(ind_loc, &len, true);
>  if (!ind_addr) {
>  error_report("%s(%x.%x.%04x): unable to access indicator",
>   __func__, sch->cssid, sch->ssid, sch->schid);

> diff --git a/target/s390x/excp_helper.c b/target/s390x/excp_helper.c
> index 1e9d6f20c1..3b58d10df3 100644
> --- a/target/s390x/excp_helper.c
> +++ b/target/s390x/excp_helper.c
> @@ -393,7 +393,7 @@ static int mchk_store_vregs(CPUS390XState *env, uint64_t 
> mcesao)
>  MchkExtSaveArea *sa;
>  int i;
>  
> -sa = cpu_physical_memory_map(mcesao, &len, 1);
> +sa = cpu_physical_memory_map(mcesao, &len, true);
>  if (!sa) {
>  return -EFAULT;
>  }
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index a3a49164e4..b810ad431e 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -151,7 +151,7 @@ LowCore *cpu_map_lowcore(CPUS390XState *env)
>  LowCore *lowcore;
>  hwaddr len = sizeof(LowCore);
>  
> -lowcore = cpu_physical_memory_map(env->psa, &len, 1);
> +lowcore = cpu_physical_memory_map(env->psa, &len, true);
>  
>  if (len < sizeof(LowCore)) {
>  cpu_abort(env_cpu(env), "Could not map lowcore\n");
> @@ -246,7 +246,7 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool 
> store_arch)
>  hwaddr len = sizeof(*sa);
>  int i;
>  
> -sa = cpu_physical_memory_map(addr, &len, 1);
> +sa = cpu_physical_memory_map(addr, &len, true);
>  if (!sa) {
>  return -EFAULT;
>  }
> @@ -298,7 +298,7 @@ int s390_store_adtl_status(S390CPU *cpu, hwaddr addr, 
> hwaddr len)
>  hwaddr save = len;
>  int i;
>  
> -sa = cpu_physical_memory_map(addr, &save, 1);
> +sa = cpu_physical_memory_map(addr, &save, true);
>  if (!sa) {
>  return -EFAULT;
>  }

s390 parts
Acked-by: Cornelia Huck 

Re: [PATCH v1 13/13] migrate/ram: Tolerate partially changed mappings in postcopy code

[David Hildenbrand]

On 20.02.20 22:07, Peter Xu wrote:
> On Thu, Feb 20, 2020 at 12:24:42PM +0100, David Hildenbrand wrote:
>> On 19.02.20 17:17, David Hildenbrand wrote:
>>> When we partially change mappings (e.g., mmap over parts of an existing
>>> mmap) where we have a userfaultfd handler registered, the handler will
>>> implicitly be unregistered from the parts that changed. This is e.g., the
>>> case when doing a qemu_ram_remap(), but is also a preparation for RAM
>>> blocks with resizable allocations and we're shrinking RAM blocks.
>>>
>>> When the mapping is changed and the handler is removed, any waiters are
>>> woken up. Trying to place pages will fail. We can simply ignore erors
>>> due to that when placing pages - as the mapping changed on the migration
>>> destination, also the content is stale. E.g., after shrinking a RAM
>>> block, nobody should be using that memory. After doing a
>>> qemu_ram_remap(), the old memory is expected to have vanished.
>>>
>>> Let's tolerate such errors (but still warn for now) when placing pages.
>>> Also, add a comment why unregistering will continue to work even though
>>> the mapping might have changed.
>>>
>>> Cc: "Dr. David Alan Gilbert" 
>>> Cc: Juan Quintela 
>>> Cc: Peter Xu 
>>> Cc: Andrea Arcangeli 
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  migration/postcopy-ram.c | 43 ++--
>>>  1 file changed, 37 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
>>> index c68caf4e42..df9d27c004 100644
>>> --- a/migration/postcopy-ram.c
>>> +++ b/migration/postcopy-ram.c
>>> @@ -506,6 +506,13 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
>>>  range_struct.start = (uintptr_t)host_addr;
>>>  range_struct.len = length;
>>>  
>>> +/*
>>> + * In case the mapping was partially changed since we enabled userfault
>>> + * (esp. when whrinking RAM blocks and we have resizable allocations, 
>>> or
>>> + * via qemu_ram_remap()), the userfaultfd handler was already removed 
>>> for
>>> + * the mappings that changed. Unregistering will, however, still work 
>>> and
>>> + * ignore mappings without a registered handler.
>>> + */
>>>  if (ioctl(mis->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
>>>  error_report("%s: userfault unregister %s", __func__, 
>>> strerror(errno));
>>>  
>>> @@ -1239,10 +1246,28 @@ int postcopy_place_page(MigrationIncomingState 
>>> *mis, void *host, void *from,
>>>   */
>>>  if (qemu_ufd_copy_ioctl(mis->userfault_fd, host, from, pagesize, rb)) {
>>>  int e = errno;
>>> -error_report("%s: %s copy host: %p from: %p (size: %zd)",
>>> - __func__, strerror(e), host, from, pagesize);
>>>  
>>> -return -e;
>>> +/*
>>> + * When the mapping gets partially changed before we try to place 
>>> a page
>>> + * (esp. when whrinking RAM blocks and we have resizable 
>>> allocations, or
>>> + * via qemu_ram_remap()), the userfaultfd handler will be removed 
>>> and
>>> + * placing pages will fail. In that case, any waiter was already 
>>> woken
>>> + * up when the mapping was changed. We can safely ignore this, as
>>> + * mappings that change once we're running on the destination imply
>>> + * that memory of these mappings vanishes. Let's still print a 
>>> warning
>>> + * for now.
>>> + *
>>
>> After talking to Andrea, on mapping changes, no waiter will be woken up
>> automatically. We have to do an UFFDIO_WAKE, which even works when there
>> is no longer a handler registered for that reason. Interesting stuff :)
> 
> Yes actually it makes sense. :)
> 
> Though I do think it should hardly happen, otherwise even if it's
> waked up it'll still try to access that GPA and KVM will be confused
> on that and exit because no memslot was setup for that.  Then I think
> it's a fatal VM error.  In other words, I feel like the resizing
> should be blocked somehow by that stall vcpu too (e.g., even if we
> want to reboot a Linux guest, it'll sync between vcpus, and same to
> bootstraping).

I am actually not concerned about KVM. More about some QEMU thread that
accesses bad RAM block state. With resizable allocations that thread
would get a segfault - here it could happen that it simply waits
forever. I guess a segfault would be better to debug than some thread
being stuck waiting for a uffd.

I do agree that this might be very rare (IOW, a BUG in the code :) ).
And we might skip the wakeup for now. But we should set the page
received in the bitmap, even if placement failed due to changed mappings.

Resizes are properly synchronized with KVM suing memory listeners. E.g.,
with resizable allocations, we will only shrink the RAM block *after*
the kvm slots where modified. (resizing kvm slots while VCPUs are in KVM
is a different problem to solve on my side :) )

> 
> Btw, I feel like we cannot always depend on the fact th

Re: [PATCH 1/2] riscv: roms: Add 32-bit OpenSBI firmware image for sifive_u

[Philippe Mathieu-Daudé]

On 2/21/20 6:54 AM, Anup Patel wrote:

On Fri, Feb 21, 2020 at 8:08 AM Bin Meng  wrote:


Hi Philippe,

On Fri, Feb 21, 2020 at 1:31 AM Philippe Mathieu-Daudé
 wrote:


Hi Bin,

On 2/20/20 3:42 PM, Bin Meng wrote:

Although the real world SiFive HiFive Unleashed board is a 64-bit
hardware configuration, with QEMU it is possible to test 32-bit
configuration with the same hardware features.

This updates the roms Makefile to add the build rules for creating
the 32-bit OpenSBI firmware image for sifive_u machine. A pre-built
OpenSBI image (built from commit 3e7d666) has been added as the
default bios for 32-bit sifive_u machine.


With QEMU:

fatal: ambiguous argument '3e7d666': unknown revision or path not in the
working tree.

This looks like an OpenSBI commit but QEMU only include up to v0.5.

Can you build v0.5? Else can you update the submodule?



Will do in v2.


We plan to release OpenSBI v0.6 on monday (24th Feb 2020) so maybe
you can update all RISC-V ROM images based on OpenSBI v0.6 ??


Sounds cleaner.

Suggestions when updating a QEMU git-submodule:


- Include output of submodule 'git-log --reverse --oneline'

- Send series/pull-request with 'git-format-patch --no-binary'






Also, can you add a CI job to build this, so we have reproducible builds
(see QEMU commit 71920809ceabed as example)?


I cannot find any document for how to test CI job with gitlab CI. Does
QEMU has a public CI runner for testing?


There is:

https://wiki.qemu.org/Testing
https://wiki.qemu.org/Testing/CI

Currently you can use whatever CI best suits you (although long term is 
probably to rely more on GitLab, because it allows adding runners on 
particular hardware/setup).




Regards,
Bin



Regards,
Anup

Re: [Virtio-fs] [PATCH] virtiofsd: Remove fuse.h and struct fuse_module

[Stefan Hajnoczi]

On Fri, Feb 21, 2020 at 02:55:15PM +0800, Xiao Yang wrote:
> All code in fuse.h and struct fuse_module are not used by virtiofsd
> so removing them is safe.
> 
> Signed-off-by: Xiao Yang 
> ---
>  tools/virtiofsd/fuse.h   | 1229 --
>  tools/virtiofsd/fuse_i.h |   16 -
>  2 files changed, 1245 deletions(-)
>  delete mode 100644 tools/virtiofsd/fuse.h

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v1 1/2] linux-user: Protect more syscalls

[Philippe Mathieu-Daudé]

On 2/21/20 12:18 AM, Alistair Francis wrote:

New y2038 safe 32-bit architectures (like RISC-V) don't support old
syscalls with a 32-bit time_t. The kernel defines new *_time64 versions
of these syscalls. Add some more #ifdefs to syscall.c in linux-user to
allow us to compile without these old syscalls.

Signed-off-by: Alistair Francis 
---
  linux-user/strace.c  |  2 ++
  linux-user/syscall.c | 18 ++
  2 files changed, 20 insertions(+)

diff --git a/linux-user/strace.c b/linux-user/strace.c
index 3d4d684450..2eb8ae3d31 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -770,6 +770,7 @@ print_syscall_ret_newselect(const struct syscallname *name, 
abi_long ret)
  #define TARGET_TIME_OOP  3   /* leap second in progress */
  #define TARGET_TIME_WAIT 4   /* leap second has occurred */
  #define TARGET_TIME_ERROR5   /* clock not synchronized */
+#ifdef TARGET_NR_adjtimex
  static void
  print_syscall_ret_adjtimex(const struct syscallname *name, abi_long ret)
  {
@@ -808,6 +809,7 @@ print_syscall_ret_adjtimex(const struct syscallname *name, 
abi_long ret)
  
  gemu_log("\n");

  }
+#endif
  
  UNUSED static struct flags access_flags[] = {

  FLAG_GENERIC(F_OK),
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index c930577686..44632a7f6a 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -738,8 +738,10 @@ safe_syscall3(ssize_t, read, int, fd, void *, buff, 
size_t, count)
  safe_syscall3(ssize_t, write, int, fd, const void *, buff, size_t, count)
  safe_syscall4(int, openat, int, dirfd, const char *, pathname, \
int, flags, mode_t, mode)
+#if defined(TARGET_NR_wait4)
  safe_syscall4(pid_t, wait4, pid_t, pid, int *, status, int, options, \
struct rusage *, rusage)
+#endif
  safe_syscall5(int, waitid, idtype_t, idtype, id_t, id, siginfo_t *, infop, \
int, options, struct rusage *, rusage)
  safe_syscall3(int, execve, const char *, filename, char **, argv, char **, 
envp)
@@ -776,8 +778,10 @@ safe_syscall4(int, rt_sigtimedwait, const sigset_t *, 
these, siginfo_t *, uinfo,
const struct timespec *, uts, size_t, sigsetsize)
  safe_syscall4(int, accept4, int, fd, struct sockaddr *, addr, socklen_t *, 
len,
int, flags)
+#if defined(TARGET_NR_nanosleep)
  safe_syscall2(int, nanosleep, const struct timespec *, req,
struct timespec *, rem)
+#endif
  #ifdef TARGET_NR_clock_nanosleep
  safe_syscall4(int, clock_nanosleep, const clockid_t, clock, int, flags,
const struct timespec *, req, struct timespec *, rem)
@@ -1063,6 +1067,7 @@ static inline abi_long host_to_target_rusage(abi_ulong 
target_addr,
  return 0;
  }
  
+#ifdef TARGET_NR_setrlimit

  static inline rlim_t target_to_host_rlim(abi_ulong target_rlim)
  {
  abi_ulong target_rlim_swap;
@@ -1078,7 +1083,9 @@ static inline rlim_t target_to_host_rlim(abi_ulong 
target_rlim)
  
  return result;

  }
+#endif
  
+#if defined(TARGET_NR_getrlimit) || defined (TARGET_NR_ugetrlimit)

  static inline abi_ulong host_to_target_rlim(rlim_t rlim)
  {
  abi_ulong target_rlim_swap;
@@ -1092,6 +1099,7 @@ static inline abi_ulong host_to_target_rlim(rlim_t rlim)
  
  return result;

  }
+#endif
  
  static inline int target_to_host_resource(int code)

  {
@@ -8584,6 +8592,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  }
  }
  return ret;
+#if defined(TARGET_NR_gettimeofday)
  case TARGET_NR_gettimeofday:
  {
  struct timeval tv;
@@ -8594,6 +8603,8 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  }
  }
  return ret;
+#endif
+#if defined(TARGET_NR_settimeofday)
  case TARGET_NR_settimeofday:
  {
  struct timeval tv, *ptv = NULL;
@@ -8615,6 +8626,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  
  return get_errno(settimeofday(ptv, ptz));

  }
+#endif
  #if defined(TARGET_NR_select)
  case TARGET_NR_select:
  #if defined(TARGET_WANT_NI_OLD_SELECT)
@@ -9260,6 +9272,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return do_syscall(cpu_env, arg1 & 0x, arg2, arg3, arg4, arg5,
arg6, arg7, arg8, 0);
  #endif
+#if defined(TARGET_NR_wait4)
  case TARGET_NR_wait4:
  {
  int status;
@@ -9287,6 +9300,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  }
  }
  return ret;
+#endif
  #ifdef TARGET_NR_swapoff
  case TARGET_NR_swapoff:
  if (!(p = lock_user_string(arg1)))
@@ -9431,6 +9445,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return do_vm86(cpu_env, arg1, arg2);
  #endif
  #endif
+#if defined(TARGET_NR_adjtimex)
  case TARGET_NR_adjtimex:
  {
  struct timex host_buf;
@@ -9446,6 

Re: [PATCH] hw/char/pl011: Enable TxFIFO and async transmission

[Gavin Shan]

On 2/21/20 7:25 PM, Paolo Bonzini wrote:

On 21/02/20 05:49, Gavin Shan wrote:

@@ -306,6 +362,7 @@ static const VMStateDescription vmstate_pl011 = {
  VMSTATE_UINT32(int_enabled, PL011State),
  VMSTATE_UINT32(int_level, PL011State),
  VMSTATE_UINT32_ARRAY(read_fifo, PL011State, 16),
+VMSTATE_UINT8_ARRAY(write_fifo, PL011State, 16),
  VMSTATE_UINT32(ilpr, PL011State),
  VMSTATE_UINT32(ibrd, PL011State),
  VMSTATE_UINT32(fbrd, PL011State),
@@ -313,6 +370,7 @@ static const VMStateDescription vmstate_pl011 = {
  VMSTATE_INT32(read_pos, PL011State),
  VMSTATE_INT32(read_count, PL011State),
  VMSTATE_INT32(read_trigger, PL011State),
+VMSTATE_INT32(write_count, PL011State),


Hi Gavin, please add these two fields to a subsection, so that they are
emitted only if write_count > 0.



Hi Paolo, sure, will do in next respin :)

Thanks,
Gavin



  VMSTATE_END_OF_LIST()
  }
  };
diff --git a/include/hw/char/pl011.h b/include/hw/char/pl011.h
index 14187165c6..aeaf332eca 100644
--- a/include/hw/char/pl011.h
+++ b/include/hw/char/pl011.h
@@ -38,6 +38,7 @@ typedef struct PL011State {
  uint32_t int_enabled;
  uint32_t int_level;
  uint32_t read_fifo[16];
+uint8_t  write_fifo[16];
  uint32_t ilpr;
  uint32_t ibrd;
  uint32_t fbrd;
@@ -45,6 +46,7 @@ typedef struct PL011State {
  int read_pos;
  int read_count;
  int read_trigger;
+int write_count;
  CharBackend chr;
  qemu_irq irq[6];
  const unsigned char *id;

Re: [PATCH] target: i386: Check float overflow about register stack

[Paolo Bonzini]

On 21/02/20 04:45, cheng...@emindsoft.com.cn wrote:
>  static inline void fpush(CPUX86State *env)
>  {
> -env->fpstt = (env->fpstt - 1) & 7;
> -env->fptags[env->fpstt] = 0; /* validate stack entry */
> +set_fpstt(env, env->fpstt - 1, false, true);

On overflow fpstt is ~0, so this does:

env->foverflow = true;
env->fpstt = 7;
env->fptags[7] = 0;  /* validate stack entry */

Is this correct?  You are going to set ST0 so the register should not be
marked empty.

>  static inline void fpop(CPUX86State *env)
>  {
> -env->fptags[env->fpstt] = 1; /* invalidate stack entry */
> -env->fpstt = (env->fpstt + 1) & 7;
> +set_fpstt(env, env->fpstt + 1, true, true);

While here:

env->foverflow = true;
env->fptags[7] = 1;
env->fpstt = 0;

>  void helper_fdecstp(CPUX86State *env)
>  {
> -env->fpstt = (env->fpstt - 1) & 7;
> +set_fpstt(env, env->fpstt - 1, false, false);

This is clearing env->foverflow.  But after 8 consecutive fdecstp or
fincstp the result of FXAM should not change.

>  env->fpus &= ~0x4700;
>  }
>  
>  void helper_fincstp(CPUX86State *env)
>  {
> -env->fpstt = (env->fpstt + 1) & 7;
> +set_fpstt(env, env->fpstt + 1, true, false);

Same here.

The actual bug is hinted in helper_fxam_ST0:

/* XXX: test fptags too */

I think the correct fix should be something like

diff --git a/target/i386/fpu_helper.c b/target/i386/fpu_helper.c
index 99f28f267f..792a128a6d 100644
--- a/target/i386/fpu_helper.c
+++ b/target/i386/fpu_helper.c
@@ -991,7 +991,11 @@ void helper_fxam_ST0(CPUX86State *env)
 env->fpus |= 0x200; /* C1 <-- 1 */
 }

-/* XXX: test fptags too */
+if (env->fptags[env->fpstt]) {
+env->fpus |= 0x4100; /* Empty */
+return;
+}
+
 expdif = EXPD(temp);
 if (expdif == MAXEXPD) {
 if (MANTD(temp) == 0x8000ULL) {

Paolo

Re: [PATCH] rcu_queue: add QSLIST functions

[Stefan Hajnoczi]

On Thu, Feb 20, 2020 at 11:38:28AM +0100, Paolo Bonzini wrote:
> QSLIST is the only family of lists for which we do not have RCU-friendly 
> accessors,
> add them.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  include/qemu/queue.h | 15 +++--
>  include/qemu/rcu_queue.h | 47 
>  tests/Makefile.include   |  2 ++
>  tests/test-rcu-list.c| 16 ++
>  tests/test-rcu-slist.c   |  2 ++
>  5 files changed, 80 insertions(+), 2 deletions(-)
>  create mode 100644 tests/test-rcu-slist.c

I'll include this in the pull request that introduces O(1) BHs.

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v1 06/13] migrate/ram: Discard new RAM when growing RAM blocks and the VM is stopped

[David Hildenbrand]

On 19.02.20 17:17, David Hildenbrand wrote:
> In case we grow our RAM after ram_postcopy_incoming_init() (e.g., when
> synchronizing the RAM block state with the migration source), the resized
> part would not get discarded. Let's perform that when being notified
> about a resize while postcopy has been advised and the guest is not
> running yet.
> 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Juan Quintela 
> Cc: Peter Xu 
> Signed-off-by: David Hildenbrand 
> ---
>  migration/ram.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 57f32011a3..cbd54947fb 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3722,6 +3722,25 @@ static void ram_mig_ram_block_resized(RAMBlockNotifier 
> *n, void *host,
>  return;
>  }
>  
> +/*
> + * Especially at the start of precopy on the migration target, before
> + * starting postcopy, we synchronize the RAM block sizes. Let's make sure
> + * that any resizes before starting the guest are properly handled by
> + * postcopy. Note: All other postcopy handling (e.g., registering 
> handlers,
> + * disabling THP) happens after all resizes (e.g., during precopy) were
> + * performed.
> + */

I think it would be clearer to do a

ps >= POSTCOPY_INCOMING_ADVISE && ps < POSTCOPY_INCOMING_RUNNING

We really only want to do something when psotcopy has been advised but
the guest is not running yet.

Will look into that as I find ways to actually test this :)

-- 
Thanks,

David / dhildenb

Re: [PATCH] hw/char/pl011: Output characters using best-effort mode

[Marc Zyngier]

Hi Gavin,

On 2020-02-21 04:24, Gavin Shan wrote:

Hi Peter and Marc,

On 2/20/20 9:10 PM, Peter Maydell wrote:

On Thu, 20 Feb 2020 at 09:10, Marc Zyngier  wrote:

On 2020-02-20 06:01, Gavin Shan wrote:

This fixes the issue by using newly added API
qemu_chr_fe_try_write_all(),
which provides another type of service (best-effort). It's different
from
qemu_chr_fe_write_all() as the data will be dropped if the backend 
has

been running into so-called broken state or 50 attempts of
transmissions.
The broken state is cleared if the data is transmitted at once.


I don't think dropping the serial port output is an acceptable 
outcome.


Agreed. The correct fix for this is the one cryptically described
in the XXX comment this patch deletes:

-/* XXX this blocks entire thread. Rewrite to use
- * qemu_chr_fe_write and background I/O callbacks */

The idea is that essentially we end up emulating the real
hardware's transmit FIFO:
  * as data arrives from the guest we put it in the FIFO
  * we try to send the data with qemu_chr_fe_write(), which does
not block
  * if qemu_chr_fe_write() tells us it did not send all the data,
we use qemu_chr_fe_add_watch() to set up an I/O callback
which will get called when the output chardev has drained
enough that we can try again
  * we make sure all the guest visible registers and mechanisms
for tracking tx fifo level (status bits, interrupts, etc) are
correctly wired up

Then we don't lose data or block QEMU if the guest sends
faster than the chardev backend can handle, assuming the
guest is well-behaved -- just as with a real hardware slow
serial port, the guest will fill the tx fifo and then either poll
or wait for an interrupt telling it that the fifo has drained
before it tries to send more data.

There is an example of this in hw/char/cadence_uart.c
(and an example of how it works for a UART with no tx
fifo in hw/char-cmsdk-apb-uart.c, which is basically the
same except the 'fifo' is just one byte.)

You will also find an awful lot of XXX comments like the
above one in various UART models in hw/char, because
converting an old-style simple blocking UART implementation
to a non-blocking one is a bit fiddly and needs knowledge
of the specifics of the UART behaviour.

The other approach here would be that we could add
options to relevant chardev backends so the user
could say "if you couldn't connect to the tcp server I
specified, throw away data rather than waiting", where
we don't have suitable options already. If the user specifically
tells us they're ok to throw away the serial data, then it's
fine to throw away the serial data :-)



I was intended to convince Marc that it's fine to lose data if the
serial connection is broken with an example. Now, I'm taking the
example trying to convince both of you: Lets assume we have a ARM
board and the UART (RS232) cable is unplugged and plugged in the middle 
of

system booting. I think we would get some output lost. We're emulating
pl011 and I think it would have same behavior. However, I'm not sure
if it makes sense :)


But the case you describe in the commit message is not that one.
The analogy is that of a serial port *plugged* and asserting flow 
control.


Another thing is that the "system" as been constructed this way by the
user. QEMU is not in a position to choose and output what is convenient,
when it is convenient. In my world, the serial output is absolutely
crucial. This is where I look for clues about failures and odd 
behaviours,
and I rely on the serial port emulation to be 100% reliable (and for 
what
it's worth, the Linux kernel can output to the serial port 
asynchronously,

to some extent).

[...]

If above analysis is correct and the first approach doesn't work out. 
We have to
consider the 2nd approach - adding option to backend to allow losing 
data. I'm
going to add "allow-data-lost" option for TYPE_CHARDEV_SOCKET. With the 
option,
a back-off algorithm in tcp_chr_write(): The channel is consider as 
broken if
it fails to transmit data in last continuous 5 times. The transmission 
is still
issued when the channel is in broken state and recovered to normal 
state if

transmission succeeds for once.


That'd be an option if you could configure the UART with something that 
says
"no flow control". In that case, dropping data on the floor becomes 
perfectly

acceptable, as it requires buy-in from the user.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

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

[Howard Spoelstra]

Hi,

It might be worth mentioning that any testing of your screamer
implementation with MacOS/OSX guests on the mac99 machine needs a
custom-built openbios.

Where possible I'll compare your screamer with the current screamer
implementation built from:
git clone -b screamer https://github.com/mcayland/qemu

All tests on OSX Sierra host with system sounds and MP3 playback through
latest QuickTime and iTunes available for the guest. Host is Intel i7-4770K
at 3.50Ghz. 32Gb memory. Audio device is an USB headset.
Overall very subjective impression is that sound problems seem to arise
quicker with strong changes in volume in the stream. Silence is produced
perfectly...
I should note that I also tested earlier with a windows build and that I
had to re-install Mac OS on three occasions to get sound going with your
screamer. Whether that was caused by a faulty installation or your screamer
is unclear to me.

There we go:

Mac OS 9.0.4: mac99,via=cuda
Apple audio extension often fails to load. (Not restricted to your
screamer. This is a longstanding issue.) See at bottom for OSX crash report.
Your screamer: shows only CD in Sound CP Input panel. Play sound through
output device is selected.
Current screamer: shows CD + External Mic. Play sound through output device
is selected.

Mac OS 9.1: mac99,via=cuda
Your screamer: No Input selection in the Sound CP.
Current screamer: Has External Mic (but no CD) in Sound CP. Play sound
through output device is not selected.

Mac OS 9.2: mac99,via=pmu
Your screamer: mp3 through iTunes and QuickTime OK. System sounds OK.
Current screamer: Has considerably more problems playing two streams
simultaneously. (mp3 through both QuickTime and iTunes.)

Mac OS X 10.0: mac99,via=cuda
Your screamer: setting the sound balance from middle position to the left
seems to control volume.
Current screamer: Serious number of drop-outs when playing MP3 through
QuickTime. Not when using iTunes. Has issues when moving the sound balance.

Mac OS X 10.1: mac99,via=cuda
Off-topic: Interestingly, when booting with via=pmu, the same error occurs
as reported above.
Your screamer: QuickTime: drop-outs. iTunes OK, even with playing system
sounds through the stream. Balance has same problem as above.
Current screamer: Serious drop-outs through both QuickTime and iTunes when
playing MP3. Balance sync gets completely lost after moving slider. More
lag in response to clicking system sounds.

Mac OSX 10.2: no test due to longstanding video issue with opening folders.

Mac OSX 10.3: mac99,via=pmu
Your screamer: drop-outs with QuickTime and iTunes. But not the clicks
heard as mentioned below. Opening the Sound preferences when playing MP3 is
OK. System sounds playing through the stream produce crackling sound.
systems sounds stop playing after several clicks on different ones. I hear
parts of earlier clicked sound when new one clicked.
Current screamer: intermittent clicks (0.5 seconds) when playing MP3 with
QuickTime and iTunes. But QuickTime much better compared to 10.1. Currently
playing mp3 gets completely distorted (doubled?) when opening Sound
preferences.

Mac OSX 10.4: mac99,via=pmu
Off-topic: From 10.4 onward, Internet radio works in iTunes. Channel update
is very slow in 10.4...
Your screamer: drop-outs with QuickTime. Sounds comparable to current
screamer. Opening Sound preferences is OK, but can make stream spiral out
of control with an echo. Seems to happen quicker when playing sound with
strong stereo effects. But always quickly recovers, unlike current
screamer. iTunes also produces drop-outs. Also with internet stream, but is
almost listenable.
Current screamer: drop-outs with QuickTime. Sounds like stream is not
always in correct order. Sound crackles. iTunes almost OK. I can hear one
or two clicks after stopping audio. Opening Sound preferences makes stream
spiral out of control with an echo.

Mac OSX 10.5: mac99,via=pmu
Your screamer: Drop-outs with QuickTime. A bit less-so with iTunes. Opening
Sound preferences provides same experience as with 10.4. Internet stream
almost listenable.
Current screamer: QuickTime produces drop-outs. Sound control panel spirals
out of control. Small audio parts still played when stopping QuickTime.
iTunes almost OK with MP3 playback, only small drop-outs. Same with
Internet radio.

For good measure I also tested 10.5 with your screamer and the recent
hardfloat patches which improve fpu performance from 9% to 11% of a real G4
1Ghz ;-)
I did not experience a considerable improvement in sound quality.

Best,
Howard

OSX host Crash report when audio extension fails:

Crashed Thread:2

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x0008
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Segmentation fault: 11
Termination Reason:Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x8:
-->
__TEXT 0001087b-000108f7f000 [ 7

Re: [PATCH v1 05/13] migrate/ram: Handle RAM block resizes during precopy

[David Hildenbrand]

On 20.02.20 21:17, Peter Xu wrote:
> On Thu, Feb 20, 2020 at 04:16:02PM +0100, David Hildenbrand wrote:
>> On 19.02.20 17:17, David Hildenbrand wrote:
>>> Resizing while migrating is dangerous and does not work as expected.
>>> The whole migration code works on the usable_length of ram blocks and does
>>> not expect this to change at random points in time.
>>>
>>> In the case of precopy, the ram block size must not change on the source,
>>> after syncing the RAM block list in ram_save_setup(), so as long as the
>>> guest is still running on the source.
>>>
>>> Resizing can be trigger *after* (but not during) a reset in
>>> ACPI code by the guest
>>> - hw/arm/virt-acpi-build.c:acpi_ram_update()
>>> - hw/i386/acpi-build.c:acpi_ram_update()
>>>
>>> Use the ram block notifier to get notified about resizes. Let's simply
>>> cancel migration and indicate the reason. We'll continue running on the
>>> source. No harm done.
>>>
>>> Update the documentation. Postcopy will be handled separately.
>>>
>>> Cc: "Dr. David Alan Gilbert" 
>>> Cc: Juan Quintela 
>>> Cc: Eduardo Habkost 
>>> Cc: Paolo Bonzini 
>>> Cc: Igor Mammedov 
>>> Cc: "Michael S. Tsirkin" 
>>> Cc: Richard Henderson 
>>> Cc: Shannon Zhao 
>>> Cc: Alex Bennée 
>>> Cc: Peter Xu 
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  exec.c|  5 +++--
>>>  include/exec/memory.h | 10 ++
>>>  migration/migration.c |  9 +++--
>>>  migration/migration.h |  1 +
>>>  migration/ram.c   | 41 +
>>>  5 files changed, 58 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/exec.c b/exec.c
>>> index b75250e773..8b015821d6 100644
>>> --- a/exec.c
>>> +++ b/exec.c
>>> @@ -2120,8 +2120,9 @@ static int memory_try_enable_merging(void *addr, 
>>> size_t len)
>>>  return qemu_madvise(addr, len, QEMU_MADV_MERGEABLE);
>>>  }
>>>  
>>> -/* Only legal before guest might have detected the memory size: e.g. on
>>> - * incoming migration, or right after reset.
>>> +/*
>>> + * Resizing RAM while migrating can result in the migration being canceled.
>>> + * Care has to be taken if the guest might have already detected the 
>>> memory.
>>>   *
>>>   * As memory core doesn't know how is memory accessed, it is up to
>>>   * resize callback to update device state and/or add assertions to detect
>>> diff --git a/include/exec/memory.h b/include/exec/memory.h
>>> index e85b7de99a..de111347e8 100644
>>> --- a/include/exec/memory.h
>>> +++ b/include/exec/memory.h
>>> @@ -113,7 +113,7 @@ typedef struct IOMMUNotifier IOMMUNotifier;
>>>  #define RAM_SHARED (1 << 1)
>>>  
>>>  /* Only a portion of RAM (used_length) is actually used, and migrated.
>>> - * This used_length size can change across reboots.
>>> + * Resizing RAM while migrating can result in the migration being canceled.
>>>   */
>>>  #define RAM_RESIZEABLE (1 << 2)
>>>  
>>> @@ -843,7 +843,9 @@ void 
>>> memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
>>>   * RAM.  Accesses into the region will
>>>   * modify memory directly.  Only an 
>>> initial
>>>   * portion of this RAM is actually 
>>> used.
>>> - * The used size can change across 
>>> reboots.
>>> + * Changing the size while migrating
>>> + * can result in the migration being
>>> + * canceled.
>>>   *
>>>   * @mr: the #MemoryRegion to be initialized.
>>>   * @owner: the object that tracks the region's reference count
>>> @@ -1464,8 +1466,8 @@ void *memory_region_get_ram_ptr(MemoryRegion *mr);
>>>  
>>>  /* memory_region_ram_resize: Resize a RAM region.
>>>   *
>>> - * Only legal before guest might have detected the memory size: e.g. on
>>> - * incoming migration, or right after reset.
>>> + * Resizing RAM while migrating can result in the migration being canceled.
>>> + * Care has to be taken if the guest might have already detected the 
>>> memory.
>>>   *
>>>   * @mr: a memory region created with @memory_region_init_resizeable_ram.
>>>   * @newsize: the new size the region
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index 8fb68795dc..ac9751dbe5 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -175,13 +175,18 @@ void migration_object_init(void)
>>>  }
>>>  }
>>>  
>>> +void migration_cancel(void)
>>> +{
>>> +migrate_fd_cancel(current_migration);
>>> +}
>>> +
>>>  void migration_shutdown(void)
>>>  {
>>>  /*
>>>   * Cancel the current migration - that will (eventually)
>>>   * stop the migration using this structure
>>>   */
>>> -migrate_fd_cancel(current_migration);
>>> +migration_cancel();
>>>  object_unref(OBJECT(current_migration));
>>>  }
>>>  
>>> @@ -2019,7 +2024,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool 
>>> blk,
>>>  
>>>  void qmp_migrat

Re: [PATCH v7 02/11] error: auto propagated local_err

[Markus Armbruster]

Vladimir Sementsov-Ogievskiy  writes:

> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with an errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> can't see this additional information, because exit() happens in
> error_setg earlier than information is added. [Reported by Greg Kurz]
>
> 2. Fix issue with error_abort and error_propagate: when we wrap
> error_abort by local_err+error_propagate, the resulting coredump will
> refer to error_propagate and not to the place where error happened.
> (the macro itself doesn't fix the issue, but it allows us to [3.] drop
> the local_err+error_propagate pattern, which will definitely fix the
> issue) [Reported by Kevin Wolf]
>
> 3. Drop local_err+error_propagate pattern, which is used to workaround
> void functions with errp parameter, when caller wants to know resulting
> status. (Note: actually these functions could be merely updated to
> return int error code).
>
> To achieve these goals, later patches will add invocations
> of this macro at the start of functions with either use
> error_prepend/error_append_hint (solving 1) or which use
> local_err+error_propagate to check errors, switching those
> functions to use *errp instead (solving 2 and 3).
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Reviewed-by: Greg Kurz 
> Reviewed-by: Eric Blake 
> ---
>
> CC: Eric Blake 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: Greg Kurz 
> CC: Stefano Stabellini 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: Stefan Hajnoczi 
> CC: "Philippe Mathieu-Daudé" 
> CC: Laszlo Ersek 
> CC: Gerd Hoffmann 
> CC: Stefan Berger 
> CC: Markus Armbruster 
> CC: Michael Roth 
> CC: qemu-bl...@nongnu.org
> CC: xen-de...@lists.xenproject.org
>
>  include/qapi/error.h | 83 +++-
>  1 file changed, 82 insertions(+), 1 deletion(-)
>
> diff --git a/include/qapi/error.h b/include/qapi/error.h
> index d34987148d..b9452d4806 100644
> --- a/include/qapi/error.h
> +++ b/include/qapi/error.h
> @@ -78,7 +78,7 @@
>   * Call a function treating errors as fatal:
>   * foo(arg, &error_fatal);
>   *
> - * Receive an error and pass it on to the caller:
> + * Receive an error and pass it on to the caller (DEPRECATED*):
>   * Error *err = NULL;
>   * foo(arg, &err);
>   * if (err) {
> @@ -98,6 +98,50 @@
>   * foo(arg, errp);
>   * for readability.
>   *
> + * DEPRECATED* This pattern is deprecated now, the use ERRP_AUTO_PROPAGATE 
> macro
> + * instead (defined below).
> + * It's deprecated because of two things:
> + *
> + * 1. Issue with error_abort and error_propagate: when we wrap error_abort by
> + * local_err+error_propagate, the resulting coredump will refer to
> + * error_propagate and not to the place where error happened.
> + *
> + * 2. A lot of extra code of the same pattern
> + *
> + * How to update old code to use ERRP_AUTO_PROPAGATE?
> + *
> + * All you need is to add ERRP_AUTO_PROPAGATE() invocation at function start,
> + * than you may safely dereference errp to check errors and do not need any
> + * additional local Error variables or calls to error_propagate().
> + *
> + * Example:
> + *
> + * old code
> + *
> + * void fn(..., Error **errp) {
> + * Error *err = NULL;
> + * foo(arg, &err);
> + * if (err) {
> + * handle the error...
> + * error_propagate(errp, err);
> + * return;
> + * }
> + * ...
> + * }
> + *
> + * updated code
> + *
> + * void fn(..., Error **errp) {
> + * ERRP_AUTO_PROPAGATE();
> + * foo(arg, errp);
> + * if (*errp) {
> + * handle the error...
> + * return;
> + * }
> + * ...
> + * }
> + *
> + *
>   * Receive and accumulate multiple errors (first one wins):
>   * Error *err = NULL, *local_err = NULL;
>   * foo(arg, &err);

Let's explain what should be done *first*, and only then talk about the
deprecated pattern and how to convert it to current usage.

> @@ -348,6 +392,43 @@ void error_set_internal(Error **errp,
>  ErrorClass err_class, const char *fmt, ...)
>  GCC_FMT_ATTR(6, 7);
>  
> +typedef struct ErrorPropagator {
> +Error *local_err;
> +Error **errp;
> +} ErrorPropagator;
> +
> +static inline void error_propagator_cleanup(ErrorPropagator *prop)
> +{
> +error_propagate(prop->errp, prop->local_err);
> +}
> +
> +G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(ErrorPropagator, error_propagator_cleanup);
> +
> +/*
> + * ERRP_AUTO_PROPAGATE
> + *
> + * This macro is created to be the first line of a function which use
> + * Error **errp parameter to report error. It's needed only in cases where we
> + * want to use error_prepend, error_append_hint or dereference *errp. It's
> + * still safe (but useless) in other cases.
> + *
> + * If errp is NULL or points to error_fatal, it is rewritten to point to a
> + * local Error object, w

Re: [PATCH v7 01/11] qapi/error: add (Error **errp) cleaning APIs

[Vladimir Sementsov-Ogievskiy]

21.02.2020 10:38, Markus Armbruster wrote:

Vladimir Sementsov-Ogievskiy  writes:


Add functions to clean Error **errp: call corresponding Error *err
cleaning function an set pointer to NULL.

New functions:
   error_free_errp
   error_report_errp
   warn_report_errp

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Greg Kurz 
Reviewed-by: Eric Blake 
---

CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Stefan Hajnoczi 
CC: "Philippe Mathieu-Daudé" 
CC: Laszlo Ersek 
CC: Gerd Hoffmann 
CC: Stefan Berger 
CC: Markus Armbruster 
CC: Michael Roth 
CC: qemu-bl...@nongnu.org
CC: xen-de...@lists.xenproject.org

  include/qapi/error.h | 26 ++
  1 file changed, 26 insertions(+)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index ad5b6e896d..d34987148d 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -309,6 +309,32 @@ void warn_reportf_err(Error *err, const char *fmt, ...)
  void error_reportf_err(Error *err, const char *fmt, ...)
  GCC_FMT_ATTR(2, 3);
  
+/*

+ * Functions to clean Error **errp: call corresponding Error *err cleaning
+ * function, then set pointer to NULL.
+ */
+static inline void error_free_errp(Error **errp)
+{
+assert(errp && *errp);
+error_free(*errp);
+*errp = NULL;
+}
+
+static inline void error_report_errp(Error **errp)
+{
+assert(errp && *errp);
+error_report_err(*errp);
+*errp = NULL;
+}
+
+static inline void warn_report_errp(Error **errp)
+{
+assert(errp && *errp);
+warn_report_err(*errp);
+*errp = NULL;
+}
+
+
  /*
   * Just like error_setg(), except you get to specify the error class.
   * Note: use of error classes other than ERROR_CLASS_GENERIC_ERROR is


These appear to be unused apart from the Coccinelle script in PATCH 03.

They are used in the full "[RFC v5 000/126] error: auto propagated
local_err" series.  Options:

1. Pick a few more patches into this part I series, so these guys come
with users.


It needs some additional effort for this series.. But it's possible. Still,
I think that we at least should not pull out patches which should be in
future series (for example from ppc or block/)..

Grepping through v5:
 for x in {warn_report_errp,error_report_errp,error_free_errp}; do echo == $x 
==; git grep -l $x | grep -v coccinelle | grep -v 'error\.h'; echo; done
== warn_report_errp ==
block/file-posix.c
hw/ppc/spapr.c
hw/ppc/spapr_caps.c
hw/ppc/spapr_irq.c
hw/vfio/pci.c
net/tap.c
qom/object.c

== error_report_errp ==
hw/block/vhost-user-blk.c
util/oslib-posix.c

== error_free_errp ==
block.c
block/qapi.c
block/sheepdog.c
block/snapshot.c
blockdev.c
chardev/char-socket.c
hw/audio/intel-hda.c
hw/core/qdev-properties.c
hw/pci-bridge/pci_bridge_dev.c
hw/pci-bridge/pcie_pci_bridge.c
hw/scsi/megasas.c
hw/scsi/mptsas.c
hw/usb/hcd-xhci.c
io/net-listener.c
migration/colo.c
qga/commands-posix.c
qga/commands-win32.c
util/qemu-sockets.c

What do you want to add?



2. Punt this patch to the first part that has users, along with the
part of the Coccinelle script that deals with them.


But coccinelle script would be wrong, if we drop this part from it. I think,
that after commit which adds coccinelle script, it should work with any file,
not only subset of these series.

So, it's probably OK for now to drop these functions, forcing their addition if
coccinelle script will be applied where these functions are needed. We can, for
example comment these three functions.

Splitting coccinelle script into two parts, which will be in different series 
will
not help any patch-porting processes.

Moreover, this will create dependencies between future series updating other 
files.

So, I don't like [2.]..



3. Do nothing: accept the functions without users.


OK for me)



I habitually dislike 3., but reviewing the rest of this series might
make me override that dislike.





same grep with maintainers:
 for x in {warn_report_errp,error_report_errp,error_free_errp}; do echo == $x 
==; git grep -l $x | grep -v coccinelle | grep -v 'error\.h' | while read f; do 
echo $f; ./scripts/get_maintainer.pl -f --no-rolestats $f | grep -v 
'qemu-block\|qemu-devel' | sed -e 's/^/   /'; done; echo; done
== warn_report_errp ==
block/file-posix.c
   Kevin Wolf 
   Max Reitz 
hw/ppc/spapr.c
   David Gibson 
   qemu-...@nongnu.org
hw/ppc/spapr_caps.c
   David Gibson 
   qemu-...@nongnu.org
hw/ppc/spapr_irq.c
   David Gibson 
   qemu-...@nongnu.org
hw/vfio/pci.c
   Alex Williamson 
net/tap.c
   Jason Wang 
qom/object.c
   Paolo Bonzini 
   "Daniel P. Berrangé" 
   Eduardo Habkost 

== error_report_errp ==
hw/block/vhost-user-blk.c
   "Michael S. Tsirkin" 
   Kevin Wolf 
   Max Reitz 
util/oslib-posix.c
   Paolo Bonzini 

== error_free_errp ==
block.c
   Kevin Wolf 
   Max Reitz 
block/qapi.c
   Markus Armbruster 
   Kevin Wolf 
   Max Reitz 
block/sheepdog.c
   Liu Yuan 
   Kevin Wolf 
   Max Reitz 
   sheep...@lis

Re: [PATCH] hw/char/pl011: Enable TxFIFO and async transmission

[Philippe Mathieu-Daudé]

Cc'ing Igor & Drew.

On 2/21/20 7:28 AM, no-re...@patchew.org wrote:

Patchew URL: https://patchew.org/QEMU/20200221044908.266883-1-gs...@redhat.com/

>

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

[...]
  TESTcheck-qtest-aarch64: tests/qtest/bios-tables-test

**
ERROR:/tmp/qemu-test/src/tests/qtest/acpi-utils.c:145:acpi_find_rsdp_address_uefi:
 code should not be reached
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/qtest/acpi-utils.c:145:acpi_find_rsdp_address_uefi:
 code should not be reached
make: *** [check-qtest-aarch64] Error 1


The virt machine is not happy, busy-looping?

$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 \
  tests/qtest/bios-tables-test
/aarch64/acpi/virt: ^C

[PATCH v3] util/async: make bh_aio_poll() O(1)

[Stefan Hajnoczi]

The ctx->first_bh list contains all created BHs, including those that
are not scheduled.  The list is iterated by the event loop and therefore
has O(n) time complexity with respected to the number of created BHs.

Rewrite BHs so that only scheduled or deleted BHs are enqueued.
Only BHs that actually require action will be iterated.

One semantic change is required: qemu_bh_delete() enqueues the BH and
therefore invokes aio_notify().  The
tests/test-aio.c:test_source_bh_delete_from_cb() test case assumed that
g_main_context_iteration(NULL, false) returns false after
qemu_bh_delete() but it now returns true for one iteration.  Fix up the
test case.

This patch makes aio_compute_timeout() and aio_bh_poll() drop from a CPU
profile reported by perf-top(1).  Previously they combined to 9% CPU
utilization when AioContext polling is commented out and the guest has 2
virtio-blk,num-queues=1 and 99 virtio-blk,num-queues=32 devices.

Signed-off-by: Stefan Hajnoczi 
---
v3:
 * Use QSLIST_FOREACH_RCU() and QSLIST_FIRST_RCU() [Paolo]
v2:
 * Use QSLIST for BHs and QSIMPLEQ for BHListSlices [Paolo]
   (Note that I replaced bh = atomic_rcu_read(&first_bh) with
QSLIST_FOREACH(&bh_list) so there is no memory ordering but I think
this is safe.)
 * Comment clarifications [Paolo]

Based-on: 20200220103828.24525-1-pbonz...@redhat.com
  ("[PATCH] rcu_queue: add QSLIST functions")
---
 include/block/aio.h |  20 +++-
 tests/test-aio.c|   3 +-
 util/async.c| 237 ++--
 3 files changed, 158 insertions(+), 102 deletions(-)

diff --git a/include/block/aio.h b/include/block/aio.h
index 7ba9bd7874..1a2ce9ca26 100644
--- a/include/block/aio.h
+++ b/include/block/aio.h
@@ -51,6 +51,19 @@ struct ThreadPool;
 struct LinuxAioState;
 struct LuringState;
 
+/*
+ * Each aio_bh_poll() call carves off a slice of the BH list, so that newly
+ * scheduled BHs are not processed until the next aio_bh_poll() call.  All
+ * active aio_bh_poll() calls chain their slices together in a list, so that
+ * nested aio_bh_poll() calls process all scheduled bottom halves.
+ */
+typedef QSLIST_HEAD(, QEMUBH) BHList;
+typedef struct BHListSlice BHListSlice;
+struct BHListSlice {
+BHList bh_list;
+QSIMPLEQ_ENTRY(BHListSlice) next;
+};
+
 struct AioContext {
 GSource source;
 
@@ -91,8 +104,11 @@ struct AioContext {
  */
 QemuLockCnt list_lock;
 
-/* Anchor of the list of Bottom Halves belonging to the context */
-struct QEMUBH *first_bh;
+/* Bottom Halves pending aio_bh_poll() processing */
+BHList bh_list;
+
+/* Chained BH list slices for each nested aio_bh_poll() call */
+QSIMPLEQ_HEAD(, BHListSlice) bh_slice_list;
 
 /* Used by aio_notify.
  *
diff --git a/tests/test-aio.c b/tests/test-aio.c
index 86fb73b3d5..8a46078463 100644
--- a/tests/test-aio.c
+++ b/tests/test-aio.c
@@ -615,7 +615,8 @@ static void test_source_bh_delete_from_cb(void)
 g_assert_cmpint(data1.n, ==, data1.max);
 g_assert(data1.bh == NULL);
 
-g_assert(!g_main_context_iteration(NULL, false));
+assert(g_main_context_iteration(NULL, false));
+assert(!g_main_context_iteration(NULL, false));
 }
 
 static void test_source_bh_delete_from_cb_many(void)
diff --git a/util/async.c b/util/async.c
index c192a24a61..b94518b948 100644
--- a/util/async.c
+++ b/util/async.c
@@ -29,6 +29,7 @@
 #include "block/thread-pool.h"
 #include "qemu/main-loop.h"
 #include "qemu/atomic.h"
+#include "qemu/rcu_queue.h"
 #include "block/raw-aio.h"
 #include "qemu/coroutine_int.h"
 #include "trace.h"
@@ -36,16 +37,76 @@
 /***/
 /* bottom halves (can be seen as timers which expire ASAP) */
 
+/* QEMUBH::flags values */
+enum {
+/* Already enqueued and waiting for aio_bh_poll() */
+BH_PENDING   = (1 << 0),
+
+/* Invoke the callback */
+BH_SCHEDULED = (1 << 1),
+
+/* Delete without invoking callback */
+BH_DELETED   = (1 << 2),
+
+/* Delete after invoking callback */
+BH_ONESHOT   = (1 << 3),
+
+/* Schedule periodically when the event loop is idle */
+BH_IDLE  = (1 << 4),
+};
+
 struct QEMUBH {
 AioContext *ctx;
 QEMUBHFunc *cb;
 void *opaque;
-QEMUBH *next;
-bool scheduled;
-bool idle;
-bool deleted;
+QSLIST_ENTRY(QEMUBH) next;
+unsigned flags;
 };
 
+/* Called concurrently from any thread */
+static void aio_bh_enqueue(QEMUBH *bh, unsigned new_flags)
+{
+AioContext *ctx = bh->ctx;
+unsigned old_flags;
+
+/*
+ * The memory barrier implicit in atomic_fetch_or makes sure that:
+ * 1. idle & any writes needed by the callback are done before the
+ *locations are read in the aio_bh_poll.
+ * 2. ctx is loaded before the callback has a chance to execute and bh
+ *could be freed.
+ */
+old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags);
+if (!(old_flags & BH_PENDING)) {
+QSLIST_INSERT_HEAD_ATOMI

Re: [PATCH v7 02/11] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy]

21.02.2020 12:19, Markus Armbruster wrote:

Vladimir Sementsov-Ogievskiy  writes:


Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.

It has three goals:

1. Fix issue with error_fatal and error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information is added. [Reported by Greg Kurz]

2. Fix issue with error_abort and error_propagate: when we wrap
error_abort by local_err+error_propagate, the resulting coredump will
refer to error_propagate and not to the place where error happened.
(the macro itself doesn't fix the issue, but it allows us to [3.] drop
the local_err+error_propagate pattern, which will definitely fix the
issue) [Reported by Kevin Wolf]

3. Drop local_err+error_propagate pattern, which is used to workaround
void functions with errp parameter, when caller wants to know resulting
status. (Note: actually these functions could be merely updated to
return int error code).

To achieve these goals, later patches will add invocations
of this macro at the start of functions with either use
error_prepend/error_append_hint (solving 1) or which use
local_err+error_propagate to check errors, switching those
functions to use *errp instead (solving 2 and 3).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Greg Kurz 
Reviewed-by: Eric Blake 
---

CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Stefan Hajnoczi 
CC: "Philippe Mathieu-Daudé" 
CC: Laszlo Ersek 
CC: Gerd Hoffmann 
CC: Stefan Berger 
CC: Markus Armbruster 
CC: Michael Roth 
CC: qemu-bl...@nongnu.org
CC: xen-de...@lists.xenproject.org

  include/qapi/error.h | 83 +++-
  1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index d34987148d..b9452d4806 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -78,7 +78,7 @@
   * Call a function treating errors as fatal:
   * foo(arg, &error_fatal);
   *
- * Receive an error and pass it on to the caller:
+ * Receive an error and pass it on to the caller (DEPRECATED*):
   * Error *err = NULL;
   * foo(arg, &err);
   * if (err) {
@@ -98,6 +98,50 @@
   * foo(arg, errp);
   * for readability.
   *
+ * DEPRECATED* This pattern is deprecated now, the use ERRP_AUTO_PROPAGATE 
macro
+ * instead (defined below).
+ * It's deprecated because of two things:
+ *
+ * 1. Issue with error_abort and error_propagate: when we wrap error_abort by
+ * local_err+error_propagate, the resulting coredump will refer to
+ * error_propagate and not to the place where error happened.
+ *
+ * 2. A lot of extra code of the same pattern
+ *
+ * How to update old code to use ERRP_AUTO_PROPAGATE?
+ *
+ * All you need is to add ERRP_AUTO_PROPAGATE() invocation at function start,
+ * than you may safely dereference errp to check errors and do not need any
+ * additional local Error variables or calls to error_propagate().
+ *
+ * Example:
+ *
+ * old code
+ *
+ * void fn(..., Error **errp) {
+ * Error *err = NULL;
+ * foo(arg, &err);
+ * if (err) {
+ * handle the error...
+ * error_propagate(errp, err);
+ * return;
+ * }
+ * ...
+ * }
+ *
+ * updated code
+ *
+ * void fn(..., Error **errp) {
+ * ERRP_AUTO_PROPAGATE();
+ * foo(arg, errp);
+ * if (*errp) {
+ * handle the error...
+ * return;
+ * }
+ * ...
+ * }
+ *
+ *
   * Receive and accumulate multiple errors (first one wins):
   * Error *err = NULL, *local_err = NULL;
   * foo(arg, &err);


Let's explain what should be done *first*, and only then talk about the
deprecated pattern and how to convert it to current usage.


@@ -348,6 +392,43 @@ void error_set_internal(Error **errp,
  ErrorClass err_class, const char *fmt, ...)
  GCC_FMT_ATTR(6, 7);
  
+typedef struct ErrorPropagator {

+Error *local_err;
+Error **errp;
+} ErrorPropagator;
+
+static inline void error_propagator_cleanup(ErrorPropagator *prop)
+{
+error_propagate(prop->errp, prop->local_err);
+}
+
+G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(ErrorPropagator, error_propagator_cleanup);
+
+/*
+ * ERRP_AUTO_PROPAGATE
+ *
+ * This macro is created to be the first line of a function which use
+ * Error **errp parameter to report error. It's needed only in cases where we
+ * want to use error_prepend, error_append_hint or dereference *errp. It's
+ * still safe (but useless) in other cases.
+ *
+ * If errp is NULL or points to error_fatal, it is rewritten to point to a
+ * local Error object, which will be automatically propagated to the original
+ * errp on function exit (see error_propagator_cleanup).
+ *
+ * After invocation of this macro it is always safe to dereference errp
+ * (as it's not NULL 

[PATCH v5 0/4] target-riscv: support vector extension part 1

[LIU Zhiwei]

This is the first part of v5 patchset. The changelog of v5 is only coverd
the part1.

Features:
  * support specification riscv-v-spec-0.7.1.
  * support basic vector extension.
  * support Zvlsseg.
  * support Zvamo.
  * not support Zvediv as it is changing.
  * SLEN always equals VLEN.
  * element width support 8bit, 16bit, 32bit, 64bit.

Changelog:

v5
  * vector registers as direct fields in RISCVCPUState.
  * mov the properties to last patch.
  * check RVV in vs().
  * check if rs1 is x0 in vsetvl/vsetvli.
  * check VILL, EDIV, RESERVED fileds in vsetvl.
v4
  * adjust max vlen to 512 bits.
  * check maximum on elen(64bits).
  * check minimum on vlen(128bits).
  * check if rs1 is x0 in vsetvl/vsetvli.
  * use gen_goto_tb in vsetvli instead of exit_tb.
  * fixup fetch vlmax from rs2, not env->vext.type.
v3
  * support VLEN configure from qemu command line.
  * support ELEN configure from qemu command line.
  * support vector specification version configure from qemu command line.
  * only default on for "any" cpu, others turn on from command line.
  * use a continous memory block for vector register description.
V2
  * use float16_compare{_quiet}
  * only use GETPC() in outer most helper
  * add ctx.ext_v Property

LIU Zhiwei (4):
  target/riscv: add vector extension field in CPURISCVState
  target/riscv: implementation-defined constant parameters
  target/riscv: support vector extension csr
  target/riscv: add vector configure instruction

 MAINTAINERS |  1 +
 target/riscv/Makefile.objs  |  2 +-
 target/riscv/cpu.c  |  7 +++
 target/riscv/cpu.h  | 78 ++---
 target/riscv/cpu_bits.h | 15 +
 target/riscv/csr.c  | 75 +++-
 target/riscv/helper.h   |  2 +
 target/riscv/insn32.decode  |  5 ++
 target/riscv/insn_trans/trans_rvv.inc.c | 69 ++
 target/riscv/translate.c| 17 +-
 target/riscv/vector_helper.c| 53 +
 11 files changed, 312 insertions(+), 12 deletions(-)
 create mode 100644 target/riscv/insn_trans/trans_rvv.inc.c
 create mode 100644 target/riscv/vector_helper.c

-- 
2.23.0

[PATCH v5 3/4] target/riscv: support vector extension csr

[LIU Zhiwei]

The v0.7.1 specification does not define vector status within mstatus.
A future revision will define the privileged portion of the vector status.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/cpu_bits.h | 15 +
 target/riscv/csr.c  | 75 -
 2 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index e99834856c..1f588ebc14 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -29,6 +29,14 @@
 #define FSR_NXA (FPEXC_NX << FSR_AEXC_SHIFT)
 #define FSR_AEXC(FSR_NVA | FSR_OFA | FSR_UFA | FSR_DZA | FSR_NXA)
 
+/* Vector Fixed-Point round model */
+#define FSR_VXRM_SHIFT  9
+#define FSR_VXRM(0x3 << FSR_VXRM_SHIFT)
+
+/* Vector Fixed-Point saturation flag */
+#define FSR_VXSAT_SHIFT 8
+#define FSR_VXSAT   (0x1 << FSR_VXSAT_SHIFT)
+
 /* Control and Status Registers */
 
 /* User Trap Setup */
@@ -48,6 +56,13 @@
 #define CSR_FRM 0x002
 #define CSR_FCSR0x003
 
+/* User Vector CSRs */
+#define CSR_VSTART  0x008
+#define CSR_VXSAT   0x009
+#define CSR_VXRM0x00a
+#define CSR_VL  0xc20
+#define CSR_VTYPE   0xc21
+
 /* User Timers and Counters */
 #define CSR_CYCLE   0xc00
 #define CSR_TIME0xc01
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 0e34c292c5..9cd2b418bf 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -46,6 +46,10 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops)
 static int fs(CPURISCVState *env, int csrno)
 {
 #if !defined(CONFIG_USER_ONLY)
+/* loose check condition for fcsr in vector extension */
+if ((csrno == CSR_FCSR) && (env->misa & RVV)) {
+return 0;
+}
 if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
 return -1;
 }
@@ -53,6 +57,14 @@ static int fs(CPURISCVState *env, int csrno)
 return 0;
 }
 
+static int vs(CPURISCVState *env, int csrno)
+{
+if (env->misa & RVV) {
+return 0;
+}
+return -1;
+}
+
 static int ctr(CPURISCVState *env, int csrno)
 {
 #if !defined(CONFIG_USER_ONLY)
@@ -160,6 +172,10 @@ static int read_fcsr(CPURISCVState *env, int csrno, 
target_ulong *val)
 #endif
 *val = (riscv_cpu_get_fflags(env) << FSR_AEXC_SHIFT)
 | (env->frm << FSR_RD_SHIFT);
+if (vs(env, csrno) >= 0) {
+*val |= (env->vxrm << FSR_VXRM_SHIFT)
+| (env->vxsat << FSR_VXSAT_SHIFT);
+}
 return 0;
 }
 
@@ -172,10 +188,62 @@ static int write_fcsr(CPURISCVState *env, int csrno, 
target_ulong val)
 env->mstatus |= MSTATUS_FS;
 #endif
 env->frm = (val & FSR_RD) >> FSR_RD_SHIFT;
+if (vs(env, csrno) >= 0) {
+env->vxrm = (val & FSR_VXRM) >> FSR_VXRM_SHIFT;
+env->vxsat = (val & FSR_VXSAT) >> FSR_VXSAT_SHIFT;
+}
 riscv_cpu_set_fflags(env, (val & FSR_AEXC) >> FSR_AEXC_SHIFT);
 return 0;
 }
 
+static int read_vtype(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vtype;
+return 0;
+}
+
+static int read_vl(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vl;
+return 0;
+}
+
+static int read_vxrm(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vxrm;
+return 0;
+}
+
+static int read_vxsat(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vxsat;
+return 0;
+}
+
+static int read_vstart(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vstart;
+return 0;
+}
+
+static int write_vxrm(CPURISCVState *env, int csrno, target_ulong val)
+{
+env->vxrm = val;
+return 0;
+}
+
+static int write_vxsat(CPURISCVState *env, int csrno, target_ulong val)
+{
+env->vxsat = val;
+return 0;
+}
+
+static int write_vstart(CPURISCVState *env, int csrno, target_ulong val)
+{
+env->vstart = val;
+return 0;
+}
+
 /* User Timers and Counters */
 static int read_instret(CPURISCVState *env, int csrno, target_ulong *val)
 {
@@ -877,7 +945,12 @@ static riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
 [CSR_FFLAGS] =  { fs,   read_fflags,  write_fflags  },
 [CSR_FRM] = { fs,   read_frm, write_frm },
 [CSR_FCSR] ={ fs,   read_fcsr,write_fcsr},
-
+/* Vector CSRs */
+[CSR_VSTART] =  { vs,   read_vstart,  write_vstart  },
+[CSR_VXSAT] =   { vs,   read_vxsat,   write_vxsat   },
+[CSR_VXRM] ={ vs,   read_vxrm,write_vxrm},
+[CSR_VL] =  { vs,   read_vl },
+[CSR_VTYPE] =   { vs,   read_vtype  },
 /* User Timers and Counters */
 [CSR_CYCLE] =   { ctr,  read_instret},
 [CSR_INSTRET] = { ctr,  read_instret},
-- 
2.23.0

[PATCH v5 2/4] target/riscv: implementation-defined constant parameters

[LIU Zhiwei]

vlen is the vector register length in bits.
elen is the max element size in bits.
vext_spec is the vector specification version, default value is v0.7.1.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/cpu.c | 7 +++
 target/riscv/cpu.h | 5 +
 2 files changed, 12 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 8c86ebc109..6900714432 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -98,6 +98,11 @@ static void set_priv_version(CPURISCVState *env, int 
priv_ver)
 env->priv_ver = priv_ver;
 }
 
+static void set_vext_version(CPURISCVState *env, int vext_ver)
+{
+env->vext_ver = vext_ver;
+}
+
 static void set_feature(CPURISCVState *env, int feature)
 {
 env->features |= (1ULL << feature);
@@ -320,6 +325,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 CPURISCVState *env = &cpu->env;
 RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev);
 int priv_version = PRIV_VERSION_1_11_0;
+int vext_version = VEXT_VERSION_0_07_1;
 target_ulong target_misa = 0;
 Error *local_err = NULL;
 
@@ -345,6 +351,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 }
 
 set_priv_version(env, priv_version);
+set_vext_version(env, vext_version);
 set_resetvec(env, DEFAULT_RSTVEC);
 
 if (cpu->cfg.mmu) {
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 2e8d01c155..748bd557f9 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -83,6 +83,8 @@ enum {
 #define PRIV_VERSION_1_10_0 0x00011000
 #define PRIV_VERSION_1_11_0 0x00011100
 
+#define VEXT_VERSION_0_07_1 0x0701
+
 #define TRANSLATE_PMP_FAIL 2
 #define TRANSLATE_FAIL 1
 #define TRANSLATE_SUCCESS 0
@@ -117,6 +119,7 @@ struct CPURISCVState {
 target_ulong badaddr;
 
 target_ulong priv_ver;
+target_ulong vext_ver;
 target_ulong misa;
 target_ulong misa_mask;
 
@@ -231,6 +234,8 @@ typedef struct RISCVCPU {
 
 char *priv_spec;
 char *user_spec;
+uint16_t vlen;
+uint16_t elen;
 bool mmu;
 bool pmp;
 } cfg;
-- 
2.23.0

Re: [PATCH] hw/char/pl011: Enable TxFIFO and async transmission

[Philippe Mathieu-Daudé]

On 2/21/20 10:37 AM, Philippe Mathieu-Daudé wrote:

Cc'ing Igor & Drew.

On 2/21/20 7:28 AM, no-re...@patchew.org wrote:
Patchew URL: 
https://patchew.org/QEMU/20200221044908.266883-1-gs...@redhat.com/

 >

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

[...]
   TEST    check-qtest-aarch64: tests/qtest/bios-tables-test

**
ERROR:/tmp/qemu-test/src/tests/qtest/acpi-utils.c:145:acpi_find_rsdp_address_uefi: 
code should not be reached
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/qtest/acpi-utils.c:145:acpi_find_rsdp_address_uefi: 
code should not be reached

make: *** [check-qtest-aarch64] Error 1


The virt machine is not happy, busy-looping?

$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 \
   tests/qtest/bios-tables-test
/aarch64/acpi/virt: ^C


So this test runs:

$ qemu-system-aarch64 -M virt -pflash pc-bios/edk2-aarch64-code.fd 
-pflash pc-bios/edk2-arm-vars.fd -cdrom 
tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2 -cpu 
cortex-a57 -serial stdio

[...]
[Bds]=End Load Options Dumping= 




[Bds]BdsWait ...Zzzz... 




[Bds]BdsWait(3)..Zzzz... 




[Bds]BdsWait(2)..Zzzz... 




[Bds]BdsWait(1)..Zzzz... 




[Bds]Exit the waiting! 




[Bds]Stop Hotkey Service! 




[Bds]UnregisterKeyNotify: 000C/ Success 




[Bds]UnregisterKeyNotify: 0017/ Success 




[Bds]UnregisterKeyNotify: /000D Success 




Memory  Previous  CurrentNext
 TypePages Pages Pages
==      
  09  0080  00A0
  0A  0020  0028
  00    
  06012C  0370  044C
  050096  0280  0320
  0303E8  03AB  03E8
  042EE0  2000  2EE0
  010014    0014
  02    
Memory Type Information settings change.
[Bds]Booting UEFI Misc Device
 BlockSize : 262144
 LastBlock : FF
[Bds] Expand VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00) -> 
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from 
VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found

Memory  Previous  CurrentNext
 TypePages Pages Pages
==      
  09  0080  00A0
  0A  0020  0028
  00    
  06012C  0370  044C
  050096  0280  0320
  0303E8  03AB  03E8
  042EE0  2040  2EE0
  010014    0014
  02    
Memory Type Information settings change.
[Bds]Booting UEFI Misc Device 2
 BlockSize : 512
 LastBlock : 33F
FatDiskIo: Cache Page OutBound occurred!
FSOpen: Open '\EFI\BOOT\BOOTAA64.EFI' Success
[Bds] Expand PciRoot(0x0)/Pci(0x2,0x0) -> 
PciRoot(0x0)/Pci(0x2,0x0)/CDROM(0x0,0x68,0x200)/\EFI\BOOT\BOOTAA64.EFI

BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
[Security] 3rd party image[0] can be loaded after EndOfDxe: 
PciRoot(0x0)/Pci(0x2,0x0)/CDROM(0x0,0x68,0x200)/\EFI\BOOT\BOOTAA64.EFI.

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 452B5840
add-symbol-file 
/home/lacos/src/upstream/qemu/tests/uefi-test-tools/Build/UefiTestTools/DEBUG_GCC5/AARCH64/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest/DEBUG/BiosTablesTest.dll 
0x442C3000

Loading driver at 0x000442C2000 EntryPoint=0x000442C47AC BiosTablesTest.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 4654E718
ProtectUefiImageCommon - 0x452B5840
  - 0x442C2000 - 0x6000
SetUefiImageMemoryAttributes - 0x442C2000 - 0x1000 
(0x4008)
SetUefiImageMemoryAttributes - 0x442C3000 - 0x3000 
(0x00020008)
SetUefiImageMemoryAttributes - 0x442C6000 - 0x2000 
(0x4008)
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from 
PciRoot(0x0)/Pci(0x2,0x0)

BiosTablesTest: BiosTablesTest=4510 Rsdp10=0 Rsdp20=4402
BiosTablesTest: Smbios21=0 Smbios30=4764
BiosTablesTest: press any key to exit
qemu-system-aarch64: terminating on signal 2

Using -d in_asm -trace pl011\* you see after "press any key to exit" it 
is looping for a key on the uart:


12638@1582277983.168226:pl011_read addr 0x0018 value 0x0010
12638@1582277983.168229:pl011_write addr 0x value 0x0030
12638@1582277983.168233:pl011_read addr 0x0018 value 0x0010
12638@1582277983.168236:pl011_write addr 0x value 0x0030
12638@1582277983.168239:pl011_read addr 0x0018 value 0x0010
12638@1582277983.168242:pl011_write addr 0x value 0x0030
12638@1582277983.168246:pl011_read addr 0x0018 value 0x0010
12638@1582277983.168249:pl011_write addr 0x value 0x0020
12638@1582277983.168252:pl011_read addr 0x0018 value 0x0010
12638@1582277983.168255:pl011_

[PATCH v5 1/4] target/riscv: add vector extension field in CPURISCVState

[LIU Zhiwei]

The 32 vector registers will be viewed as a continuous memory block.
It avoids the convension between element index and (regno, offset).
Thus elements can be directly accessed by offset from the first vector
base address.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/cpu.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index de0a8d893a..2e8d01c155 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -64,6 +64,7 @@
 #define RVA RV('A')
 #define RVF RV('F')
 #define RVD RV('D')
+#define RVV RV('V')
 #define RVC RV('C')
 #define RVS RV('S')
 #define RVU RV('U')
@@ -93,9 +94,20 @@ typedef struct CPURISCVState CPURISCVState;
 
 #include "pmp.h"
 
+#define RV_VLEN_MAX 512
+
 struct CPURISCVState {
 target_ulong gpr[32];
 uint64_t fpr[32]; /* assume both F and D extensions */
+
+/* vector coprocessor state. */
+uint64_t vreg[32 * RV_VLEN_MAX / 64] QEMU_ALIGNED(16);
+target_ulong vxrm;
+target_ulong vxsat;
+target_ulong vl;
+target_ulong vstart;
+target_ulong vtype;
+
 target_ulong pc;
 target_ulong load_res;
 target_ulong load_val;
-- 
2.23.0

Re: [PATCH] virtiofsd: Remove fuse.h and struct fuse_module

[Philippe Mathieu-Daudé]

On 2/21/20 7:55 AM, Xiao Yang wrote:

All code in fuse.h and struct fuse_module are not used by virtiofsd
so removing them is safe.

Signed-off-by: Xiao Yang 
---
  tools/virtiofsd/fuse.h   | 1229 --
  tools/virtiofsd/fuse_i.h |   16 -
  2 files changed, 1245 deletions(-)
  delete mode 100644 tools/virtiofsd/fuse.h


Reviewed-by: Philippe Mathieu-Daudé 

[PATCH v5 4/4] target/riscv: add vector configure instruction

[LIU Zhiwei]

vsetvl and vsetvli are two configure instructions for vl, vtype. TB flags
should update after configure instructions. The (ill, lmul, sew ) of vtype
and the bit of (VSTART == 0 && VL == VLMAX) will be placed within tb_flags.

Signed-off-by: LIU Zhiwei 
---
 MAINTAINERS |  1 +
 target/riscv/Makefile.objs  |  2 +-
 target/riscv/cpu.h  | 61 +++---
 target/riscv/helper.h   |  2 +
 target/riscv/insn32.decode  |  5 ++
 target/riscv/insn_trans/trans_rvv.inc.c | 69 +
 target/riscv/translate.c| 17 +-
 target/riscv/vector_helper.c| 53 +++
 8 files changed, 199 insertions(+), 11 deletions(-)
 create mode 100644 target/riscv/insn_trans/trans_rvv.inc.c
 create mode 100644 target/riscv/vector_helper.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1740a4fddc..cd2e200db9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,6 +266,7 @@ M: Palmer Dabbelt 
 M: Alistair Francis 
 M: Sagar Karandikar 
 M: Bastian Koppelmann 
+M: LIU Zhiwei 
 L: qemu-ri...@nongnu.org
 S: Supported
 F: target/riscv/
diff --git a/target/riscv/Makefile.objs b/target/riscv/Makefile.objs
index ff651f69f6..ff38df6219 100644
--- a/target/riscv/Makefile.objs
+++ b/target/riscv/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o 
gdbstub.o
+obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o 
vector_helper.o gdbstub.o
 obj-$(CONFIG_SOFTMMU) += pmp.o
 
 ifeq ($(CONFIG_SOFTMMU),y)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 748bd557f9..f7003edb86 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -21,6 +21,7 @@
 #define RISCV_CPU_H
 
 #include "hw/core/cpu.h"
+#include "hw/registerfields.h"
 #include "exec/cpu-defs.h"
 #include "fpu/softfloat-types.h"
 
@@ -98,6 +99,12 @@ typedef struct CPURISCVState CPURISCVState;
 
 #define RV_VLEN_MAX 512
 
+FIELD(VTYPE, LMUL, 0, 2)
+FIELD(VTYPE, SEW, 2, 3)
+FIELD(VTYPE, EDIV, 5, 2)
+FIELD(VTYPE, RESERVED, 7, sizeof(target_ulong) * 8 - 9)
+FIELD(VTYPE, VILL, sizeof(target_ulong) * 8 - 2, 1)
+
 struct CPURISCVState {
 target_ulong gpr[32];
 uint64_t fpr[32]; /* assume both F and D extensions */
@@ -302,16 +309,59 @@ void riscv_cpu_set_fflags(CPURISCVState *env, 
target_ulong);
 #define TB_FLAGS_MMU_MASK   3
 #define TB_FLAGS_MSTATUS_FS MSTATUS_FS
 
+typedef CPURISCVState CPUArchState;
+typedef RISCVCPU ArchCPU;
+#include "exec/cpu-all.h"
+
+FIELD(TB_FLAGS, VL_EQ_VLMAX, 2, 1)
+FIELD(TB_FLAGS, LMUL, 3, 2)
+FIELD(TB_FLAGS, SEW, 5, 3)
+FIELD(TB_FLAGS, VILL, 8, 1)
+
+/*
+ * A simplification for VLMAX
+ * = (1 << LMUL) * VLEN / (8 * (1 << SEW))
+ * = (VLEN << LMUL) / (8 << SEW)
+ * = (VLEN << LMUL) >> (SEW + 3)
+ * = VLEN >> (SEW + 3 - LMUL)
+ */
+static inline uint32_t vext_get_vlmax(RISCVCPU *cpu, target_ulong vtype)
+{
+uint8_t sew, lmul;
+
+sew = FIELD_EX64(vtype, VTYPE, SEW);
+lmul = FIELD_EX64(vtype, VTYPE, LMUL);
+return cpu->cfg.vlen >> (sew + 3 - lmul);
+}
+
 static inline void cpu_get_tb_cpu_state(CPURISCVState *env, target_ulong *pc,
-target_ulong *cs_base, uint32_t *flags)
+target_ulong *cs_base, uint32_t 
*pflags)
 {
+uint32_t flags = 0;
+
 *pc = env->pc;
 *cs_base = 0;
+
+if (env->misa & RVV) {
+uint32_t vlmax = vext_get_vlmax(env_archcpu(env), env->vtype);
+bool vl_eq_vlmax = (env->vstart == 0) && (vlmax == env->vl);
+flags = FIELD_DP32(flags, TB_FLAGS, VILL,
+FIELD_EX64(env->vtype, VTYPE, VILL));
+flags = FIELD_DP32(flags, TB_FLAGS, SEW,
+FIELD_EX64(env->vtype, VTYPE, SEW));
+flags = FIELD_DP32(flags, TB_FLAGS, LMUL,
+FIELD_EX64(env->vtype, VTYPE, LMUL));
+flags = FIELD_DP32(flags, TB_FLAGS, VL_EQ_VLMAX, vl_eq_vlmax);
+} else {
+flags = FIELD_DP32(flags, TB_FLAGS, VILL, 1);
+}
+
 #ifdef CONFIG_USER_ONLY
-*flags = TB_FLAGS_MSTATUS_FS;
+flags |= TB_FLAGS_MSTATUS_FS;
 #else
-*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
+flags |= cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
 #endif
+*pflags = flags;
 }
 
 int riscv_csrrw(CPURISCVState *env, int csrno, target_ulong *ret_value,
@@ -352,9 +402,4 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations 
*ops);
 
 void riscv_cpu_register_gdb_regs_for_features(CPUState *cs);
 
-typedef CPURISCVState CPUArchState;
-typedef RISCVCPU ArchCPU;
-
-#include "exec/cpu-all.h"
-
 #endif /* RISCV_CPU_H */
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index debb22a480..3c28c7e407 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -76,3 +76,5 @@ DEF_HELPER_2(mret, tl, env, tl)
 DEF_HELPER_1(wfi, void, env)
 DEF_HELPER_1(tlb_flush, void, env)
 #endif
+/* Vector functions */
+DEF_HELPER_3(vsetvl, tl, env, tl, 

Re: [PATCH v4 02/16] s390x: protvirt: Add diag308 subcodes 8 - 10

[Cornelia Huck]

On Thu, 20 Feb 2020 07:56:24 -0500
Janosch Frank  wrote:

> For diag308 subcodes 8 - 10 we have a new ipib of type 5. The ipib
> holds the address and length of the secure execution header, as well
> as a list of guest components.
> 
> Each component is a block of memory, for example kernel or initrd,
> which needs to be decrypted by the Ultravisor in order to run a
> protected VM. The secure execution header instructs the Ultravisor on
> how to handle the protected VM and its components.
> 
> Subcodes 8 and 9 are similiar to 5 and 6 and subcode 10 will finally
> start the protected guest.
> 
> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
> 3 and then the 8 and 10 combination for a protected reboot.
> 
> Signed-off-by: Janosch Frank 
> ---
>  hw/s390x/ipl.c  | 48 ++---
>  hw/s390x/ipl.h  | 31 +
>  target/s390x/diag.c | 27 ++---
>  3 files changed, 100 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> index 7773499d7f..e92d989813 100644
> --- a/hw/s390x/ipl.c
> +++ b/hw/s390x/ipl.c
> @@ -538,15 +538,56 @@ static bool is_virtio_scsi_device(IplParameterBlock 
> *iplb)
>  return is_virtio_ccw_device_of_type(iplb, VIRTIO_ID_SCSI);
>  }
>  
> +int s390_ipl_pv_check_components(IplParameterBlock *iplb)
> +{
> +int i;
> +IPLBlockPV *ipib_pv = &iplb->pv;
> +
> +if (ipib_pv->num_comp == 0) {
> +return -EINVAL;
> +}
> +
> +for (i = 0; i < ipib_pv->num_comp; i++) {
> +
> +/* Addr must be 4k aligned */
> +if (ipib_pv->components[i].addr & ~TARGET_PAGE_MASK) {
> +return -EINVAL;
> +}
> +
> +/* Tweak prefix is monotonously increasing with each component */
> +if (i < ipib_pv->num_comp - 1 &&
> +ipib_pv->components[i].tweak_pref >
> +ipib_pv->components[i + 1].tweak_pref) {
> +return -EINVAL;
> +}
> +}
> +return 1;

Any reason why you return 1 here? 0 vs negative error is the more usual
pattern.

> +}
> +

(...)

> @@ -117,7 +123,8 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, 
> uint64_t r3, uintptr_t ra)
>  
>  cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
>  
> -if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb)) {
> +if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
> +!(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 
> 0)) {

!s390_ipl_pv_check_components() would also read nicer IMHO :)

>  env->regs[r1 + 1] = DIAG_308_RC_INVALID;
>  goto out;
>  }

Otherwise, looks good to me.

Re: Race condition in overlayed qcow2?

[dovgaluk]

Vladimir Sementsov-Ogievskiy писал 2020-02-20 12:36:

20.02.2020 12:05, Vladimir Sementsov-Ogievskiy wrote:

20.02.2020 11:31, dovgaluk wrote:

Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:

19.02.2020 17:32, dovgaluk wrote:
I encountered a problem with record/replay of QEMU execution and 
figured out the following, when
QEMU is started with one virtual disk connected to the qcow2 image 
with applied 'snapshot' option.


The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: 
introduce parallel subrequest handling in read and write"
introduces some kind of race condition, which causes difference in 
the data read from the disk.


I detected this by adding the following code, which logs IO 
operation checksum. And this checksum may be different in different 
runs of the same recorded execution.


logging in blk_aio_complete function:
 qemu_log("%"PRId64": blk_aio_complete\n", 
replay_get_current_icount());

 QEMUIOVector *qiov = acb->rwco.iobuf;
 if (qiov && qiov->iov) {
 size_t i, j;
 uint64_t sum = 0;
 int count = 0;
 for (i = 0 ; i < qiov->niov ; ++i) {
 for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
 sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
 ++count;
 }
 }
 qemu_log("--- iobuf offset %"PRIx64" len %x sum: 
%"PRIx64"\n", acb->rwco.offset, count, sum);

 }

I tried to get rid of aio task by patching qcow2_co_preadv_part:
ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, 
cur_bytes, qiov, qiov_offset);


That change fixed a bug, but I have no idea what to debug next to 
figure out the exact reason of the failure.


Do you have any ideas or hints?



Hi!

Hmm, do mean that read from the disk may return wrong data? It would
be very bad of course :(
Could you provide a reproducer, so that I can look at it and debug?


It is just a winxp-32 image. I record the execution and replay it 
with the following command lines:


qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M 
-drive file=xp.qcow2,if=none,id=device-34-file,snapshot -drive 
driver=blkreplay,if=none,image=device-34-file,id=device-34-driver 
-device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net 
none


qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M 
-drive file=xp.qcow2,if=none,id=device-34-file,snapshot -drive 
driver=blkreplay,if=none,image=device-34-file,id=device-34-driver 
-device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net 
none


Replay stalls at some moment due to the non-determinism of the 
execution (probably caused by the wrong data read).


Hmm.. I tried it  (with x86_64 qemu and centos image). I waited for 
some time for a first command, than Ctrl+C it. After it replay.bin was 
4M. Than started the second command. It works, not failing, not 
finishing. Is it bad? What is expected behavior and what is wrong?





What is exactly the case? May be you have other parallel aio
operations to the same region?


As far as I understand, all aio operations, initiated by IDE 
controller, are performed one-by-one.

I don't see anything else in the logs.


Ideas to experiment:

1. change QCOW2_MAX_WORKERS to 1 or to 2, will it help?


1 or 2 are ok, and 4 or 8 lead to the failures.

2. understand what is the case in code: is it read from one or 
several

clusters, is it aligned,
what is the type of clusters, is encryption in use, compression?


There is no encryption and I thinks compression is not enabled too.
Clusters are read from the temporary overlay:

blk_aio_prwv
blk_aio_read_entry
bdrv_co_preadv_part complete offset: 2630 qiov_offset: 1c200 len: 
1e00
bdrv_co_preadv_part complete offset: 24723e00 qiov_offset: 0 len: 
1c200
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 
1e000
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 
1e000
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 
1e000




3. understand what kind of data corruption. What we read instead of
correct data? Just garbage, or may be zeroes, or what..


Most bytes are the same, but some are different:

< 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00
< 46 49 4c 45 30 00 03 00 18 d1 33 02 00 00 00 00
< 01 00 01 00 38 00 01 00 68 01 00 00 00 04 00 00
< 00 00 00 00 00 00 00 00 04 00 00 00 9d 0e 00 00
< 02 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
---

00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00
46 49 4c 45 30 00 03 00 86 78 35 03 00 00 00 00
01 00 01 00 38 00 01 00 60 01 00 00 00 04 00 00
00 00 00 00 00 00 00 00 04 00 00 00 a1 0e 00 00
04 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00


That is strange. I could think, that it was caused by the bugs in
deterministic CPU execution, but the first difference in logs
occur in READ operation (I dump read/write buffers in 
blk_aio_complete).




Aha, yes, looks strange.

Then next steps:

1. Does problem hit into 

Re: [PATCH v3] util/async: make bh_aio_poll() O(1)

[Stefan Hajnoczi]

On Fri, Feb 21, 2020 at 9:40 AM Stefan Hajnoczi  wrote:
>
> The ctx->first_bh list contains all created BHs, including those that
> are not scheduled.  The list is iterated by the event loop and therefore
> has O(n) time complexity with respected to the number of created BHs.
>
> Rewrite BHs so that only scheduled or deleted BHs are enqueued.
> Only BHs that actually require action will be iterated.
>
> One semantic change is required: qemu_bh_delete() enqueues the BH and
> therefore invokes aio_notify().  The
> tests/test-aio.c:test_source_bh_delete_from_cb() test case assumed that
> g_main_context_iteration(NULL, false) returns false after
> qemu_bh_delete() but it now returns true for one iteration.  Fix up the
> test case.
>
> This patch makes aio_compute_timeout() and aio_bh_poll() drop from a CPU
> profile reported by perf-top(1).  Previously they combined to 9% CPU
> utilization when AioContext polling is commented out and the guest has 2
> virtio-blk,num-queues=1 and 99 virtio-blk,num-queues=32 devices.
>
> Signed-off-by: Stefan Hajnoczi 
> ---
> v3:
>  * Use QSLIST_FOREACH_RCU() and QSLIST_FIRST_RCU() [Paolo]

I forgot to include Paolo's R-b that he gave conditional on making this change:

Reviewed-by: Paolo Bonzini 

Re: [PATCH v4 16/16] docs: Add protvirt docs

[Cornelia Huck]

On Thu, 20 Feb 2020 07:56:38 -0500
Janosch Frank  wrote:

> Lets add some documentation for the Protected VM functionality.
> 
> Signed-off-by: Janosch Frank 
> ---
>  docs/protvirt.rst | 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 docs/protvirt.rst

You'll probably want to add that file to an index as well, so that it
gets built properly.

> 
> diff --git a/docs/protvirt.rst b/docs/protvirt.rst
> new file mode 100644
> index 00..8bfa72be01
> --- /dev/null
> +++ b/docs/protvirt.rst
> @@ -0,1 +1,53 @@
> +Protected Virtualization on s390x
> +

Please lengthen the underlining :)

Also, it might improve readability of the text doc if you added an
empty line beneath the headers.

> +The memory and most of the register contents of Protected Virtual
> +Machines (PVMs) are inaccessible to the hypervisor, effectively
> +prohibiting VM introspection when the VM is running. At rest, PVMs are
> +encrypted and can only be decrypted by the firmware of specific IBM Z
> +machines.
> +
> +
> +Prerequisites
> +-
> +To run PVMs, you need to have a machine with the Protected
> +Virtualization feature, which is indicated by the Ultravisor Call
> +facility (stfle bit 158). This is a KVM only feature, therefore you
> +need a KVM which is able to support PVMs and activate the Ultravisor
> +initialization by setting "prot_virt=1" on the kernel command line.

`prot_virt=1`, so that it gets rendered as a literal in html?

> +
> +If those requirements are met, the capability "KVM_CAP_S390_PROTECTED"

`KVM_CAP_S390_PROTECTED`

> +will indicate that KVM can support PVMs on that LPAR.
> +
> +
> +QEMU Settings
> +-
> +To indicate to the VM that it can move into protected mode, the
> +"Unpack facility" (stfle bit 161) needs to be part of the cpu model of
> +the VM.

Add an example invocation here?

> +
> +All I/O devices need to use the IOMMU.
> +Passthrough devices are currently not supported.

s/Passthrough devices/Passthrough (vfio) devices/ ?

> +
> +Host huge page backings are not supported. The guest however can use
> +huge pages as indicated by its facilities.
> +
> +
> +Boot Process
> +-

Underlining too long :)

> +A secure guest image can be booted from disk and using the QEMU

"can be both booted from..." ?

> +command line. Booting from disk is done by the unmodified s390-ccw
> +BIOS. I.e., the bootmap is interpreted and a number of components is
> +read into memory and control is transferred to one of the components
> +(zipl stage3), which does some fixups and then transfers control to
> +some program residing in guest memory, which is normally the OS
> +kernel. The secure image has another component prepended (stage3a)
> +which uses the new diag308 subcodes 8 and 10 to trigger the transition
> +into secure mode.
> +
> +Booting from the command line requires that the file passed
> +via -kernel has the same memory layout as would result from the disk
> +boot. This memory layout includes the encrypted components (kernel,
> +initrd, cmdline), the stage3a loader and metadata. In case this boot
> +method is used, the command line options -initrd and -cmdline are
> +ineffective.  The preparation of secure guest image is done by a
> +program (name tbd) of the s390-tools package.

Hm... do you have an ETA for that tbd program?

Re: [PATCH] console: make QMP screendump use coroutine

[Kevin Wolf]

Am 20.02.2020 um 17:01 hat Markus Armbruster geschrieben:
> >> >  void qmp_screendump(const char *filename, bool has_device, const char 
> >> > *device,
> >> >  bool has_head, int64_t head, Error **errp)
> >> >  {
> >> >  QemuConsole *con;
> >> >  DisplaySurface *surface;
> >> > +g_autoptr(pixman_image_t) image = NULL;
> >> >  int fd;
> >> >
> >> >  if (has_device) {
> >> > @@ -365,7 +375,15 @@ void qmp_screendump(const char *filename, bool 
> >> > has_device, const char *device,
> >> >  }
> >> >  }
> >> >
> >> > -graphic_hw_update(con);
> >> > +if (qemu_in_coroutine()) {
> >> > +assert(!con->screendump_co);
> >> > +con->screendump_co = qemu_coroutine_self();
> >> > +aio_bh_schedule_oneshot(qemu_get_aio_context(),
> >> > +graphic_hw_update_bh, con);
> >> > +qemu_coroutine_yield();
> >> > +con->screendump_co = NULL;
> >> > +}
> >>
> >> What if multiple QMP monitors simultaneously screendump?  Hmm, it works
> >> because all execute one after another in the same coroutine
> >> qmp_dispatcher_co.  Implicit mutual exclusion.
> >>
> >> Executing them one after another is bad, because it lets an ill-behaved
> >> QMP command starve *all* QMP monitors.  We do it only out of
> >> (reasonable!) fear of implicit mutual exclusion requirements like the
> >> one you add.
> >>
> >> Let's not add more if we can help it.
> >
> > The situation is not worse than the current blocking handling.
> 
> Really?
> 
> What makes executing multiple qmp_screendump() concurrently (in separate
> threads) or interleaved (in separate coroutines in the same thread)
> unsafe before this patch?

QMP command handlers are guaranteed to run in the main thread with the
BQL held, so there is no concurrency. If you want to change this, you
would have much more complicated problems to solve than in this handler.
I'm not sure it's fair to require thread-safety from one handler when
no other handler is thread safe (except accidentally) and nobody seems
to plan actually calling them from multiple threads.

> >> Your screendump_co is per QemuConsole instead of per QMP monitor only
> >> because you need to find the coroutine in graphic_hw_update_done().  Can
> >> we somehow pass it via function arguments?
> >
> > I think it could be done later, so I suggest a TODO.
> 
> We should avoid making our dependence on implicit mutual exclusion
> worse.  When we do it anyway, a big, fat, ugly comment is definitely
> called for.

Anyway, what I really wanted to add:

This should be easy to solve by having a CoQueue instead of a single
Coroutine pointer. The coroutine would just call qemu_co_queue_wait(),
which adds itself to the queue before it yields and the update
completion would wake up all coroutines that are currently queued with
qemu_co_queue_restart_all().

qemu_co_queue_wait() takes a lock as its second parameter. You don't
need it in this context and can just pass NULL. (This is a lock that
would be dropped while the coroutine is sleeping and automatically
reacquired afterwards.)

> >> In case avoiding the mutual exclusion is impractical: please explain it
> >> in a comment to make it somewhat less implicit.
> 
> It is anything but: see appended patch.

This works, too, but it requires an additional struct. I think the queue
is easier. (Note there is a difference in the mechanism: Your patch
waits for the specific update it triggered, while the CoQueue would wait
for _any_ update to complete. I assume effectively the result is the
same.)

Kevin

Re: Race condition in overlayed qcow2?

[Vladimir Sementsov-Ogievskiy]

21.02.2020 12:49, dovgaluk wrote:

Vladimir Sementsov-Ogievskiy писал 2020-02-20 12:36:

20.02.2020 12:05, Vladimir Sementsov-Ogievskiy wrote:

20.02.2020 11:31, dovgaluk wrote:

Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:

19.02.2020 17:32, dovgaluk wrote:

I encountered a problem with record/replay of QEMU execution and figured out 
the following, when
QEMU is started with one virtual disk connected to the qcow2 image with applied 
'snapshot' option.

The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: introduce parallel 
subrequest handling in read and write"
introduces some kind of race condition, which causes difference in the data 
read from the disk.

I detected this by adding the following code, which logs IO operation checksum. 
And this checksum may be different in different runs of the same recorded 
execution.

logging in blk_aio_complete function:
 qemu_log("%"PRId64": blk_aio_complete\n", replay_get_current_icount());
 QEMUIOVector *qiov = acb->rwco.iobuf;
 if (qiov && qiov->iov) {
 size_t i, j;
 uint64_t sum = 0;
 int count = 0;
 for (i = 0 ; i < qiov->niov ; ++i) {
 for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
 sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
 ++count;
 }
 }
 qemu_log("--- iobuf offset %"PRIx64" len %x sum: %"PRIx64"\n", 
acb->rwco.offset, count, sum);
 }

I tried to get rid of aio task by patching qcow2_co_preadv_part:
ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, cur_bytes, qiov, 
qiov_offset);

That change fixed a bug, but I have no idea what to debug next to figure out 
the exact reason of the failure.

Do you have any ideas or hints?



Hi!

Hmm, do mean that read from the disk may return wrong data? It would
be very bad of course :(
Could you provide a reproducer, so that I can look at it and debug?


It is just a winxp-32 image. I record the execution and replay it with the 
following command lines:

qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M -drive 
file=xp.qcow2,if=none,id=device-34-file,snapshot -drive 
driver=blkreplay,if=none,image=device-34-file,id=device-34-driver -device 
ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net none

qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M -drive 
file=xp.qcow2,if=none,id=device-34-file,snapshot -drive 
driver=blkreplay,if=none,image=device-34-file,id=device-34-driver -device 
ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net none

Replay stalls at some moment due to the non-determinism of the execution 
(probably caused by the wrong data read).


Hmm.. I tried it  (with x86_64 qemu and centos image). I waited for some time 
for a first command, than Ctrl+C it. After it replay.bin was 4M. Than started 
the second command. It works, not failing, not finishing. Is it bad? What is 
expected behavior and what is wrong?




What is exactly the case? May be you have other parallel aio
operations to the same region?


As far as I understand, all aio operations, initiated by IDE controller, are 
performed one-by-one.
I don't see anything else in the logs.


Ideas to experiment:

1. change QCOW2_MAX_WORKERS to 1 or to 2, will it help?


1 or 2 are ok, and 4 or 8 lead to the failures.


2. understand what is the case in code: is it read from one or several
clusters, is it aligned,
what is the type of clusters, is encryption in use, compression?


There is no encryption and I thinks compression is not enabled too.
Clusters are read from the temporary overlay:

blk_aio_prwv
blk_aio_read_entry
bdrv_co_preadv_part complete offset: 2630 qiov_offset: 1c200 len: 1e00
bdrv_co_preadv_part complete offset: 24723e00 qiov_offset: 0 len: 1c200
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000



3. understand what kind of data corruption. What we read instead of
correct data? Just garbage, or may be zeroes, or what..


Most bytes are the same, but some are different:

< 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00
< 46 49 4c 45 30 00 03 00 18 d1 33 02 00 00 00 00
< 01 00 01 00 38 00 01 00 68 01 00 00 00 04 00 00
< 00 00 00 00 00 00 00 00 04 00 00 00 9d 0e 00 00
< 02 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
---

00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00
46 49 4c 45 30 00 03 00 86 78 35 03 00 00 00 00
01 00 01 00 38 00 01 00 60 01 00 00 00 04 00 00
00 00 00 00 00 00 00 00 04 00 00 00 a1 0e 00 00
04 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00


That is strange. I could think, that it was caused by the bugs in
deterministic CPU execution, but the first difference in logs
occur in READ operation (I dump read/write buffers in blk_aio_complete).



Aha, yes, looks strange.

Then next steps:

1. Does probl

Re: [PATCH v1 05/13] migrate/ram: Handle RAM block resizes during precopy

[David Hildenbrand]

On 21.02.20 10:18, David Hildenbrand wrote:
> On 20.02.20 21:17, Peter Xu wrote:
>> On Thu, Feb 20, 2020 at 04:16:02PM +0100, David Hildenbrand wrote:
>>> On 19.02.20 17:17, David Hildenbrand wrote:
 Resizing while migrating is dangerous and does not work as expected.
 The whole migration code works on the usable_length of ram blocks and does
 not expect this to change at random points in time.

 In the case of precopy, the ram block size must not change on the source,
 after syncing the RAM block list in ram_save_setup(), so as long as the
 guest is still running on the source.

 Resizing can be trigger *after* (but not during) a reset in
 ACPI code by the guest
 - hw/arm/virt-acpi-build.c:acpi_ram_update()
 - hw/i386/acpi-build.c:acpi_ram_update()

 Use the ram block notifier to get notified about resizes. Let's simply
 cancel migration and indicate the reason. We'll continue running on the
 source. No harm done.

 Update the documentation. Postcopy will be handled separately.

 Cc: "Dr. David Alan Gilbert" 
 Cc: Juan Quintela 
 Cc: Eduardo Habkost 
 Cc: Paolo Bonzini 
 Cc: Igor Mammedov 
 Cc: "Michael S. Tsirkin" 
 Cc: Richard Henderson 
 Cc: Shannon Zhao 
 Cc: Alex Bennée 
 Cc: Peter Xu 
 Signed-off-by: David Hildenbrand 
 ---
  exec.c|  5 +++--
  include/exec/memory.h | 10 ++
  migration/migration.c |  9 +++--
  migration/migration.h |  1 +
  migration/ram.c   | 41 +
  5 files changed, 58 insertions(+), 8 deletions(-)

 diff --git a/exec.c b/exec.c
 index b75250e773..8b015821d6 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -2120,8 +2120,9 @@ static int memory_try_enable_merging(void *addr, 
 size_t len)
  return qemu_madvise(addr, len, QEMU_MADV_MERGEABLE);
  }
  
 -/* Only legal before guest might have detected the memory size: e.g. on
 - * incoming migration, or right after reset.
 +/*
 + * Resizing RAM while migrating can result in the migration being 
 canceled.
 + * Care has to be taken if the guest might have already detected the 
 memory.
   *
   * As memory core doesn't know how is memory accessed, it is up to
   * resize callback to update device state and/or add assertions to detect
 diff --git a/include/exec/memory.h b/include/exec/memory.h
 index e85b7de99a..de111347e8 100644
 --- a/include/exec/memory.h
 +++ b/include/exec/memory.h
 @@ -113,7 +113,7 @@ typedef struct IOMMUNotifier IOMMUNotifier;
  #define RAM_SHARED (1 << 1)
  
  /* Only a portion of RAM (used_length) is actually used, and migrated.
 - * This used_length size can change across reboots.
 + * Resizing RAM while migrating can result in the migration being 
 canceled.
   */
  #define RAM_RESIZEABLE (1 << 2)
  
 @@ -843,7 +843,9 @@ void 
 memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
   * RAM.  Accesses into the region will
   * modify memory directly.  Only an 
 initial
   * portion of this RAM is actually 
 used.
 - * The used size can change across 
 reboots.
 + * Changing the size while migrating
 + * can result in the migration being
 + * canceled.
   *
   * @mr: the #MemoryRegion to be initialized.
   * @owner: the object that tracks the region's reference count
 @@ -1464,8 +1466,8 @@ void *memory_region_get_ram_ptr(MemoryRegion *mr);
  
  /* memory_region_ram_resize: Resize a RAM region.
   *
 - * Only legal before guest might have detected the memory size: e.g. on
 - * incoming migration, or right after reset.
 + * Resizing RAM while migrating can result in the migration being 
 canceled.
 + * Care has to be taken if the guest might have already detected the 
 memory.
   *
   * @mr: a memory region created with @memory_region_init_resizeable_ram.
   * @newsize: the new size the region
 diff --git a/migration/migration.c b/migration/migration.c
 index 8fb68795dc..ac9751dbe5 100644
 --- a/migration/migration.c
 +++ b/migration/migration.c
 @@ -175,13 +175,18 @@ void migration_object_init(void)
  }
  }
  
 +void migration_cancel(void)
 +{
 +migrate_fd_cancel(current_migration);
 +}
 +
  void migration_shutdown(void)
  {
  /*
   * Cancel the current migration - that will (eventually)
   * stop the migration using this structure
   */
 -migrate_fd_cancel(current_migration);
 +migration_cance

[Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.

[Laurent Vivier]

Yes, it's fixed in v4.2.0, and with the help of your test program I've
bisect to the fix:

commit 1645fb5a1e537f85eda744bfa6e9d3dda047ba28
Author: Shu-Chun Weng 
Date:   Thu Oct 17 17:19:20 2019 -0700

Fix unsigned integer underflow in fd-trans.c

In any of these `*_for_each_*` functions, the last entry in the buffer (so 
the
"remaining length in the buffer" `len` is equal to the length of the
entry `nlmsg_len`/`nla_len`/etc) has size that is not a multiple of the
alignment, the aligned lengths `*_ALIGN(*_len)` will be greater than `len`.
Since `len` is unsigned (`size_t`), it underflows and the loop will read
pass the buffer.

This may manifest as random EINVAL or EOPNOTSUPP error on IO or network
system calls.

Signed-off-by: Shu-Chun Weng 
Reviewed-by: Laurent Vivier 
Message-Id: <20191018001920.178283-1-...@google.com>
Signed-off-by: Laurent Vivier 


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

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

Title:
  qemu user static binary seems to lack support for network namespace.

Status in QEMU:
  Fix Released

Bug description:
  Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I
  see the following error message.

  Unable to configure loopback interface: Operation not supported

  If I disable emerge's network-sandbox which utilizes network
  namespace, the error disappears.

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

Re: [PATCH] maint: Include top-level *.rst files early in git diff

[Peter Maydell]

On Thu, 20 Feb 2020 at 16:22, Eric Blake  wrote:
>
> We are converting more doc files to *.rst rather than *.texi.  Most
> doc files are already listed early in diffs due to our catchall
> docs/*, but a few top-level files get missed by that glob.
>
> Signed-off-by: Eric Blake 
> ---
>
> Both *.texi and *.rst entries make sense while we are still converting
> things, but we'll need a followup to drop *.texi when the conversion
> is complete...

I was wondering what rst files we had outside docs, and
the answer is "README.rst, CODING_STYLE.rst and
tests/acceptance/README.rst".

(There's a reasonable argument for moving CODING_STYLE.rst to
docs/devel now; depends how highly you rate having it more
"discoverable" to new contributors.)

thanks
-- PMM

Re: [PATCH v1 05/13] migrate/ram: Handle RAM block resizes during precopy

[David Hildenbrand]

On 21.02.20 11:10, David Hildenbrand wrote:
> On 21.02.20 10:18, David Hildenbrand wrote:
>> On 20.02.20 21:17, Peter Xu wrote:
>>> On Thu, Feb 20, 2020 at 04:16:02PM +0100, David Hildenbrand wrote:
 On 19.02.20 17:17, David Hildenbrand wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> In the case of precopy, the ram block size must not change on the source,
> after syncing the RAM block list in ram_save_setup(), so as long as the
> guest is still running on the source.
>
> Resizing can be trigger *after* (but not during) a reset in
> ACPI code by the guest
> - hw/arm/virt-acpi-build.c:acpi_ram_update()
> - hw/i386/acpi-build.c:acpi_ram_update()
>
> Use the ram block notifier to get notified about resizes. Let's simply
> cancel migration and indicate the reason. We'll continue running on the
> source. No harm done.
>
> Update the documentation. Postcopy will be handled separately.
>
> Cc: "Dr. David Alan Gilbert" 
> Cc: Juan Quintela 
> Cc: Eduardo Habkost 
> Cc: Paolo Bonzini 
> Cc: Igor Mammedov 
> Cc: "Michael S. Tsirkin" 
> Cc: Richard Henderson 
> Cc: Shannon Zhao 
> Cc: Alex Bennée 
> Cc: Peter Xu 
> Signed-off-by: David Hildenbrand 
> ---
>  exec.c|  5 +++--
>  include/exec/memory.h | 10 ++
>  migration/migration.c |  9 +++--
>  migration/migration.h |  1 +
>  migration/ram.c   | 41 +
>  5 files changed, 58 insertions(+), 8 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index b75250e773..8b015821d6 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2120,8 +2120,9 @@ static int memory_try_enable_merging(void *addr, 
> size_t len)
>  return qemu_madvise(addr, len, QEMU_MADV_MERGEABLE);
>  }
>  
> -/* Only legal before guest might have detected the memory size: e.g. on
> - * incoming migration, or right after reset.
> +/*
> + * Resizing RAM while migrating can result in the migration being 
> canceled.
> + * Care has to be taken if the guest might have already detected the 
> memory.
>   *
>   * As memory core doesn't know how is memory accessed, it is up to
>   * resize callback to update device state and/or add assertions to detect
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index e85b7de99a..de111347e8 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -113,7 +113,7 @@ typedef struct IOMMUNotifier IOMMUNotifier;
>  #define RAM_SHARED (1 << 1)
>  
>  /* Only a portion of RAM (used_length) is actually used, and migrated.
> - * This used_length size can change across reboots.
> + * Resizing RAM while migrating can result in the migration being 
> canceled.
>   */
>  #define RAM_RESIZEABLE (1 << 2)
>  
> @@ -843,7 +843,9 @@ void 
> memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
>   * RAM.  Accesses into the region 
> will
>   * modify memory directly.  Only an 
> initial
>   * portion of this RAM is actually 
> used.
> - * The used size can change across 
> reboots.
> + * Changing the size while migrating
> + * can result in the migration being
> + * canceled.
>   *
>   * @mr: the #MemoryRegion to be initialized.
>   * @owner: the object that tracks the region's reference count
> @@ -1464,8 +1466,8 @@ void *memory_region_get_ram_ptr(MemoryRegion *mr);
>  
>  /* memory_region_ram_resize: Resize a RAM region.
>   *
> - * Only legal before guest might have detected the memory size: e.g. on
> - * incoming migration, or right after reset.
> + * Resizing RAM while migrating can result in the migration being 
> canceled.
> + * Care has to be taken if the guest might have already detected the 
> memory.
>   *
>   * @mr: a memory region created with @memory_region_init_resizeable_ram.
>   * @newsize: the new size the region
> diff --git a/migration/migration.c b/migration/migration.c
> index 8fb68795dc..ac9751dbe5 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -175,13 +175,18 @@ void migration_object_init(void)
>  }
>  }
>  
> +void migration_cancel(void)
> +{
> +migrate_fd_cancel(current_migration);
> +}
> +
>  void migration_shutdown(void)
>  {
>  /*
>   * Cancel the current mig

Re: [PATCH] hw/char/pl011: Output characters using best-effort mode

[Peter Maydell]

On Fri, 21 Feb 2020 at 04:24, Gavin Shan  wrote:
> If above analysis is correct and the first approach doesn't work out. We have 
> to
> consider the 2nd approach - adding option to backend to allow losing data. I'm
> going to add "allow-data-lost" option for TYPE_CHARDEV_SOCKET. With the 
> option,
> a back-off algorithm in tcp_chr_write(): The channel is consider as broken if
> it fails to transmit data in last continuous 5 times. The transmission is 
> still
> issued when the channel is in broken state and recovered to normal state if
> transmission succeeds for once.

Before you do that, I would suggest investigating:
 * is this a problem we've already had on x86 and that there is a
   standard solution for?
 * should this be applicable to more than just the socket chardev?
   What's special about the socket chardev?

I've added the chardev backend maintainers to the cc list.

thanks
-- PMM

Re: [PATCH] console: make QMP screendump use coroutine

[Dr. David Alan Gilbert]

* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert"  writes:
> 
> > * Markus Armbruster (arm...@redhat.com) wrote:
> [...]
> >> Collecting several users before building infrastructure makes sense when
> >> the design of the infrastructure isn't obvious, or when the need for it
> >> is in doubt.
> >> 
> >> Neither is the case for running QMP handlers in a coroutine: QMP
> >> commands blocking the main loop is without doubt a problem we need to
> >> solve, and the way to solve it was obvious enough for Kevin to do it
> >> with one user: block_resize.  A second one quickly followed: screendump.
> >> 
> >> The only part that's different for HMP, I think, is "need".
> >> 
> >> Is HMP blocking the main loop a problem?
> >> 
> >> If yes, is it serious enough to justify solving it?
> >
> > I don't mind if HMP blocks for a small time while doing something, but
> > not if it can hang if the guest (or something else like it) misbehaves.
> > Not if it's something you might need to issue another command to recover
> > from.
> 
> The issue isn't HMP being unavailable while a command executes.  The
> issue is HMP stopping the main loop while a command executes.
> 
> Stopping the main loop not only stops everything running there, it can
> also stop other threads when they synchronize with the main loop via the
> Big QEMU Lock.

Yep.

> The obvious example is a command accessing a remote filesystem.  Special
> case: NFS with the hard option can hang indefinitely.

That I don't worry about too much for HMP; if your host is hosed, fix your host.

> screendump does that, and also waits for asynchronous gfx_update() with
> qxl devices.  Networking again, with a different peer.

That I would worry about since that's probably got interactions with the
guest and spice, and all the type of things you might be trying to debug
or test.

> We already decided that QMP commands stopping the main loop is serious.
> 
> To say it's not serious for HMP amounts to "don't do that then, use
> QMP".  Which may be fair.  Not for me to decide, though.

It's certainly more important for QMP; you don't want the main lock
being held for everyday type of interactions with management layers.

Dave

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH/RFC 0/1] Vhost User Cross Cable: Intro

[Stefan Hajnoczi]

On Thu, Feb 13, 2020 at 03:48:59PM +0200, Nikos Dragazis wrote:
> On Tue, 14 Jan 2020 at 10:20 Stefan Hajnoczi
>  wrote:
> > On Fri, Jan 10, 2020 at 10:34 AM Marc-André Lureau
> >  wrote:
> > > On Wed, Jan 8, 2020 at 5:57 AM V.  wrote:
> >
> > Hi V.,
> > I think I remember you from Etherboot/gPXE days :).
> >
> > > > 3.
> > > > Now if Cross Cable is actually a new and (after a code-rewrite of 10) a
> > > > viable way to connect 2 QEMU's together, could I actually
> > > > suggest a better way?
> > > > I am thinking of a '-netdev vhost-user-slave' option to connect (as 
> > > > client
> > > > or server) to a master QEMU running '-netdev vhost-user'.
> > > > This way there is no need for any external program at all, the master 
> > > > can
> > > > have it's memory unshared and everything would just work
> > > > and be fast.
> > > > Also the whole thing can fall back to normal virtio if memory is not 
> > > > shared
> > > > and it would even work in pure usermode without any
> > > > context switch.
> > > >
> > > > Building a patch for this idea I could maybe get around to, don't 
> > > > clearly
> > > > have an idea how much work this would be but I've done
> > > > crazier things.
> > > > But is this is something that someone might be able to whip up in an 
> > > > hour
> > > > or two? Someone who actually does have a clue about vhost
> > > > and virtio maybe? ;-)
> > >
> > > I believe https://wiki.qemu.org/Features/VirtioVhostUser is what you
> > > are after. It's still being discussed and non-trivial, but not very
> > > active lately afaik.
> >
> > virtio-vhost-user is being experimented with in the SPDK community but
> > there has been no activity on VIRTIO standardization or the QEMU
> > patches for some time.  More info here:
> > https://ndragazis.github.io/spdk.html
> >
> > I think the new ivshmem v2 feature may provide the functionality you
> > are looking for, but I haven't looked at them yet.  Here is the link:
> > https://www.mail-archive.com/address@hidden/msg668749.html
> >
> > And here is Jan's KVM Forum presentation on ivshmem v2:
> > https://www.youtube.com/watch?v=TiZrngLUFMA
> >
> > Stefan
> 
> 
> Hi Stefan,
> 
> First of all, sorry for the delayed response. The mail got lost
> somewhere in my inbox. Please keep Cc-ing me on all threads related to
> virtio-vhost-user.
> 
> As you correctly pointed out, I have been experimenting with
> virtio-vhost-user on SPDK and [1] is a working demo on this matter. I
> have been working on getting it merged with SPDK and, to this end, I
> have been interacting with the SPDK team [2][3] and mostly with Darek
> Stojaczyk (Cc-ing him).
> 
> The reason that you haven’t seen any activity for the last months is
> that I got a job and hence my schedule has become tighter. But I will
> definitely find some space and fit it into my schedule. Let me give you
> a heads up, so that we get synced:
> 
> Originally, I created and sent a patch (influenced from your DPDK patch
> [4]) to SPDK that was enhancing SPDK’s internal rte_vhost library with
> the virtio-vhost-user transport. However, a few weeks later, the SPDK
> team decided to switch from their internal rte_vhost library to using
> DPDK’s rte_vhost library directly [3]. Given that, I refactored and sent
> the patch for the virtio-vhost-user transport to the DPDK mailing list
> [5]. Regarding the virtio-vhost-user device, I have made some
> enhancements [6] on your original RFC device implementation and, as you
> may remember, I have sent some revised versions of the spec to the
> virtio mailing list [7].
> 
> At the moment, the blocker is the virtio spec. The last update on this
> was my discussion with Michael Tsirkin (Cc-ing him as well) about the
> need for the VIRTIO_PCI_CAP_DOORBELL_CFG and
> VIRTIO_PCI_CAP_NOTIFICATION_CFG configuration structures [8].
> 
> So, I think the next steps should be the following:
> 
> 1. merging the spec
> 2. adding the device on QEMU
> 3. adding the vvu transport on DPDK
> 4. extending SPDK to make use of the new vhost-user transport
> 
> To conclude, I still believe that this device is useful and should be
> part of virtio/qemu/dpdk/spdk and I will continue working on this
> direction.

Thanks for letting me know.  Feel free to resend the latest VIRTIO spec
changes to restart the discussion.  I am certainly interested.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH v2 2/4] virtio-scsi: default num_queues to -smp N

[Stefan Hajnoczi]

On Wed, Feb 12, 2020 at 11:18:32AM +, Stefan Hajnoczi wrote:
> On Tue, Feb 11, 2020 at 11:31:17AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2020 at 04:20:41PM +, Stefan Hajnoczi wrote:
> > > On Mon, Feb 03, 2020 at 12:39:49PM +0100, Sergio Lopez wrote:
> > > > On Mon, Feb 03, 2020 at 10:57:44AM +, Daniel P. Berrangé wrote:
> > > > > On Mon, Feb 03, 2020 at 11:25:29AM +0100, Sergio Lopez wrote:
> > > > > > On Thu, Jan 30, 2020 at 10:52:35AM +, Stefan Hajnoczi wrote:
> > > > > > > On Thu, Jan 30, 2020 at 01:29:16AM +0100, Paolo Bonzini wrote:
> > > > > > > > On 29/01/20 16:44, Stefan Hajnoczi wrote:
> > > > > > > > > On Mon, Jan 27, 2020 at 02:10:31PM +0100, Cornelia Huck wrote:
> > > > > > > > >> On Fri, 24 Jan 2020 10:01:57 +
> > > > > > > > >> Stefan Hajnoczi  wrote:
> > > I will create a 32 vCPU guest with 100 virtio-blk devices and verify
> > > that enabling multi-queue is successful.
> > 
> > and that it's helpful for performance?
> 
> I may be a little while before the next revision of this patch series.
> Testing reveals scalability problems when creating so many virtqueues
> :).
> 
> I've measured boot time, memory consumption, and random read IOPS.  They
> are all significantly worse (32 vCPUs, 24 GB RAM, 101 virtio-blk
> devices, 32 queues/device).
> 
> Time to see what's going on and whether some general scalability
> improvements are possible here before we enable multi-queue by default.

Update:

Boot time has improved with "[PATCH] memory: batch allocate ioeventfds[]
in address_space_update_ioeventfds()".

IOPS looks a lot better with the O(1) QEMU event loop patches that I've
posted.  This work is not complete yet, I still need to make AioContext
polling O(1) too (it consumes too much CPU with many idle devices).

After this work is complete I'll measure boot time, memory consumption,
and IOPS again.  Then we can decide whether multiqueue by default is a
good idea.

Stefan


signature.asc
Description: PGP signature

Re: [GSoC/Outreachy] Arduino complete setup visualization and emulation

[Stefan Hajnoczi]

On Tue, Feb 11, 2020 at 10:51:19AM +, Stefan Hajnoczi wrote:
> On Mon, Feb 10, 2020 at 08:58:28PM +0100, Philippe Mathieu-Daudé wrote:

Ping?

QEMU has been accepted as a mentoring organization.  Please post a final
version of this project idea on the wiki:

  https://wiki.qemu.org/Google_Summer_of_Code_2020

Thanks,
Stefan


signature.asc
Description: PGP signature

Re: [PATCH rc4 06/29] target/avr: Add defintions of AVR core types

[Michael Rolnik]

Hi all.

How is it going?

Regards,
Michael.

On Mon, Feb 10, 2020 at 9:39 AM Michael Rolnik  wrote:

> Hi all.
>
> When I decided to implement AVR 8 bit CPU support for QEMU I found this
> document
> 
>  which
> listed all AVR instructions.
> After that I learned that there are several CPU flavours, I looked into
> this GCC file
>  
> to
> figure out what are they as I could not find any official document
> explaining it.
> Then I downloaded several datasheets and created a list of instructions by
> CPU type (attached).It turned out that there are some variations
> e.g.
> - AVTTINY - some have LDS, some don't
> - AVR1, AVR25 - some have short SP, some don't
> - AVRXMEGA2, AVRXMEGA4, AVRXMEGA5, AVRXMEGA6, AVRXMEGA7 - some have RMW,
> some don't
> - AVRXMEGA3 - some have RCALL, some don't
>
> I decided to leave CPU flavour definition as suggested by GCC
> gcc/config/avr/avr-devices.c
> 
> file and when a specific MCU is created it will set / reset CPU features
> relevant to it.
>
> I hope this helps.
>
> Best Regards,
> Michael Rolnik
>
>
>
>
>
>
>
> On Sat, Feb 8, 2020 at 9:35 AM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Sunday, February 2, 2020, Joaquin de Andres 
>> wrote:
>>
>>> On 1/31/20 1:02 AM, Aleksandar Markovic wrote:
>>>
 From: Michael Rolnik 

 AVR core types are:

- avr1
- avr2
- avr25
- avr3
- avr31
- avr35
- avr4
- avr5
- avr51
- avr6
- avrtiny
- xmega2
- xmega3
- xmega4
- xmega5
- xmega6
- xmega7

 Each core type covers multiple AVR MCUs, mentioned in the comments
 before definition of particular AVR core type (part of this patch).

 AVR core type defines shared features that are valid for all AVR
 MCUs belonging in that type.

 [AM: Split a larger AVR introduction patch into logical units]
 Suggested-by: Aleksandar Markovic 

 Co-developed-by: Michael Rolnik 
 Co-developed-by: Sarah Harris 
 Signed-off-by: Michael Rolnik 
 Signed-off-by: Sarah Harris 
 Signed-off-by: Michael Rolnik 
 Acked-by: Igor Mammedov 
 Tested-by: Philippe Mathieu-Daudé 
 Signed-off-by: Richard Henderson 
 Signed-off-by: Aleksandar Markovic 
 ---
   target/avr/cpu.c | 601
 +++
   1 file changed, 601 insertions(+)

 diff --git a/target/avr/cpu.c b/target/avr/cpu.c
 index f41a887..e0ae055 100644
 --- a/target/avr/cpu.c
 +++ b/target/avr/cpu.c
 @@ -215,3 +215,604 @@ static void avr_cpu_class_init(ObjectClass *oc,
 void *data)
   cc->gdb_num_core_regs = 35;
   cc->gdb_core_xml_file = "avr-cpu.xml";
   }
 +
 +/*
 + * Setting features of AVR core type avr1
 + * --
 + *
 + * This type of AVR core is present in the following AVR MCUs:
 + *
 + * at90s1200, attiny11, attiny12, attiny15, attiny28
 + */
 +static void avr_avr1_initfn(Object *obj)
 +{
 +AVRCPU *cpu = AVR_CPU(obj);
 +CPUAVRState *env = &cpu->env;
 +
 +set_avr_feature(env, AVR_FEATURE_LPM);
 +set_avr_feature(env, AVR_FEATURE_2_BYTE_SP);
 +set_avr_feature(env, AVR_FEATURE_2_BYTE_PC);
 +}
 +
 +/*
 + * Setting features of AVR core type avr2
 + * --
 + *
 + * This type of AVR core is present in the following AVR MCUs:
 + *
 + * at90s2313, at90s2323, at90s2333, at90s2343, attiny22, attiny26,
 at90s4414,
 + * at90s4433, at90s4434, at90s8515, at90c8534, at90s8535
 + */
 +static void avr_avr2_initfn(Object *obj)
 +{
 +AVRCPU *cpu = AVR_CPU(obj);
 +CPUAVRState *env = &cpu->env;
 +
 +set_avr_feature(env, AVR_FEATURE_LPM);
 +set_avr_feature(env, AVR_FEATURE_IJMP_ICALL);
 +set_avr_feature(env, AVR_FEATURE_ADIW_SBIW);
 +set_avr_feature(env, AVR_FEATURE_SRAM);
 +set_avr_feature(env, AVR_FEATURE_BREAK);
 +
 +set_avr_feature(env, AVR_FEATURE_2_BYTE_PC);
 +set_avr_feature(env, AVR_FEATURE_2_BYTE_SP);
 +}
 +
 +/*
 + * Setting features of AVR core type avr25
 + * --
 + *
 + * This type of AVR core is present in the following AVR MCUs:
 + *
 + * ata5272, ata6616c, attiny13, attiny13a, attiny2313, attiny2313a,
 attiny24,
 + * attiny24a, attiny4313, attiny44, attiny44a, attiny441, attiny84,
 attiny84a,
 + * attiny25, attiny45, attiny85, attiny261, attiny261a, attiny461,
 attiny461a,
 + * attiny86

[Bug 1722884] Re: keyboard input while mouse moving triggers mouse failure

[Geoffrey McRae]

I tracked this down and fixed it last year, your issue is unrelated.

https://github.com/qemu/qemu/commit/143c04c7e0639e53086519592ead15d2556bfbf2
#diff-3b5bd599c018d558b135bd19647a00c6

https://github.com/qemu/qemu/commit/7abe7eb29494b4e4a11ec99ae5623083409a2f1e
#diff-3b5bd599c018d558b135bd19647a00c6

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

Title:
  keyboard input while mouse moving triggers mouse failure

Status in QEMU:
  New

Bug description:
  When QEMU is getting a ton of mouse input events if keys are pressed
  on the keyboard the scan code will be corrupted causing erroneous
  behavior. I have confirmed this problem in the latest version in git
  (530049bc1dcc24c1178a29d99ca08b6dd08413e0).

  After the erroneous behavior the operating system issues a keyboard
  reset which prevents the mouse from functioning until the operating
  system is restarted.

  This seems to only occur if the PS2 mouse is being used as the input,
  the tablet input device doesn't exhibit this behavior.

  The same problem was reported here also:
  https://openxt.atlassian.net/browse/OXT-562

  Host  : Debian 9
  CPU   : Ryzen 1700X
  RAM   : 16GB
  Kernel: 4.12.0-0.bpo.2-amd64

  Guest : Windows 10 (KVM)
  RAM   : 8GB (1GB Huge pages)

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

Re: [GSoC/Outreachy] Arduino complete setup visualization and emulation

[Philippe Mathieu-Daudé]

On 2/21/20 11:56 AM, Stefan Hajnoczi wrote:

On Tue, Feb 11, 2020 at 10:51:19AM +, Stefan Hajnoczi wrote:

On Mon, Feb 10, 2020 at 08:58:28PM +0100, Philippe Mathieu-Daudé wrote:


Ping?

QEMU has been accepted as a mentoring organization.  Please post a final
version of this project idea on the wiki:

   https://wiki.qemu.org/Google_Summer_of_Code_2020


I apologize, quickly after we chat on IRC about this last week I did the 
modifications but forgot to reply to this thread.


There is the project description with 1 FIXME and 2 TODO (add the 
references), we will update the wiki tomorrow:


---

[*] Goal

Be able to use a visual virtual Arduino board, and program it with
the Arduino IDE. The result should be easily usable by newcomers to
the Arduino world.

[*] Summary

The project will add a visual representation of an Arduino board.

By running the code on the emulated AVR processor, the virtual board is
updated and displays the changes. Interracting with the code via external
events (sensors) triggers changes on the UI.

[*] Materials provided

- a specific circuit configuration represented as a netlist.
- preset Arduino tests compliant with QEMU limitations
- QMP commands documentation

[*] Essential skills required

- Fluent in C
- Comfortable programming in Python
- Knowledge of Javascript might be useful (Java will *not* be used).
- Working knowledge with User Interfaces

* Electrical engineering background is not essential


[*] Deliverables

- IDE Integration
  Configure QEMU with the Arduino IDE (using chardev UART0).
  Compile program and upload via serial.
  The IDE doesn't need modifications.

- UI (Python)
  Connect UART1 (via QMP or chardev), display as textbox
  (input is not important at this point).

- QEMU: GPIO
  Produce a script to extract the GPIO devices from the netlist.
  Configure QEMU devices to use the previous names/values.
  Publish GPIO events (name as a string and tension as float) via
  a QMP socket (JSON form?).
  Write a test which runs FreeRTOS to generate a stable output.

- UI (Python)
  Connect to the QMP socket and display the GPIO events.
  Now GPIOs are connected to LEDs. Present graphical LEDs as ON/OFF.
  Add an oscilloscope representation (matplotlib widget). Each GPIO
  can be plugged into the oscilloscope channels.
  Add Switches and PushButtons to the UI, generating QMP events which
  trigger GPIO input.
  Add a push button to reset the Arduino (already on board) signaling to
  the core, and[to] switch for[to] general power (for QEMU shutdown and 
start).

  ### FIXME check with Joaquin ###

- QEMU: PWM
  Modify script to extract PWM devices used from the netlist.
  Configure QEMU devices to use the previous names/values.
  Use QEMU sound API to generate a stream of PWM values (as a wav).
  Add a QMP command to lookup the PWM wav stream.
  Write a FreeRTOS test producing a sinusoidal via PWM, verify the
  wav form.

- UI (Python)
  Lookup the wav stream via the QMP socket, connect to it, display
  it on the oscilloscope view.
  Add a graphical representation of the LED intensity.

- QEMU: ADC
  Modify the script to extract the ADC devices from the netlist.
  Similarly to PWM, use the sound wav stream to read ADC samples.

- UI: Python
  Add a textbox to set the ambient temperature (a thermometer is
  connected to some ADC pins).
  Use a slider to set the tension sampled by the ADC (like if it
  was a potentiometer).

[*] Test with the preset arduino examples (### TODO add references ###)

- Basic: "Blink: Turn a LED on and off."
- Analog: "Fading: Use an analog output (PWM pin) to dim a LED."
- Analog: "Analog Input: Use a potentiometer to control the flashing
  of a LED."

Additional tasks are available for applicants who completes the project.

[References]


[*] Prerequisites:

- AVR port and Arduino machines merged upstream
- AVR flash device working (for firmware upload via IDE)


Co-mentor: Philippe Mathieu-Daudé 
Co-mentor: Joaquín De Andres 


Reference Schema:

   +-+-+
   | | |
   | | |
   | | |
   | |Arduino IDE  |
   | | |
   | | |
   | +-+
   | | |
   | | |
   +-+--+--+
|
|console
  +--+  |chardev
  |  |  |
  |  <--+
  |   QEMU   |
  PWM stream  |  |
+-+ AVR core |
| |  |
| +---+  <--+
| |   |  |  |JSON
|JSON |   +--+  |event
|event| | I/O
| I/O |  

Re: [PATCH v3 1/4] luks: extract qcrypto_block_calculate_payload_offset()

[Stefan Hajnoczi]

On Wed, Feb 19, 2020 at 02:03:50PM +0100, Max Reitz wrote:
> On 11.02.20 17:03, Stefan Hajnoczi wrote:
> > The qcow2 .bdrv_measure() code calculates the crypto payload offset.
> > This logic really belongs in crypto/block.c where it can be reused by
> > other image formats.
> > 
> > The "luks" block driver will need this same logic in order to implement
> > .bdrv_measure(), so extract the qcrypto_block_calculate_payload_offset()
> > function now.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  block/qcow2.c  | 74 +++---
> >  crypto/block.c | 40 +++
> >  include/crypto/block.h | 22 +
> >  3 files changed, 81 insertions(+), 55 deletions(-)
> 
> [...]
> 
> > diff --git a/crypto/block.c b/crypto/block.c
> > index 325752871c..a9e1b8cc36 100644
> > --- a/crypto/block.c
> > +++ b/crypto/block.c
> > @@ -115,6 +115,46 @@ QCryptoBlock 
> > *qcrypto_block_create(QCryptoBlockCreateOptions *options,
> 
> [...]
> 
> > +bool
> > +qcrypto_block_calculate_payload_offset(QCryptoBlockCreateOptions 
> > *create_opts,
> > +   const char *optprefix,
> > +   size_t *len,
> > +   Error **errp)
> > +{
> > +QCryptoBlock *crypto;
> > +bool ok;
> > +
> > +/* Fake LUKS creation in order to determine the payload size */
> > +crypto = qcrypto_block_create(create_opts, optprefix,
> > +  qcrypto_block_headerlen_hdr_init_func,
> > +  qcrypto_block_headerlen_hdr_write_func,
> > +  len, errp);
> > +ok = crypto != NULL;
> > +qcrypto_block_free(crypto);
> > +return ok;
> 
> Speaking of g_autoptr...  Would g_autoptr(QCryptoBlock) crypto; suffice
> to contract these three lines into “return crypto != NULL;”?
> 
> Either way:
> 
> Reviewed-by: Max Reitz 

Yes, it can be simplified.  Will fix in v3.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH v3 2/4] luks: implement .bdrv_measure()

[Stefan Hajnoczi]

On Wed, Feb 19, 2020 at 04:46:34PM +0100, Max Reitz wrote:
> On 11.02.20 17:03, Stefan Hajnoczi wrote:
> > Add qemu-img measure support in the "luks" block driver.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  block/crypto.c | 62 ++
> >  1 file changed, 62 insertions(+)
> > 
> > diff --git a/block/crypto.c b/block/crypto.c
> > index 24823835c1..453119875e 100644
> > --- a/block/crypto.c
> > +++ b/block/crypto.c
> > @@ -484,6 +484,67 @@ static int64_t block_crypto_getlength(BlockDriverState 
> > *bs)
> 
> [...]
> 
> > +cryptoopts = qemu_opts_to_qdict_filtered(opts, NULL,
> > +&block_crypto_create_opts_luks, true);
> > +qdict_put_str(cryptoopts, "format", "luks");
> > +create_opts = block_crypto_create_opts_init(cryptoopts, errp);
> 
> It looks a bit weird to me to use errp here...
> 
> > +qobject_unref(cryptoopts);
> > +if (!create_opts) {
> > +goto err;
> > +}
> > +
> > +if (!qcrypto_block_calculate_payload_offset(create_opts, NULL,
> > +&luks_payload_size,
> > +&local_err)) {
> 
> ...and local_err here.  Either works, but consistent style would be a
> bit nicer.
> 
> But not more correct, so:
> 
> Reviewed-by: Max Reitz 

Thanks, will fix!

Stefan


signature.asc
Description: PGP signature

Re: [RFC v3 2/3] acpi:pci-expender-bus: Add pxb support for arm

[Michael S. Tsirkin]

On Fri, Feb 21, 2020 at 02:35:11PM +0800, Yubo Miao wrote:
> From: miaoyubo 
> 
> Currently virt machine is not supported by pxb-pcie,
> and only one main host bridge described in ACPI tables.
> In this patch,PXB-PCIE is supproted by arm and certain
> resource is allocated for each pxb-pcie in acpi table.
> The resource for the main host bridge is also reallocated.
> 
> Signed-off-by: miaoyubo 
> ---
>  hw/arm/virt-acpi-build.c | 125 +++
>  hw/pci-host/gpex.c   |   4 ++
>  include/hw/arm/virt.h|   7 +++
>  3 files changed, 125 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 0540234b8a..2c1e0d2aaa 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -49,6 +49,8 @@
>  #include "kvm_arm.h"
>  #include "migration/vmstate.h"
>  
> +#include "hw/arm/virt.h"
> +#include "hw/pci/pci_bus.h"
>  #define ARM_SPI_BASE 32
>  
>  static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
> @@ -271,19 +273,117 @@ static void acpi_dsdt_add_pci_osc(Aml *dev, Aml *scope)
>  }
>  
>  static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> -  uint32_t irq, bool use_highmem, bool 
> highmem_ecam)
> +  uint32_t irq, bool use_highmem, bool 
> highmem_ecam,
> +  VirtMachineState *vms)
>  {
>  int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> -Aml *method, *crs;
> +Aml *method, *dev, *crs;
> +int count = 0;
>  hwaddr base_mmio = memmap[VIRT_PCIE_MMIO].base;
>  hwaddr size_mmio = memmap[VIRT_PCIE_MMIO].size;
>  hwaddr base_pio = memmap[VIRT_PCIE_PIO].base;
>  hwaddr size_pio = memmap[VIRT_PCIE_PIO].size;
>  hwaddr base_ecam = memmap[ecam_id].base;
>  hwaddr size_ecam = memmap[ecam_id].size;
> +/*
> + * 0x60 would be enough for pxb device
> + * if it is too small, there is no enough space
> + * for a pcie device plugged in a pcie-root port
> + */
> +hwaddr size_addr = 0x60;
> +hwaddr size_io = 0x4000;
>  int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
> +int root_bus_limit = 0xFF;

what's this?

> +PCIBus *bus = NULL;
> +bus = VIRT_MACHINE(vms)->bus;

So just move assignment as part of declaration.

> +
> +if (bus) {
> +QLIST_FOREACH(bus, &bus->child, sibling) {
> +uint8_t bus_num = pci_bus_num(bus);
> +uint8_t numa_node = pci_bus_numa_node(bus);
> +
> +if (!pci_bus_is_root(bus)) {
> +continue;
> +}
> +if (bus_num < root_bus_limit) {
> +root_bus_limit = bus_num - 1;

what is this doing? manually coded up MIN?

> +}
> +count++;
> +dev = aml_device("PC%.02X", bus_num);
> +aml_append(dev, aml_name_decl("_HID", aml_string("PNP0A08")));
> +aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
> +aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> +aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> +aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> +aml_append(dev, aml_name_decl("_BBN", aml_int(bus_num)));
> +aml_append(dev, aml_name_decl("_UID", aml_int(bus_num)));
> +aml_append(dev, aml_name_decl("_STR", aml_unicode("pxb 
> Device")));
> +if (numa_node != NUMA_NODE_UNASSIGNED) {
> +method = aml_method("_PXM", 0, AML_NOTSERIALIZED);
> +aml_append(method, aml_return(aml_int(numa_node)));
> +aml_append(dev, method);
> +}
> +
> +acpi_dsdt_add_pci_route_table(dev, scope, nr_pcie_buses, irq);
> +
> +method = aml_method("_CBA", 0, AML_NOTSERIALIZED);
> +aml_append(method, aml_return(aml_int(base_ecam)));
> +aml_append(dev, method);
> +
> +method = aml_method("_CRS", 0, AML_NOTSERIALIZED);
> +Aml *rbuf = aml_resource_template();
> +aml_append(rbuf,
> +   aml_word_bus_number(AML_MIN_FIXED, AML_MAX_FIXED,
> +   AML_POS_DECODE, 0x,
> +   bus_num, bus_num + 1, 0x,
> +   2));
> +aml_append(rbuf,
> +   aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED,
> +AML_MAX_FIXED, AML_NON_CACHEABLE,
> +AML_READ_WRITE, 0x,
> +base_mmio + size_mmio -
> +size_addr * count,
> +base_mmio + size_mmio - 1 -
> +size_addr * (count - 1),
> +0x, size_addr));
> +aml_append(rbuf,
> +  

Re: [RFC v3 3/3] ACPI/unit-test: Add a new test for pxb-pcie for arm

[Michael S. Tsirkin]

On Fri, Feb 21, 2020 at 02:35:12PM +0800, Yubo Miao wrote:
> From: miaoyubo 
> 
> Currently, pxb-pcie could be defined by the cmdline like
> --device pxb-pcie,id=pci.9,bus_nr=128
> However pxb-pcie is not described in acpi tables for arm.
> 
> The formal two patches support pxb-pcie for arm, escpcially the
> specification for pxb-pcie in DSDT table.
> 
> Add a testcase to make sure the ACPI table is correct for guest.
> 
> Signed-off-by: miaoyubo 


Please look at the top of tests/qtest/bios-tables-test.c
for how to add or update tests.

> ---
>  tests/data/acpi/virt/DSDT.pxb  | Bin 0 -> 34209 bytes
>  tests/qtest/bios-tables-test.c |  54 +
>  2 files changed, 48 insertions(+), 6 deletions(-)
>  create mode 100644 tests/data/acpi/virt/DSDT.pxb
> 
> diff --git a/tests/data/acpi/virt/DSDT.pxb b/tests/data/acpi/virt/DSDT.pxb
> new file mode 100644
> index 
> ..4eea3192c75ff28f7054d626a9363ca025b6c0ad
> GIT binary patch

I can't read this.

> literal 34209
> zcmeI*cXU+szJ~D)1PGxe5PG+us9-{YGz}UAMT!L#ks?x*Dx!d5hoIPd
> z?}}o>iWL;GW5HgrlKbvVM&HM??^)~qbMIProvd|8p2_U*%qO!m?AgcPkRQ( zR3DKyBsMVKK5tZUEMJ#Z3xXj0I{cizY-H-_vUpxu>HLbszg^Hd*
> zYT59@{GfDxK}u{$QSzH5MFX?4va_qcnOYVriD$G-YqqdX5KgQUqzA#0T0ymH9aJ-P
> zt=#;Qdf_)p=V$jH6t9{xXmH68P3ev)8EFlwrs(=X$_(9dxJh>6UU8FZi5vcVla%Bp
> zz50)g^-pXvw4i9XAYFAU@nN}Xb+t___n%uw)`8L
> z7F4goX88!*;pB+$X8&bG_2BOj*;OO*!h6xx&B+mI)uU#l*o>||BPVi3ji?#5Y(|dH
> z=oUF6C2B^h&FJPcx<}5a88su#W_0%%JtAk+ikeZ+X7unGJtJq-j+)WHX7uzKy&`9%

...

Re: [PULL 00/13] Linux user for 5.0 patches

[Peter Maydell]

On Thu, 20 Feb 2020 at 09:22, Laurent Vivier  wrote:
>
> The following changes since commit 6c599282f8ab382fe59f03a6cae755b89561a7b3:
>
>   Merge remote-tracking branch 
> 'remotes/armbru/tags/pull-monitor-2020-02-15-v2' into staging (2020-02-17 
> 13:32:25 +)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu.git tags/linux-user-for-5.0-pull-request
>
> for you to fetch changes up to 045823a98c30fbcafa6d6b61a28b284de7038f07:
>
>   linux-user: Add support for selected alsa timer instructions using ioctls 
> (2020-02-19 11:17:40 +0100)
>
> 
> Implement membarrier, SO_RCVTIMEO and SO_SNDTIMEO
> Disable by default build of fdt, slirp and tools with linux-user
> Improve strace and use qemu_log to send trace to a file
> Add partial ALSA ioctl supports


Applied, thanks.

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

-- PMM

[PATCH v4 3/4] qemu-img: allow qemu-img measure --object without a filename

[Stefan Hajnoczi]

In most qemu-img sub-commands the --object option only makes sense when
there is a filename.  qemu-img measure is an exception because objects
may be referenced from the image creation options instead of an existing
image file.  Allow --object without a filename.

Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Max Reitz 
---
 qemu-img.c   | 6 ++
 tests/qemu-iotests/178   | 2 +-
 tests/qemu-iotests/178.out.qcow2 | 8 
 tests/qemu-iotests/178.out.raw   | 8 
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index 2b4562b9d9..0cee7bed8b 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -4912,10 +4912,8 @@ static int img_measure(int argc, char **argv)
 filename = argv[optind];
 }
 
-if (!filename &&
-(object_opts || image_opts || fmt || snapshot_name || sn_opts)) {
-error_report("--object, --image-opts, -f, and -l "
- "require a filename argument.");
+if (!filename && (image_opts || fmt || snapshot_name || sn_opts)) {
+error_report("--image-opts, -f, and -l require a filename argument.");
 goto out;
 }
 if (filename && img_size != UINT64_MAX) {
diff --git a/tests/qemu-iotests/178 b/tests/qemu-iotests/178
index 51a70fe669..7cf0e27154 100755
--- a/tests/qemu-iotests/178
+++ b/tests/qemu-iotests/178
@@ -50,7 +50,7 @@ _make_test_img 1G
 $QEMU_IMG measure # missing arguments
 $QEMU_IMG measure --size 2G "$TEST_IMG" # only one allowed
 $QEMU_IMG measure "$TEST_IMG" a # only one filename allowed
-$QEMU_IMG measure --object secret,id=sec0,data=MTIzNDU2,format=base64 # 
missing filename
+$QEMU_IMG measure --object secret,id=sec0,data=MTIzNDU2,format=base64 # size 
or filename needed
 $QEMU_IMG measure --image-opts # missing filename
 $QEMU_IMG measure -f qcow2 # missing filename
 $QEMU_IMG measure -l snap1 # missing filename
diff --git a/tests/qemu-iotests/178.out.qcow2 b/tests/qemu-iotests/178.out.qcow2
index 9e7d8c44df..f59bf4b2fb 100644
--- a/tests/qemu-iotests/178.out.qcow2
+++ b/tests/qemu-iotests/178.out.qcow2
@@ -5,10 +5,10 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 qemu-img: Either --size N or one filename must be specified.
 qemu-img: --size N cannot be used together with a filename.
 qemu-img: At most one filename argument is allowed.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
+qemu-img: Either --size N or one filename must be specified.
+qemu-img: --image-opts, -f, and -l require a filename argument.
+qemu-img: --image-opts, -f, and -l require a filename argument.
+qemu-img: --image-opts, -f, and -l require a filename argument.
 qemu-img: Invalid option list: ,
 qemu-img: Invalid parameter 'snapshot.foo'
 qemu-img: Failed in parsing snapshot param 'snapshot.foo'
diff --git a/tests/qemu-iotests/178.out.raw b/tests/qemu-iotests/178.out.raw
index 6478365905..404ca908d8 100644
--- a/tests/qemu-iotests/178.out.raw
+++ b/tests/qemu-iotests/178.out.raw
@@ -5,10 +5,10 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 qemu-img: Either --size N or one filename must be specified.
 qemu-img: --size N cannot be used together with a filename.
 qemu-img: At most one filename argument is allowed.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
-qemu-img: --object, --image-opts, -f, and -l require a filename argument.
+qemu-img: Either --size N or one filename must be specified.
+qemu-img: --image-opts, -f, and -l require a filename argument.
+qemu-img: --image-opts, -f, and -l require a filename argument.
+qemu-img: --image-opts, -f, and -l require a filename argument.
 qemu-img: Invalid option list: ,
 qemu-img: Invalid parameter 'snapshot.foo'
 qemu-img: Failed in parsing snapshot param 'snapshot.foo'
-- 
2.24.1

[PATCH v4 2/4] luks: implement .bdrv_measure()

[Stefan Hajnoczi]

Add qemu-img measure support in the "luks" block driver.

Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Max Reitz 
---
 block/crypto.c | 62 ++
 1 file changed, 62 insertions(+)

diff --git a/block/crypto.c b/block/crypto.c
index 24823835c1..23e9c74d6f 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -484,6 +484,67 @@ static int64_t block_crypto_getlength(BlockDriverState *bs)
 }
 
 
+static BlockMeasureInfo *block_crypto_measure(QemuOpts *opts,
+  BlockDriverState *in_bs,
+  Error **errp)
+{
+g_autoptr(QCryptoBlockCreateOptions) create_opts = NULL;
+Error *local_err = NULL;
+BlockMeasureInfo *info;
+uint64_t size;
+size_t luks_payload_size;
+QDict *cryptoopts;
+
+/*
+ * Preallocation mode doesn't affect size requirements but we must consume
+ * the option.
+ */
+g_free(qemu_opt_get_del(opts, BLOCK_OPT_PREALLOC));
+
+size = qemu_opt_get_size_del(opts, BLOCK_OPT_SIZE, 0);
+
+if (in_bs) {
+int64_t ssize = bdrv_getlength(in_bs);
+
+if (ssize < 0) {
+error_setg_errno(&local_err, -ssize,
+ "Unable to get image virtual_size");
+goto err;
+}
+
+size = ssize;
+}
+
+cryptoopts = qemu_opts_to_qdict_filtered(opts, NULL,
+&block_crypto_create_opts_luks, true);
+qdict_put_str(cryptoopts, "format", "luks");
+create_opts = block_crypto_create_opts_init(cryptoopts, &local_err);
+qobject_unref(cryptoopts);
+if (!create_opts) {
+goto err;
+}
+
+if (!qcrypto_block_calculate_payload_offset(create_opts, NULL,
+&luks_payload_size,
+&local_err)) {
+goto err;
+}
+
+/*
+ * Unallocated blocks are still encrypted so allocation status makes no
+ * difference to the file size.
+ */
+info = g_new(BlockMeasureInfo, 1);
+info->fully_allocated = luks_payload_size + size;
+info->required = luks_payload_size + size;
+return info;
+
+err:
+error_propagate(errp, local_err);
+return NULL;
+}
+
+
 static int block_crypto_probe_luks(const uint8_t *buf,
int buf_size,
const char *filename) {
@@ -670,6 +731,7 @@ static BlockDriver bdrv_crypto_luks = {
 .bdrv_co_preadv = block_crypto_co_preadv,
 .bdrv_co_pwritev= block_crypto_co_pwritev,
 .bdrv_getlength = block_crypto_getlength,
+.bdrv_measure   = block_crypto_measure,
 .bdrv_get_info  = block_crypto_get_info_luks,
 .bdrv_get_specific_info = block_crypto_get_specific_info_luks,
 
-- 
2.24.1

[PATCH v4 1/4] luks: extract qcrypto_block_calculate_payload_offset()

[Stefan Hajnoczi]

The qcow2 .bdrv_measure() code calculates the crypto payload offset.
This logic really belongs in crypto/block.c where it can be reused by
other image formats.

The "luks" block driver will need this same logic in order to implement
.bdrv_measure(), so extract the qcrypto_block_calculate_payload_offset()
function now.

Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Max Reitz 
---
 block/qcow2.c  | 74 +++---
 crypto/block.c | 36 
 include/crypto/block.h | 22 +
 3 files changed, 77 insertions(+), 55 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 8dcee5efec..59df7ec0ce 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -4601,60 +4601,6 @@ static coroutine_fn int 
qcow2_co_flush_to_os(BlockDriverState *bs)
 return ret;
 }
 
-static ssize_t qcow2_measure_crypto_hdr_init_func(QCryptoBlock *block,
-size_t headerlen, void *opaque, Error **errp)
-{
-size_t *headerlenp = opaque;
-
-/* Stash away the payload size */
-*headerlenp = headerlen;
-return 0;
-}
-
-static ssize_t qcow2_measure_crypto_hdr_write_func(QCryptoBlock *block,
-size_t offset, const uint8_t *buf, size_t buflen,
-void *opaque, Error **errp)
-{
-/* Discard the bytes, we're not actually writing to an image */
-return buflen;
-}
-
-/* Determine the number of bytes for the LUKS payload */
-static bool qcow2_measure_luks_headerlen(QemuOpts *opts, size_t *len,
- Error **errp)
-{
-QDict *opts_qdict;
-QDict *cryptoopts_qdict;
-QCryptoBlockCreateOptions *cryptoopts;
-QCryptoBlock *crypto;
-
-/* Extract "encrypt." options into a qdict */
-opts_qdict = qemu_opts_to_qdict(opts, NULL);
-qdict_extract_subqdict(opts_qdict, &cryptoopts_qdict, "encrypt.");
-qobject_unref(opts_qdict);
-
-/* Build QCryptoBlockCreateOptions object from qdict */
-qdict_put_str(cryptoopts_qdict, "format", "luks");
-cryptoopts = block_crypto_create_opts_init(cryptoopts_qdict, errp);
-qobject_unref(cryptoopts_qdict);
-if (!cryptoopts) {
-return false;
-}
-
-/* Fake LUKS creation in order to determine the payload size */
-crypto = qcrypto_block_create(cryptoopts, "encrypt.",
-  qcow2_measure_crypto_hdr_init_func,
-  qcow2_measure_crypto_hdr_write_func,
-  len, errp);
-qapi_free_QCryptoBlockCreateOptions(cryptoopts);
-if (!crypto) {
-return false;
-}
-
-qcrypto_block_free(crypto);
-return true;
-}
-
 static BlockMeasureInfo *qcow2_measure(QemuOpts *opts, BlockDriverState *in_bs,
Error **errp)
 {
@@ -4705,9 +4651,27 @@ static BlockMeasureInfo *qcow2_measure(QemuOpts *opts, 
BlockDriverState *in_bs,
 g_free(optstr);
 
 if (has_luks) {
+g_autoptr(QCryptoBlockCreateOptions) create_opts = NULL;
+QDict *opts_qdict;
+QDict *cryptoopts;
 size_t headerlen;
 
-if (!qcow2_measure_luks_headerlen(opts, &headerlen, &local_err)) {
+opts_qdict = qemu_opts_to_qdict(opts, NULL);
+qdict_extract_subqdict(opts_qdict, &cryptoopts, "encrypt.");
+qobject_unref(opts_qdict);
+
+qdict_put_str(cryptoopts, "format", "luks");
+
+create_opts = block_crypto_create_opts_init(cryptoopts, errp);
+qobject_unref(cryptoopts);
+if (!create_opts) {
+goto err;
+}
+
+if (!qcrypto_block_calculate_payload_offset(create_opts,
+"encrypt.",
+&headerlen,
+&local_err)) {
 goto err;
 }
 
diff --git a/crypto/block.c b/crypto/block.c
index 325752871c..6f42b32f1e 100644
--- a/crypto/block.c
+++ b/crypto/block.c
@@ -115,6 +115,42 @@ QCryptoBlock 
*qcrypto_block_create(QCryptoBlockCreateOptions *options,
 }
 
 
+static ssize_t qcrypto_block_headerlen_hdr_init_func(QCryptoBlock *block,
+size_t headerlen, void *opaque, Error **errp)
+{
+size_t *headerlenp = opaque;
+
+/* Stash away the payload size */
+*headerlenp = headerlen;
+return 0;
+}
+
+
+static ssize_t qcrypto_block_headerlen_hdr_write_func(QCryptoBlock *block,
+size_t offset, const uint8_t *buf, size_t buflen,
+void *opaque, Error **errp)
+{
+/* Discard the bytes, we're not actually writing to an image */
+return buflen;
+}
+
+
+bool
+qcrypto_block_calculate_payload_offset(QCryptoBlockCreateOptions *create_opts,
+   const char *optprefix,
+   size_t *len,
+   Error **errp)
+{
+/* Fake LUKS creation in order to determine the payload size */
+g_autoptr(QCryptoBlock) crypto =
+qcrypto_block_create(create_

[PATCH v4 0/4] luks: add qemu-img measure support

[Stefan Hajnoczi]

v4:
 * This revision is what German speakers call "das Tüpfelchen auf dem I".  "The
   icing on the cake" is the English equivalent.  Since I like cake and don't
   want it to be half-baked, and because I like my metaphors shaken, not
   stirred, I went ahead with the extra revision so I could write this message.
 * Use g_autoptr(QCryptoBlock) to make the code more concise [Max]
 * Use local_err consistently [Max]
 * Folded in Max's Reviewed-by tags
v3:
 * Move payload offset calculation function to crypto/block.c [Max]
 * Zero/unallocated blocks always require disk space on encrypted files [Max]
 * Update qemu-iotests 178 output when changing qemu-img measure command-line
   options

v2:
 * Fix uint64_t <-> size_t type mismatch in block_crypto_measure() so that
   32-bit builds pass

This patch series adds qemu-img measure support to the "luks" block driver.  We
just need to take into account the LUKS header when sizing the image.

Stefan Hajnoczi (4):
  luks: extract qcrypto_block_calculate_payload_offset()
  luks: implement .bdrv_measure()
  qemu-img: allow qemu-img measure --object without a filename
  iotests: add 282 luks qemu-img measure test

 block/crypto.c   | 62 +
 block/qcow2.c| 74 +++--
 crypto/block.c   | 36 +
 include/crypto/block.h   | 22 
 qemu-img.c   |  6 +--
 tests/qemu-iotests/178   |  2 +-
 tests/qemu-iotests/178.out.qcow2 |  8 +--
 tests/qemu-iotests/178.out.raw   |  8 +--
 tests/qemu-iotests/282   | 93 
 tests/qemu-iotests/282.out   | 30 +++
 tests/qemu-iotests/group |  1 +
 11 files changed, 274 insertions(+), 68 deletions(-)
 create mode 100755 tests/qemu-iotests/282
 create mode 100644 tests/qemu-iotests/282.out

-- 
2.24.1

[PATCH v4 4/4] iotests: add 282 luks qemu-img measure test

[Stefan Hajnoczi]

This test exercises the block/crypto.c "luks" block driver
.bdrv_measure() code.

Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Max Reitz 
---
 tests/qemu-iotests/282 | 93 ++
 tests/qemu-iotests/282.out | 30 
 tests/qemu-iotests/group   |  1 +
 3 files changed, 124 insertions(+)
 create mode 100755 tests/qemu-iotests/282
 create mode 100644 tests/qemu-iotests/282.out

diff --git a/tests/qemu-iotests/282 b/tests/qemu-iotests/282
new file mode 100755
index 00..6c62065aef
--- /dev/null
+++ b/tests/qemu-iotests/282
@@ -0,0 +1,93 @@
+#!/usr/bin/env bash
+#
+# qemu-img measure tests for LUKS images
+#
+# Copyright (C) 2020 Red Hat, Inc.
+#
+# 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 .
+#
+
+# creator
+owner=stefa...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1# failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+rm -f "$TEST_IMG.converted"
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.pattern
+
+_supported_fmt luks
+_supported_proto file
+_supported_os Linux
+
+SECRET=secret,id=sec0,data=passphrase
+
+echo "== measure 1G image file =="
+echo
+
+$QEMU_IMG measure --object "$SECRET" \
+ -O "$IMGFMT" \
+ -o key-secret=sec0,iter-time=10 \
+ --size 1G
+
+echo
+echo "== create 1G image file (size should be no greater than measured) =="
+echo
+
+_make_test_img 1G
+stat -c "image file size in bytes: %s" "$TEST_IMG_FILE"
+
+echo
+echo "== modified 1G image file (size should be no greater than measured) =="
+echo
+
+$QEMU_IO --object "$SECRET" --image-opts "$TEST_IMG" -c "write -P 0x51 0x1 
0x400" | _filter_qemu_io | _filter_testdir
+stat -c "image file size in bytes: %s" "$TEST_IMG_FILE"
+
+echo
+echo "== measure preallocation=falloc 1G image file =="
+echo
+
+$QEMU_IMG measure --object "$SECRET" \
+ -O "$IMGFMT" \
+ -o key-secret=sec0,iter-time=10,preallocation=falloc \
+ --size 1G
+
+echo
+echo "== measure with input image file =="
+echo
+
+IMGFMT=raw IMGKEYSECRET= IMGOPTS= _make_test_img 1G | _filter_imgfmt
+QEMU_IO_OPTIONS= IMGOPTSSYNTAX= $QEMU_IO -f raw -c "write -P 0x51 0x1 
0x400" "$TEST_IMG_FILE" | _filter_qemu_io | _filter_testdir
+$QEMU_IMG measure --object "$SECRET" \
+ -O "$IMGFMT" \
+ -o key-secret=sec0,iter-time=10 \
+ -f raw \
+ "$TEST_IMG_FILE"
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/282.out b/tests/qemu-iotests/282.out
new file mode 100644
index 00..996cc44a67
--- /dev/null
+++ b/tests/qemu-iotests/282.out
@@ -0,0 +1,30 @@
+QA output created by 282
+== measure 1G image file ==
+
+required size: 1075810304
+fully allocated size: 1075810304
+
+== create 1G image file (size should be no greater than measured) ==
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
+image file size in bytes: 1075810304
+
+== modified 1G image file (size should be no greater than measured) ==
+
+wrote 1024/1024 bytes at offset 65536
+1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+image file size in bytes: 1075810304
+
+== measure preallocation=falloc 1G image file ==
+
+required size: 1075810304
+fully allocated size: 1075810304
+
+== measure with input image file ==
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
+wrote 1024/1024 bytes at offset 65536
+1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+required size: 1075810304
+fully allocated size: 1075810304
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 1904223020..6a25efea4d 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -289,4 +289,5 @@
 279 rw backing quick
 280 rw migration quick
 281 rw quick
+282 quick
 283 auto quick
-- 
2.24.1

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

[Programmingkid]

> On Feb 21, 2020, at 4:13 AM, Howard Spoelstra  wrote:
> 
> Hi,
> 
> It might be worth mentioning that any testing of your screamer implementation 
> with MacOS/OSX guests on the mac99 machine needs a custom-built openbios.
> 
> Where possible I'll compare your screamer with the current screamer 
> implementation built from:
> git clone -b screamer https://github.com/mcayland/qemu 
> 
> All tests on OSX Sierra host with system sounds and MP3 playback through 
> latest QuickTime and iTunes available for the guest. Host is Intel i7-4770K 
> at 3.50Ghz. 32Gb memory. Audio device is an USB headset.
> Overall very subjective impression is that sound problems seem to arise 
> quicker with strong changes in volume in the stream. Silence is produced 
> perfectly...
> I should note that I also tested earlier with a windows build and that I had 
> to re-install Mac OS on three occasions to get sound going with your 
> screamer. Whether that was caused by a faulty installation or your screamer 
> is unclear to me.
> 
> There we go:
> 
> Mac OS 9.0.4: mac99,via=cuda
> Apple audio extension often fails to load. (Not restricted to your screamer. 
> This is a longstanding issue.) See at bottom for OSX crash report.
> Your screamer: shows only CD in Sound CP Input panel. Play sound through 
> output device is selected.
> Current screamer: shows CD + External Mic. Play sound through output device 
> is selected.
> 
> Mac OS 9.1: mac99,via=cuda
> Your screamer: No Input selection in the Sound CP. 
> Current screamer: Has External Mic (but no CD) in Sound CP. Play sound 
> through output device is not selected.
> 
> Mac OS 9.2: mac99,via=pmu
> Your screamer: mp3 through iTunes and QuickTime OK. System sounds OK.
> Current screamer: Has considerably more problems playing two streams 
> simultaneously. (mp3 through both QuickTime and iTunes.)
> 
> Mac OS X 10.0: mac99,via=cuda
> Your screamer: setting the sound balance from middle position to the left 
> seems to control volume.
> Current screamer: Serious number of drop-outs when playing MP3 through 
> QuickTime. Not when using iTunes. Has issues when moving the sound balance. 
> 
> Mac OS X 10.1: mac99,via=cuda
> Off-topic: Interestingly, when booting with via=pmu, the same error occurs as 
> reported above.
> Your screamer: QuickTime: drop-outs. iTunes OK, even with playing system 
> sounds through the stream. Balance has same problem as above.
> Current screamer: Serious drop-outs through both QuickTime and iTunes when 
> playing MP3. Balance sync gets completely lost after moving slider. More lag 
> in response to clicking system sounds.
> 
> Mac OSX 10.2: no test due to longstanding video issue with opening folders.
> 
> Mac OSX 10.3: mac99,via=pmu
> Your screamer: drop-outs with QuickTime and iTunes. But not the clicks heard 
> as mentioned below. Opening the Sound preferences when playing MP3 is OK. 
> System sounds playing through the stream produce crackling sound. systems 
> sounds stop playing after several clicks on different ones. I hear parts of 
> earlier clicked sound when new one clicked.
> Current screamer: intermittent clicks (0.5 seconds) when playing MP3 with 
> QuickTime and iTunes. But QuickTime much better compared to 10.1. Currently 
> playing mp3 gets completely distorted (doubled?) when opening Sound 
> preferences.
> 
> Mac OSX 10.4: mac99,via=pmu
> Off-topic: From 10.4 onward, Internet radio works in iTunes. Channel update 
> is very slow in 10.4...
> Your screamer: drop-outs with QuickTime. Sounds comparable to current 
> screamer. Opening Sound preferences is OK, but can make stream spiral out of 
> control with an echo. Seems to happen quicker when playing sound with strong 
> stereo effects. But always quickly recovers, unlike current screamer. iTunes 
> also produces drop-outs. Also with internet stream, but is almost listenable.
> Current screamer: drop-outs with QuickTime. Sounds like stream is not always 
> in correct order. Sound crackles. iTunes almost OK. I can hear one or two 
> clicks after stopping audio. Opening Sound preferences makes stream spiral 
> out of control with an echo.
> 
> Mac OSX 10.5: mac99,via=pmu
> Your screamer: Drop-outs with QuickTime. A bit less-so with iTunes. Opening 
> Sound preferences provides same experience as with 10.4. Internet stream 
> almost listenable.
> Current screamer: QuickTime produces drop-outs. Sound control panel spirals 
> out of control. Small audio parts still played when stopping QuickTime. 
> iTunes almost OK with MP3 playback, only small drop-outs. Same with Internet 
> radio. 
> 
> For good measure I also tested 10.5 with your screamer and the recent 
> hardfloat patches which improve fpu performance from 9% to 11% of a real G4 
> 1Ghz ;-)
> I did not experience a considerable improvement in sound quality.
> 
> Best,
> Howard
> 
> OSX host Crash report when audio extension fails:
> 
> Crashed Thread:2
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:  

Re: [PATCH 2/2] vhost-use-blk: convert to new virtio_delete_queue

[Stefan Hajnoczi]

On Thu, Feb 13, 2020 at 09:28:07AM +0800, pannengy...@huawei.com wrote:
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 2eba8b9db0..ed6a5cc03b 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -420,9 +420,10 @@ static void vhost_user_blk_device_realize(DeviceState 
> *dev, Error **errp)
>  virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
>  sizeof(struct virtio_blk_config));
>  
> +s->virtqs = g_new0(VirtQueue *, s->num_queues);

Minor point, up to you if you want to change it: the array is fully
initialized by the for loop in the next line.  There is no need to clear
the memory first:

s/g_new0/g_new/

> diff --git a/include/hw/virtio/vhost-user-blk.h 
> b/include/hw/virtio/vhost-user-blk.h
> index 108bfadeeb..f68911f6f0 100644
> --- a/include/hw/virtio/vhost-user-blk.h
> +++ b/include/hw/virtio/vhost-user-blk.h
> @@ -37,6 +37,7 @@ typedef struct VHostUserBlk {
>  struct vhost_inflight *inflight;
>  VhostUserState vhost_user;
>  struct vhost_virtqueue *vqs;
> +VirtQueue **virtqs;

Both vqs and virtqs exist and are easily confused.  Please rename vqs to
vhost_vqs.


signature.asc
Description: PGP signature

Re: [PATCH 1/2] vhost-user-blk: delete virtioqueues in unrealize to fix memleaks

[Stefan Hajnoczi]

On Thu, Feb 13, 2020 at 09:28:06AM +0800, pannengy...@huawei.com wrote:
> From: Pan Nengyuan 
> 
> virtio queues forgot to delete in unrealize, and aslo error path in
> realize, this patch fix these memleaks, the leak stack is as follow:
> 
> Direct leak of 114688 byte(s) in 16 object(s) allocated from:
> #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0)
> #1 0x7f2401642015 in g_malloc0 (/lib64/libglib-2.0.so.0+0x50015)
> #2 0x55ad175a6447 in virtio_add_queue 
> /mnt/sdb/qemu/hw/virtio/virtio.c:2327
> #3 0x55ad17570cf9 in vhost_user_blk_device_realize 
> /mnt/sdb/qemu/hw/block/vhost-user-blk.c:419
> #4 0x55ad175a3707 in virtio_device_realize 
> /mnt/sdb/qemu/hw/virtio/virtio.c:3509
> #5 0x55ad176ad0d1 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:876
> #6 0x55ad1781ff9d in property_set_bool /mnt/sdb/qemu/qom/object.c:2080
> #7 0x55ad178245ae in object_property_set_qobject 
> /mnt/sdb/qemu/qom/qom-qobject.c:26
> #8 0x55ad17821eb4 in object_property_set_bool 
> /mnt/sdb/qemu/qom/object.c:1338
> #9 0x55ad177aeed7 in virtio_pci_realize 
> /mnt/sdb/qemu/hw/virtio/virtio-pci.c:1801
> 
> Reported-by: Euler Robot 
> Signed-off-by: Pan Nengyuan 
> ---
>  hw/block/vhost-user-blk.c | 8 
>  1 file changed, 8 insertions(+)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH] hw/char/pl011: Output characters using best-effort mode

[Paolo Bonzini]

On 21/02/20 11:21, Peter Maydell wrote:
> Before you do that, I would suggest investigating:
>  * is this a problem we've already had on x86 and that there is a
>standard solution for
Disconnected sockets always lose data (see tcp_chr_write in
chardev/char-socket.c).

For connected sockets, 8250 does at most 4 retries (each retry is
triggered by POLLOUT|POLLHUP).  After these four retries the output
chardev is considered broken, just like in Gavin's patch, and only a
reset will restart the output.

>  * should this be applicable to more than just the socket chardev?
>What's special about the socket chardev?

For 8250 there's no difference between socket and everything else.

Paolo

> I've added the chardev backend maintainers to the cc list.

Re: [PATCH] tcg: gdbstub: Fix single-step issue on arm target

[Changbin Du]

On Thu, Feb 20, 2020 at 10:24:37PM +0100, Luc Michel wrote:
> I'm curious, I never experienced this behaviour from GDB. What GDB and
> QEMU versions are you using?
> 
> On my side (GDB 9.1), even without 'vContSupported+' in the 'qSupported'
> answer, GDB sends a 'vCont?' packet on the first stepi:
> 
> 0x in ?? ()
> (gdb) si
> Sending packet: $m0,4#fd...Ack
> Packet received: 
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;s:p1.1;c:p1.-1#f7...Ack
> Packet received: T05thread:p01.01;
> 
> Your second issue (wrong PC value) should be investigated though. Does
> it happen on QEMU vanilla? Do you have a way to reproduce this bug?
> 
Just confirmed this issue. This is an endianness problem for gdb. I was
debugging an big-endian elf and my host cpu is little-endian. QEMU gdbstub
always uses host cpu endian but gdb client treats it as big-endian by
inspecting elf info.

I can mannually set it to little-endian but it is painful. The gdb complains
abount invalid opcode error in debuginfo.

I also noticed that someoneelse has already tried to resolve this issue.
https://patchwork.kernel.org/patch/9528947/

> Anyway after re-reading the GDB remote protocol documentation, I think
> your patch is right, the feature should be advertised.
> 
> However I think your commit message needs some modifications. This fix
> is not specific to ARM or TCG, but to the gdbstub itself. You also
> mention this bug you have with PC, which is not related to the bug you
> are fixing here. Could you rewrite it in a more generic way? You simply
> need to emphasis the effect of advertising the 'vContSupported+' feature
> on GDB.
> 
> Thanks.
> 
> -- 
> Luc

-- 
Cheers,
Changbin Du

Re: [PATCH] pcie_root_port: Add disable_hotplug option

[Daniel P . Berrangé]

On Tue, Feb 18, 2020 at 12:18:04PM -0500, Laine Stump wrote:
> On 2/18/20 11:17 AM, Julia Suvorova wrote:
> > Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt
> > to manage it and restrict unplug for the entire machine. This is going
> > to prevent user-initiated unplug in guests (Windows mostly).
> > Usage:
> >  -device pcie-root-port,disable-hotplug=true,...
> 
> Double negatives (e.g. "disable-hotplug=false") tend to confuse simple minds
> like mine. Would it be any more difficult to make the name of the option
> positive instead (e.g. "enable-hotplug") with the default set to "true"?

Or simply  "hotpluggable=on|off"


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

[Bug 1863601] Re: unable to type "|" character in french keyboard.

[Daniel Berrange]

Can you provide more information here. What command line have you
launched QEMU with ?  How are you interacting with QEMU (serial console,
GTK UI, VNC, SPICE ?)  If VNC/SPICE, what client app are you using ?

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

Title:
  unable to type "|" character in french keyboard.

Status in QEMU:
  New

Bug description:
  Unable to type "|" character when using french keyboard. It is
  displaying "<" instead of "|" while pressing AltGr+6 from my keyboard.

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

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

[David Gibson]

On Fri, Feb 21, 2020 at 03:09:46PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 18/02/2020 16:48, Philippe Mathieu-Daudé wrote:
> > On 2/17/20 11:46 PM, David Gibson wrote:
> >> On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote:
> >>> On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote:
>  Hi Alexey,
> 
>  On 2/17/20 3:12 AM, Alexey Kardashevskiy wrote:
> > The following changes since commit
> > 05943fb4ca41f626078014c0327781815c6584c5:
> >
> >     ppc: free 'fdt' after reset the machine (2020-02-17 11:27:23
> > +1100)
> >
> > are available in the Git repository at:
> >
> >     g...@github.com:aik/qemu.git tags/qemu-slof-20200217
> >
> > for you to fetch changes up to
> > ea9a03e5aa023c5391bab5259898475d0298aac2:
> >
> >     pseries: Update SLOF firmware image (2020-02-17 13:08:59 +1100)
> >
> > 
> > Alexey Kardashevskiy (1):
> >     pseries: Update SLOF firmware image
> >
> >    pc-bios/README   |   2 +-
> >    pc-bios/slof.bin | Bin 931032 -> 968560 bytes
> >    roms/SLOF    |   2 +-
> >    3 files changed, 2 insertions(+), 2 deletions(-)
> 
>  I only received the cover, not the patch, have you posted it?
> >>>
> >>> OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam
> >>> filter. FYI you can use 'git-format-patch --no-binary' to emit the patch
> >>> with the commit description but without the content.
> >>
> >> Generally Alexey sends SLOF updates to me just as pull requests
> >> without patches in full, because a huge slab of base64 encoded
> >> firmware isn't particularly illuminating.
> > 
> > I understand, this is why I later suggested Alexey to use
> > 'git-format-patch --no-binary', because Laszlo uses it for EDK2
> > submodule, this allow to quickly review the change on the list (without
> > posting the base64), see:
> > 
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624429.html
> > (pull-request cover)
> > 
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624432.html
> > "roms/edk2: update submodule"
> > 
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624435.html
> > "pc-bios: refresh edk2 build artifacts"
> 
> I am not quite sure where to fit this "git-format-patch". I run now "git
> request-pull" and "git send-email" so am I expected to run format-patch
> and post it as a patchset but with the pull request mail as a cover
> letter? This does not seem very useful though. For today, I'll add the
> change log to the pull request mail. Thanks,

Most git format-patch options can also be passed to git send-email,
and it will pass them through.

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


signature.asc
Description: PGP signature

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

[Howard Spoelstra]

On Fri, Feb 21, 2020 at 12:30 PM Programmingkid 
wrote:

>
> > On Feb 21, 2020, at 4:13 AM, Howard Spoelstra 
> wrote:
> >
> > Hi,
> >
> > It might be worth mentioning that any testing of your screamer
> implementation with MacOS/OSX guests on the mac99 machine needs a
> custom-built openbios.
> >
> > Where possible I'll compare your screamer with the current screamer
> implementation built from:
> > git clone -b screamer https://github.com/mcayland/qemu
> >
> > All tests on OSX Sierra host with system sounds and MP3 playback through
> latest QuickTime and iTunes available for the guest. Host is Intel i7-4770K
> at 3.50Ghz. 32Gb memory. Audio device is an USB headset.
> > Overall very subjective impression is that sound problems seem to arise
> quicker with strong changes in volume in the stream. Silence is produced
> perfectly...
> > I should note that I also tested earlier with a windows build and that I
> had to re-install Mac OS on three occasions to get sound going with your
> screamer. Whether that was caused by a faulty installation or your screamer
> is unclear to me.
> >
> > There we go:
> >
> > Mac OS 9.0.4: mac99,via=cuda
> > Apple audio extension often fails to load. (Not restricted to your
> screamer. This is a longstanding issue.) See at bottom for OSX crash report.
> > Your screamer: shows only CD in Sound CP Input panel. Play sound through
> output device is selected.
> > Current screamer: shows CD + External Mic. Play sound through output
> device is selected.
> >
> > Mac OS 9.1: mac99,via=cuda
> > Your screamer: No Input selection in the Sound CP.
> > Current screamer: Has External Mic (but no CD) in Sound CP. Play sound
> through output device is not selected.
> >
> > Mac OS 9.2: mac99,via=pmu
> > Your screamer: mp3 through iTunes and QuickTime OK. System sounds OK.
> > Current screamer: Has considerably more problems playing two streams
> simultaneously. (mp3 through both QuickTime and iTunes.)
> >
> > Mac OS X 10.0: mac99,via=cuda
> > Your screamer: setting the sound balance from middle position to the
> left seems to control volume.
> > Current screamer: Serious number of drop-outs when playing MP3 through
> QuickTime. Not when using iTunes. Has issues when moving the sound balance.
> >
> > Mac OS X 10.1: mac99,via=cuda
> > Off-topic: Interestingly, when booting with via=pmu, the same error
> occurs as reported above.
> > Your screamer: QuickTime: drop-outs. iTunes OK, even with playing system
> sounds through the stream. Balance has same problem as above.
> > Current screamer: Serious drop-outs through both QuickTime and iTunes
> when playing MP3. Balance sync gets completely lost after moving slider.
> More lag in response to clicking system sounds.
> >
> > Mac OSX 10.2: no test due to longstanding video issue with opening
> folders.
> >
> > Mac OSX 10.3: mac99,via=pmu
> > Your screamer: drop-outs with QuickTime and iTunes. But not the clicks
> heard as mentioned below. Opening the Sound preferences when playing MP3 is
> OK. System sounds playing through the stream produce crackling sound.
> systems sounds stop playing after several clicks on different ones. I hear
> parts of earlier clicked sound when new one clicked.
> > Current screamer: intermittent clicks (0.5 seconds) when playing MP3
> with QuickTime and iTunes. But QuickTime much better compared to 10.1.
> Currently playing mp3 gets completely distorted (doubled?) when opening
> Sound preferences.
> >
> > Mac OSX 10.4: mac99,via=pmu
> > Off-topic: From 10.4 onward, Internet radio works in iTunes. Channel
> update is very slow in 10.4...
> > Your screamer: drop-outs with QuickTime. Sounds comparable to current
> screamer. Opening Sound preferences is OK, but can make stream spiral out
> of control with an echo. Seems to happen quicker when playing sound with
> strong stereo effects. But always quickly recovers, unlike current
> screamer. iTunes also produces drop-outs. Also with internet stream, but is
> almost listenable.
> > Current screamer: drop-outs with QuickTime. Sounds like stream is not
> always in correct order. Sound crackles. iTunes almost OK. I can hear one
> or two clicks after stopping audio. Opening Sound preferences makes stream
> spiral out of control with an echo.
> >
> > Mac OSX 10.5: mac99,via=pmu
> > Your screamer: Drop-outs with QuickTime. A bit less-so with iTunes.
> Opening Sound preferences provides same experience as with 10.4. Internet
> stream almost listenable.
> > Current screamer: QuickTime produces drop-outs. Sound control panel
> spirals out of control. Small audio parts still played when stopping
> QuickTime. iTunes almost OK with MP3 playback, only small drop-outs. Same
> with Internet radio.
> >
> > For good measure I also tested 10.5 with your screamer and the recent
> hardfloat patches which improve fpu performance from 9% to 11% of a real G4
> 1Ghz ;-)
> > I did not experience a considerable improvement in sound quality.
> >
> > Best,
> > Howard
> >
> > OSX host Crash report when audio 

Re: [PATCH v1 00/13] migrate/ram: Fix resizing RAM blocks while migrating

[David Hildenbrand]

On 19.02.20 17:17, David Hildenbrand wrote:
> This is the follow up of
> "[PATCH RFC] memory: Don't allow to resize RAM while migrating" [1]
> 
> This series contains some (slightly modified) patches also contained in:
> "[PATCH v2 fixed 00/16] Ram blocks with resizable anonymous allocations
>  under POSIX" [2]
> That series will be based on this series. The last patch (#13) in this
> series could be moved to the other series, but I decided to include it in
> here for now (similar context).
> 
> I realized that resizing RAM blocks while the guest is being migrated
> (precopy: resize while still running on the source, postcopy: resize
>  while already running on the target) is buggy. In case of precopy, we
> can simply cancel migration. Postcopy handling is more involved. Resizing
> can currently happen during a guest reboot, triggered by ACPI rebuilds.
> 
> Along with the fixes, some cleanups.
> 
> [1] https://lkml.kernel.org/r/20200213172016.196609-1-da...@redhat.com
> [2] https://lkml.kernel.org/r/20200212134254.11073-1-da...@redhat.com
> 

I'm working on some reworks/cleanups and some testing (with virtio-mem
because there it's easy to trigger resizes). So whoever wants to have a
look, better to wait for the updated series :)

-- 
Thanks,

David / dhildenb

Re: [PATCH] tcg: gdbstub: Fix single-step issue on arm target

[Philippe Mathieu-Daudé]

On 2/21/20 12:51 PM, Changbin Du wrote:

On Thu, Feb 20, 2020 at 10:24:37PM +0100, Luc Michel wrote:

I'm curious, I never experienced this behaviour from GDB. What GDB and
QEMU versions are you using?

On my side (GDB 9.1), even without 'vContSupported+' in the 'qSupported'
answer, GDB sends a 'vCont?' packet on the first stepi:

0x in ?? ()
(gdb) si
Sending packet: $m0,4#fd...Ack
Packet received: 
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;s:p1.1;c:p1.-1#f7...Ack
Packet received: T05thread:p01.01;

Your second issue (wrong PC value) should be investigated though. Does
it happen on QEMU vanilla? Do you have a way to reproduce this bug?


Just confirmed this issue. This is an endianness problem for gdb. I was
debugging an big-endian elf and my host cpu is little-endian. QEMU gdbstub
always uses host cpu endian but gdb client treats it as big-endian by
inspecting elf info.


I'm using Debian gdb-multiarch, and indeed use cross-endianess (I always 
set arch/endian explicitly). This might be why I hit this too.




I can mannually set it to little-endian but it is painful. The gdb complains
abount invalid opcode error in debuginfo.

I also noticed that someoneelse has already tried to resolve this issue.
https://patchwork.kernel.org/patch/9528947/


Anyway after re-reading the GDB remote protocol documentation, I think
your patch is right, the feature should be advertised.

However I think your commit message needs some modifications. This fix
is not specific to ARM or TCG, but to the gdbstub itself. You also
mention this bug you have with PC, which is not related to the bug you
are fixing here. Could you rewrite it in a more generic way? You simply
need to emphasis the effect of advertising the 'vContSupported+' feature
on GDB.

Thanks.

--
Luc

Re: Race condition in overlayed qcow2?

[dovgaluk]

Vladimir Sementsov-Ogievskiy писал 2020-02-21 13:09:

21.02.2020 12:49, dovgaluk wrote:

Vladimir Sementsov-Ogievskiy писал 2020-02-20 12:36:

1 or 2 are ok, and 4 or 8 lead to the failures.


That is strange. I could think, that it was caused by the bugs in
deterministic CPU execution, but the first difference in logs
occur in READ operation (I dump read/write buffers in 
blk_aio_complete).




Aha, yes, looks strange.

Then next steps:

1. Does problem hit into the same offset every time?
2. Do we write to this region before this strange read?

2.1. If yes, we need to check that we read what we write.. You say 
you dump buffers
in blk_aio_complete... I think it would be more reliable to dump at 
start of
bdrv_co_pwritev and at end of bdrv_co_preadv. Also, guest may modify 
its buffers

during operation which would be strange but possible.

2.2 If not, hmm...




Another idea to check: use blkverify


I added logging of file descriptor and discovered that different 
results are obtained

when reading from the backing file.
And even more - replay runs of the same recording produce different 
results.
Logs show that there is a preadv race, but I can't figure out the 
source of the failure.


Log1:
preadv c 30467e00
preadv c 3096
--- sum = a2e1e
bdrv_co_preadv_part complete offset: 30467e00 qiov_offset: 0 len: 8200
--- sum = 10cdee
bdrv_co_preadv_part complete offset: 3096 qiov_offset: 8200 len: 
ee00


Log2:
preadv c 30467e00
--- sum = a2e1e
bdrv_co_preadv_part complete offset: 30467e00 qiov_offset: 0 len: 8200
preadv c 3096
--- sum = f094f
bdrv_co_preadv_part complete offset: 3096 qiov_offset: 8200 len: 
ee00



Checksum calculation was added to preadv in file-posix.c



So, preadv in file-posix.c returns different results for the same
offset, for file which is always opened in RO mode? Sounds impossible
:)


True.
Maybe my logging is wrong?

static ssize_t
qemu_preadv(int fd, const struct iovec *iov, int nr_iov, off_t offset)
{
ssize_t res = preadv(fd, iov, nr_iov, offset);
qemu_log("preadv %x %"PRIx64"\n", fd, (uint64_t)offset);
int i;
uint32_t sum = 0;
int cnt = 0;
for (i = 0 ; i < nr_iov ; ++i) {
int j;
for (j = 0 ; j < (int)iov[i].iov_len ; ++j)
{
sum += ((uint8_t*)iov[i].iov_base)[j];
++cnt;
}
}
qemu_log("size: %x sum: %x\n", cnt, sum);
assert(cnt == res);
return res;
}

This code prints preadv checksum.
But when I calculate the same with the standalone program, then it gives 
me another values of the checksums for the same offsets:


#include 
#include 
#include 
#include 
#include 
#include 

unsigned char buf[0x10];

int main(int argc, char **argv)
{
  if (argc < 4) return 1;
  int f = open(argv[1], O_RDONLY);
  unsigned int cnt;
  unsigned int offs;
  sscanf(argv[2], "%x", &offs);
  sscanf(argv[3], "%x", &cnt);
  printf("file: %s offset: %x size: %x\n", argv[1], offs, cnt);
  struct iovec iov = {buf, (size_t)cnt};
  size_t sz = preadv(f, &iov, 1, offs);
  printf("read %x\n", (int)sz);
  int i;
  unsigned int sum = 0;
  for (i = 0 ; i < cnt ; ++i)
sum += buf[i];
  printf("sum = %x\n", sum);
}



Pavel Dovgalyuk

Re: [PATCH v2] gdbstub: Fix single-step issue by confirming 'vContSupported+' feature to gdb

[Luc Michel]

On 2/21/20 1:25 AM, Changbin Du wrote:
> Recently when debugging an arm32 system on qemu, I found sometimes the
> single-step command (stepi) is not working. This can be reproduced by
> below steps:
>  1) start qemu-system-arm -s -S .. and wait for gdb connection.
>  2) start gdb and connect to qemu. In my case, gdb gets a wrong value
> (0x60) for PC, which is an another bug.
>  3) After connected, type 'stepi' and expect it will stop at next ins.
> 
> But, it has never stopped. This because:
>  1) We doesn't report ‘vContSupported’ feature to gdb explicitly and gdb
> think we do not support it. In this case, gdb use a software breakpoint
> to emulate single-step.
>  2) Since gdb gets a wrong initial value of PC, then gdb inserts a
> breakpoint to wrong place (PC+4).
> 
> Not only for the arm target, Philippe has also encountered this on MIPS.
> Probably gdb has different assumption for different architectures.
> 
> Since we do support ‘vContSupported’ query command, so let's tell gdb that
> we support it.
> 
> Before this change, gdb send below 'Z0' packet to implement single-step:
> gdb_handle_packet: Z0,4,4
> 
> After this change, gdb send "vCont;s.." which is expected:
> gdb_handle_packet: vCont?
> put_packet: vCont;c;C;s;S
> gdb_handle_packet: vCont;s:p1.1;c:p1.-1
> 
> Signed-off-by: Changbin Du 
> Tested-by: Philippe Mathieu-Daudé 

Reviewed-by: Luc Michel 

> 
> ---
> v2: polish commit message.
> ---
>  gdbstub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index ce304ff482..adccd938e2 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -2111,7 +2111,7 @@ static void handle_query_supported(GdbCmdContext 
> *gdb_ctx, void *user_ctx)
>  gdb_ctx->s->multiprocess = true;
>  }
>  
> -pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), ";multiprocess+");
> +pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), 
> ";vContSupported+;multiprocess+");
>  put_packet(gdb_ctx->s, gdb_ctx->str_buf);
>  }
>  
> 

Re: [PATCH] hw/char/pl011: Output characters using best-effort mode

[Peter Maydell]

On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini  wrote:
>
> On 21/02/20 11:21, Peter Maydell wrote:
> > Before you do that, I would suggest investigating:
> >  * is this a problem we've already had on x86 and that there is a
> >standard solution for
> Disconnected sockets always lose data (see tcp_chr_write in
> chardev/char-socket.c).
>
> For connected sockets, 8250 does at most 4 retries (each retry is
> triggered by POLLOUT|POLLHUP).  After these four retries the output
> chardev is considered broken, just like in Gavin's patch, and only a
> reset will restart the output.
>
> >  * should this be applicable to more than just the socket chardev?
> >What's special about the socket chardev?
>
> For 8250 there's no difference between socket and everything else.

Interesting, I didn't know our 8250 emulation had this
retry-and-drop-data logic. Is it feasible to put it into
the chardev layer instead, so that every serial device
can get it without having to manually implement it?

thanks
-- PMM

[Bug 1863601] Re: unable to type "|" character in french keyboard.

[Aditya prakash]

Hi Daniel, Thanks for your response. I am using virt-manager to start
with to connect with VNC.

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

Title:
  unable to type "|" character in french keyboard.

Status in QEMU:
  New

Bug description:
  Unable to type "|" character when using french keyboard. It is
  displaying "<" instead of "|" while pressing AltGr+6 from my keyboard.

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

Re: [PATCH 5/5] aio-posix: make AioHandler dispatch O(1) with epoll

[Stefan Hajnoczi]

On Wed, Feb 19, 2020 at 12:13:40PM +0100, Paolo Bonzini wrote:
> On 14/02/20 18:17, Stefan Hajnoczi wrote:
> > +while ((node = QLIST_FIRST(ready_list))) {
> > +QLIST_SAFE_REMOVE(node, node_ready);
> 
> Why does this need safe remove?

Yes, it's necessary.  QLIST_SAFE_REMOVE() has two properties that make
it "safe":
1. It doesn't crash if the node is currently not on a list.
2. It clears the node's linked list pointers so that future linked
   list operations (like QLIST_SAFE_REMOVE()) aren't accidentally
   performed on stale pointers.

The node has a long lifespan and will be inserted into ready_lists
multiple times.  We need to safely remove it from ready_list to protect
against a corruption the next time the node is inserted into a
ready_list again:

  /* Add a handler to a ready list */
  static void add_ready_handler(AioHandlerList *ready_list,
AioHandler *node,
int revents)
  {
  QLIST_SAFE_REMOVE(node, node_ready); /* remove from nested parent's list 
*/
  ^ would cause corruption if node->node_ready was stale!

Would you like me to add a comment?

Stefan


signature.asc
Description: PGP signature

[Bug 1863601] Re: unable to type "|" character in french keyboard.

[Daniel Berrange]

Can you provide the QEMU command line (/var/log/libvirt/qemu/$GUEST.log)

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

Title:
  unable to type "|" character in french keyboard.

Status in QEMU:
  New

Bug description:
  Unable to type "|" character when using french keyboard. It is
  displaying "<" instead of "|" while pressing AltGr+6 from my keyboard.

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

Re: [PATCH 5/5] aio-posix: make AioHandler dispatch O(1) with epoll

[Paolo Bonzini]

On 21/02/20 13:59, Stefan Hajnoczi wrote:
> 1. It doesn't crash if the node is currently not on a list.
> 2. It clears the node's linked list pointers so that future linked
>list operations (like QLIST_SAFE_REMOVE()) aren't accidentally
>performed on stale pointers.
>
> The node has a long lifespan and will be inserted into ready_lists
> multiple times.  We need to safely remove it from ready_list to protect
> against a corruption the next time the node is inserted into a
> ready_list again:

Ah, so the one I singled out is for (2) (we know the node is currently
on a list), while the one below is for (1).  Would it make sense to move
(2) to Q*_REMOVE_*?  We can do it separately after this pull request.

>   /* Add a handler to a ready list */
>   static void add_ready_handler(AioHandlerList *ready_list,
> AioHandler *node,
> int revents)
>   {
>   QLIST_SAFE_REMOVE(node, node_ready); /* remove from nested parent's 
> list */
>   ^ would cause corruption if node->node_ready was stale!
> 
> Would you like me to add a comment?
No, it's okay.

Paolo

[PULL 00/52] target-arm queue

[Peter Maydell]

Big pullreq this week, though none of the new features are
particularly earthshaking. Most of the bulk is from code cleanup
patches from me or rth.

thanks
-- PMM

The following changes since commit b651b80822fa8cb66ca30087ac7fbc75507ae5d2:

  Merge remote-tracking branch 
'remotes/vivier2/tags/linux-user-for-5.0-pull-request' into staging (2020-02-20 
17:35:42 +)

are available in the Git repository at:

  https://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20200221

for you to fetch changes up to 270a679b3f950d7c4c600f324aab8bff292d0971:

  target/arm: Add missing checks for fpsp_v2 (2020-02-21 12:54:25 +)


target-arm queue:
 * aspeed/scu: Implement chip ID register
 * hw/misc/iotkit-secctl: Fix writing to 'PPC Interrupt Clear' register
 * mainstone: Make providing flash images non-mandatory
 * z2: Make providing flash images non-mandatory
 * Fix failures to flush SVE high bits after AdvSIMD INS/ZIP/UZP/TRN/TBL/TBX/EXT
 * Minor performance improvement: spend less time recalculating hflags values
 * Code cleanup to isar_feature function tests
 * Implement ARMv8.1-PMU and ARMv8.4-PMU extensions
 * Bugfix: correct handling of PMCR_EL0.LC bit
 * Bugfix: correct definition of PMCRDP
 * Correctly implement ACTLR2, HACTLR2
 * allwinner: Wire up USB ports
 * Vectorize emulation of USHL, SSHL, PMUL*
 * xilinx_spips: Correct the number of dummy cycles for the FAST_READ_4 cmd
 * sh4: Fix PCI ISA IO memory subregion
 * Code cleanup to use more isar_feature tests and fewer ARM_FEATURE_* tests


Francisco Iglesias (1):
  xilinx_spips: Correct the number of dummy cycles for the FAST_READ_4 cmd

Guenter Roeck (6):
  mainstone: Make providing flash images non-mandatory
  z2: Make providing flash images non-mandatory
  hw: usb: hcd-ohci: Move OHCISysBusState and TYPE_SYSBUS_OHCI to include 
file
  hcd-ehci: Introduce "companion-enable" sysbus property
  arm: allwinner: Wire up USB ports
  sh4: Fix PCI ISA IO memory subregion

Joel Stanley (2):
  aspeed/scu: Create separate write callbacks
  aspeed/scu: Implement chip ID register

Peter Maydell (21):
  target/arm: Add _aa32_ to isar_feature functions testing 32-bit ID 
registers
  target/arm: Check aa32_pan in take_aarch32_exception(), not aa64_pan
  target/arm: Add isar_feature_any_fp16 and document naming/usage 
conventions
  target/arm: Define and use any_predinv isar_feature test
  target/arm: Factor out PMU register definitions
  target/arm: Add and use FIELD definitions for ID_AA64DFR0_EL1
  target/arm: Use FIELD macros for clearing ID_DFR0 PERFMON field
  target/arm: Define an aa32_pmu_8_1 isar feature test function
  target/arm: Add _aa64_ and _any_ versions of pmu_8_1 isar checks
  target/arm: Stop assuming DBGDIDR always exists
  target/arm: Move DBGDIDR into ARMISARegisters
  target/arm: Read debug-related ID registers from KVM
  target/arm: Implement ARMv8.1-PMU extension
  target/arm: Implement ARMv8.4-PMU extension
  target/arm: Provide ARMv8.4-PMU in '-cpu max'
  target/arm: Correct definition of PMCRDP
  target/arm: Correct handling of PMCR_EL0.LC bit
  target/arm: Test correct register in aa32_pan and aa32_ats1e1 checks
  target/arm: Use isar_feature function for testing AA32HPD feature
  target/arm: Use FIELD_EX32 for testing 32-bit fields
  target/arm: Correctly implement ACTLR2, HACTLR2

Philippe Mathieu-Daudé (1):
  hw/misc/iotkit-secctl: Fix writing to 'PPC Interrupt Clear' register

Richard Henderson (21):
  target/arm: Flush high bits of sve register after AdvSIMD EXT
  target/arm: Flush high bits of sve register after AdvSIMD TBL/TBX
  target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRN
  target/arm: Flush high bits of sve register after AdvSIMD INS
  target/arm: Use bit 55 explicitly for pauth
  target/arm: Fix select for aa64_va_parameters_both
  target/arm: Remove ttbr1_valid check from get_phys_addr_lpae
  target/arm: Split out aa64_va_parameter_tbi, aa64_va_parameter_tbid
  target/arm: Vectorize USHL and SSHL
  target/arm: Convert PMUL.8 to gvec
  target/arm: Convert PMULL.64 to gvec
  target/arm: Convert PMULL.8 to gvec
  target/arm: Rename isar_feature_aa32_simd_r32
  target/arm: Use isar_feature_aa32_simd_r32 more places
  target/arm: Set MVFR0.FPSP for ARMv5 cpus
  target/arm: Add isar_feature_aa32_simd_r16
  target/arm: Rename isar_feature_aa32_fpdp_v2
  target/arm: Add isar_feature_aa32_{fpsp_v2, fpsp_v3, fpdp_v3}
  target/arm: Perform fpdp_v2 check first
  target/arm: Replace ARM_FEATURE_VFP3 checks with fp{sp, dp}_v3
  target/arm: Add missing checks for fpsp_v2

 hw/usb/hcd-ohci.h  |  16 ++
 

[PULL 01/52] aspeed/scu: Create separate write callbacks

[Peter Maydell]

From: Joel Stanley 

This splits the common write callback into separate ast2400 and ast2500
implementations. This makes it clearer when implementing differing
behaviour.

Signed-off-by: Joel Stanley 
Reviewed-by: Andrew Jeffery 
Reviewed-by: Cédric Le Goater 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200121013302.43839-2-j...@jms.id.au
Signed-off-by: Peter Maydell 
---
 hw/misc/aspeed_scu.c | 80 +++-
 1 file changed, 57 insertions(+), 23 deletions(-)

diff --git a/hw/misc/aspeed_scu.c b/hw/misc/aspeed_scu.c
index ce2f9562d4c..6cb388330a8 100644
--- a/hw/misc/aspeed_scu.c
+++ b/hw/misc/aspeed_scu.c
@@ -232,8 +232,47 @@ static uint64_t aspeed_scu_read(void *opaque, hwaddr 
offset, unsigned size)
 return s->regs[reg];
 }
 
-static void aspeed_scu_write(void *opaque, hwaddr offset, uint64_t data,
- unsigned size)
+static void aspeed_ast2400_scu_write(void *opaque, hwaddr offset,
+ uint64_t data, unsigned size)
+{
+AspeedSCUState *s = ASPEED_SCU(opaque);
+int reg = TO_REG(offset);
+
+if (reg >= ASPEED_SCU_NR_REGS) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds write at offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+return;
+}
+
+if (reg > PROT_KEY && reg < CPU2_BASE_SEG1 &&
+!s->regs[PROT_KEY]) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: SCU is locked!\n", __func__);
+}
+
+trace_aspeed_scu_write(offset, size, data);
+
+switch (reg) {
+case PROT_KEY:
+s->regs[reg] = (data == ASPEED_SCU_PROT_KEY) ? 1 : 0;
+return;
+case SILICON_REV:
+case FREQ_CNTR_EVAL:
+case VGA_SCRATCH1 ... VGA_SCRATCH8:
+case RNG_DATA:
+case FREE_CNTR4:
+case FREE_CNTR4_EXT:
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Write to read-only offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+return;
+}
+
+s->regs[reg] = data;
+}
+
+static void aspeed_ast2500_scu_write(void *opaque, hwaddr offset,
+ uint64_t data, unsigned size)
 {
 AspeedSCUState *s = ASPEED_SCU(opaque);
 int reg = TO_REG(offset);
@@ -257,25 +296,11 @@ static void aspeed_scu_write(void *opaque, hwaddr offset, 
uint64_t data,
 case PROT_KEY:
 s->regs[reg] = (data == ASPEED_SCU_PROT_KEY) ? 1 : 0;
 return;
-case CLK_SEL:
-s->regs[reg] = data;
-break;
 case HW_STRAP1:
-if (ASPEED_IS_AST2500(s->regs[SILICON_REV])) {
-s->regs[HW_STRAP1] |= data;
-return;
-}
-/* Jump to assignment below */
-break;
+s->regs[HW_STRAP1] |= data;
+return;
 case SILICON_REV:
-if (ASPEED_IS_AST2500(s->regs[SILICON_REV])) {
-s->regs[HW_STRAP1] &= ~data;
-} else {
-qemu_log_mask(LOG_GUEST_ERROR,
-  "%s: Write to read-only offset 0x%" HWADDR_PRIx "\n",
-  __func__, offset);
-}
-/* Avoid assignment below, we've handled everything */
+s->regs[HW_STRAP1] &= ~data;
 return;
 case FREQ_CNTR_EVAL:
 case VGA_SCRATCH1 ... VGA_SCRATCH8:
@@ -291,9 +316,18 @@ static void aspeed_scu_write(void *opaque, hwaddr offset, 
uint64_t data,
 s->regs[reg] = data;
 }
 
-static const MemoryRegionOps aspeed_scu_ops = {
+static const MemoryRegionOps aspeed_ast2400_scu_ops = {
 .read = aspeed_scu_read,
-.write = aspeed_scu_write,
+.write = aspeed_ast2400_scu_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.valid.min_access_size = 4,
+.valid.max_access_size = 4,
+.valid.unaligned = false,
+};
+
+static const MemoryRegionOps aspeed_ast2500_scu_ops = {
+.read = aspeed_scu_read,
+.write = aspeed_ast2500_scu_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 .valid.min_access_size = 4,
 .valid.max_access_size = 4,
@@ -469,7 +503,7 @@ static void aspeed_2400_scu_class_init(ObjectClass *klass, 
void *data)
 asc->calc_hpll = aspeed_2400_scu_calc_hpll;
 asc->apb_divider = 2;
 asc->nr_regs = ASPEED_SCU_NR_REGS;
-asc->ops = &aspeed_scu_ops;
+asc->ops = &aspeed_ast2400_scu_ops;
 }
 
 static const TypeInfo aspeed_2400_scu_info = {
@@ -489,7 +523,7 @@ static void aspeed_2500_scu_class_init(ObjectClass *klass, 
void *data)
 asc->calc_hpll = aspeed_2500_scu_calc_hpll;
 asc->apb_divider = 4;
 asc->nr_regs = ASPEED_SCU_NR_REGS;
-asc->ops = &aspeed_scu_ops;
+asc->ops = &aspeed_ast2500_scu_ops;
 }
 
 static const TypeInfo aspeed_2500_scu_info = {
-- 
2.20.1

[PULL 05/52] z2: Make providing flash images non-mandatory

[Peter Maydell]

From: Guenter Roeck 

Up to now, the z2 machine only boots if a flash image is provided.
This is not really necessary; the machine can boot from initrd or from
SD without it. At the same time, having to provide dummy flash images
is a nuisance and does not add any real value. Make it optional.

Signed-off-by: Guenter Roeck 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200217210903.18602-1-li...@roeck-us.net
Signed-off-by: Peter Maydell 
---
 hw/arm/z2.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/hw/arm/z2.c b/hw/arm/z2.c
index 34794fe3ae6..4bb237f22d2 100644
--- a/hw/arm/z2.c
+++ b/hw/arm/z2.c
@@ -314,12 +314,6 @@ static void z2_init(MachineState *machine)
 be = 0;
 #endif
 dinfo = drive_get(IF_PFLASH, 0, 0);
-if (!dinfo && !qtest_enabled()) {
-error_report("Flash image must be given with the "
- "'pflash' parameter");
-exit(1);
-}
-
 if (!pflash_cfi01_register(Z2_FLASH_BASE, "z2.flash0", Z2_FLASH_SIZE,
dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
sector_len, 4, 0, 0, 0, 0, be)) {
-- 
2.20.1

[PULL 03/52] hw/misc/iotkit-secctl: Fix writing to 'PPC Interrupt Clear' register

[Peter Maydell]

From: Philippe Mathieu-Daudé 

Fix warning reported by Clang static code analyzer:

CC  hw/misc/iotkit-secctl.o
  hw/misc/iotkit-secctl.c:343:9: warning: Value stored to 'value' is never read
  value &= 0x00f000f3;
  ^~~

Fixes: b3717c23e1c
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé 
Message-id: 20200217132922.24607-1-f4...@amsat.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/misc/iotkit-secctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/misc/iotkit-secctl.c b/hw/misc/iotkit-secctl.c
index 609869821a1..9fdb82056a8 100644
--- a/hw/misc/iotkit-secctl.c
+++ b/hw/misc/iotkit-secctl.c
@@ -340,7 +340,7 @@ static MemTxResult iotkit_secctl_s_write(void *opaque, 
hwaddr addr,
 qemu_set_irq(s->sec_resp_cfg, s->secrespcfg);
 break;
 case A_SECPPCINTCLR:
-value &= 0x00f000f3;
+s->secppcintstat &= ~(value & 0x00f000f3);
 foreach_ppc(s, iotkit_secctl_ppc_update_irq_clear);
 break;
 case A_SECPPCINTEN:
-- 
2.20.1

[PULL 06/52] target/arm: Flush high bits of sve register after AdvSIMD EXT

[Peter Maydell]

From: Richard Henderson 

Writes to AdvSIMD registers flush the bits above 128.

Buglink: https://bugs.launchpad.net/bugs/1863247
Signed-off-by: Richard Henderson 
Message-id: 20200214194643.23317-2-richard.hender...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target/arm/translate-a64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 7c26c3bfebb..620a4290671 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -6895,6 +6895,7 @@ static void disas_simd_ext(DisasContext *s, uint32_t insn)
 tcg_temp_free_i64(tcg_resl);
 write_vec_element(s, tcg_resh, rd, 1, MO_64);
 tcg_temp_free_i64(tcg_resh);
+clear_vec_high(s, true, rd);
 }
 
 /* TBL/TBX
-- 
2.20.1

[PULL 02/52] aspeed/scu: Implement chip ID register

[Peter Maydell]

From: Joel Stanley 

This returns a fixed but non-zero value for the chip id.

Signed-off-by: Joel Stanley 
Reviewed-by: Andrew Jeffery 
Reviewed-by: Cédric Le Goater 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200121013302.43839-3-j...@jms.id.au
Signed-off-by: Peter Maydell 
---
 hw/misc/aspeed_scu.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/hw/misc/aspeed_scu.c b/hw/misc/aspeed_scu.c
index 6cb388330a8..9d7482a9df1 100644
--- a/hw/misc/aspeed_scu.c
+++ b/hw/misc/aspeed_scu.c
@@ -77,6 +77,8 @@
 #define CPU2_BASE_SEG4   TO_REG(0x110)
 #define CPU2_BASE_SEG5   TO_REG(0x114)
 #define CPU2_CACHE_CTRL  TO_REG(0x118)
+#define CHIP_ID0 TO_REG(0x150)
+#define CHIP_ID1 TO_REG(0x154)
 #define UART_HPLL_CLKTO_REG(0x160)
 #define PCIE_CTRLTO_REG(0x180)
 #define BMC_MMIO_CTRLTO_REG(0x184)
@@ -115,6 +117,8 @@
 #define AST2600_HW_STRAP2_PROTTO_REG(0x518)
 #define AST2600_RNG_CTRL  TO_REG(0x524)
 #define AST2600_RNG_DATA  TO_REG(0x540)
+#define AST2600_CHIP_ID0  TO_REG(0x5B0)
+#define AST2600_CHIP_ID1  TO_REG(0x5B4)
 
 #define AST2600_CLK TO_REG(0x40)
 
@@ -182,6 +186,8 @@ static const uint32_t ast2500_a1_resets[ASPEED_SCU_NR_REGS] 
= {
  [CPU2_BASE_SEG1]  = 0x8000U,
  [CPU2_BASE_SEG4]  = 0x1E60U,
  [CPU2_BASE_SEG5]  = 0xC000U,
+ [CHIP_ID0]= 0x1234ABCDU,
+ [CHIP_ID1]= 0xU,
  [UART_HPLL_CLK]   = 0x1903U,
  [PCIE_CTRL]   = 0x007BU,
  [BMC_DEV_ID]  = 0x2402U
@@ -307,6 +313,8 @@ static void aspeed_ast2500_scu_write(void *opaque, hwaddr 
offset,
 case RNG_DATA:
 case FREE_CNTR4:
 case FREE_CNTR4_EXT:
+case CHIP_ID0:
+case CHIP_ID1:
 qemu_log_mask(LOG_GUEST_ERROR,
   "%s: Write to read-only offset 0x%" HWADDR_PRIx "\n",
   __func__, offset);
@@ -620,6 +628,8 @@ static void aspeed_ast2600_scu_write(void *opaque, hwaddr 
offset,
 case AST2600_RNG_DATA:
 case AST2600_SILICON_REV:
 case AST2600_SILICON_REV2:
+case AST2600_CHIP_ID0:
+case AST2600_CHIP_ID1:
 /* Add read only registers here */
 qemu_log_mask(LOG_GUEST_ERROR,
   "%s: Write to read-only offset 0x%" HWADDR_PRIx "\n",
@@ -648,6 +658,9 @@ static const uint32_t 
ast2600_a0_resets[ASPEED_AST2600_SCU_NR_REGS] = {
 [AST2600_CLK_STOP_CTRL2]= 0xFFF0FFF0,
 [AST2600_SDRAM_HANDSHAKE]   = 0x0040,  /* SoC completed DRAM init */
 [AST2600_HPLL_PARAM]= 0x1000405F,
+[AST2600_CHIP_ID0]  = 0x1234ABCD,
+[AST2600_CHIP_ID1]  = 0x,
+
 };
 
 static void aspeed_ast2600_scu_reset(DeviceState *dev)
-- 
2.20.1

[PULL 04/52] mainstone: Make providing flash images non-mandatory

[Peter Maydell]

From: Guenter Roeck 

Up to now, the mainstone machine only boots if two flash images are
provided. This is not really necessary; the machine can boot from initrd
or from SD without it. At the same time, having to provide dummy flash
images is a nuisance and does not add any real value. Make it optional.

Signed-off-by: Guenter Roeck 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200217210824.18513-1-li...@roeck-us.net
Signed-off-by: Peter Maydell 
---
 hw/arm/mainstone.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/hw/arm/mainstone.c b/hw/arm/mainstone.c
index b01ce3ce08c..6e64dfab506 100644
--- a/hw/arm/mainstone.c
+++ b/hw/arm/mainstone.c
@@ -138,19 +138,10 @@ static void mainstone_common_init(MemoryRegion 
*address_space_mem,
 /* There are two 32MiB flash devices on the board */
 for (i = 0; i < 2; i ++) {
 dinfo = drive_get(IF_PFLASH, 0, i);
-if (!dinfo) {
-if (qtest_enabled()) {
-break;
-}
-error_report("Two flash images must be given with the "
- "'pflash' parameter");
-exit(1);
-}
-
 if (!pflash_cfi01_register(mainstone_flash_base[i],
i ? "mainstone.flash1" : "mainstone.flash0",
MAINSTONE_FLASH,
-   blk_by_legacy_dinfo(dinfo),
+   dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
sector_len, 4, 0, 0, 0, 0, be)) {
 error_report("Error registering flash memory");
 exit(1);
-- 
2.20.1

[PULL 08/52] target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRN

[Peter Maydell]

From: Richard Henderson 

Writes to AdvSIMD registers flush the bits above 128.

Signed-off-by: Richard Henderson 
Message-id: 20200214194643.23317-4-richard.hender...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target/arm/translate-a64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 096a854aed7..b83d09dbcd7 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -7054,6 +7054,7 @@ static void disas_simd_zip_trn(DisasContext *s, uint32_t 
insn)
 tcg_temp_free_i64(tcg_resl);
 write_vec_element(s, tcg_resh, rd, 1, MO_64);
 tcg_temp_free_i64(tcg_resh);
+clear_vec_high(s, true, rd);
 }
 
 /*
-- 
2.20.1

[PULL 07/52] target/arm: Flush high bits of sve register after AdvSIMD TBL/TBX

[Peter Maydell]

From: Richard Henderson 

Writes to AdvSIMD registers flush the bits above 128.

Signed-off-by: Richard Henderson 
Message-id: 20200214194643.23317-3-richard.hender...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target/arm/translate-a64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 620a4290671..096a854aed7 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -6964,6 +6964,7 @@ static void disas_simd_tb(DisasContext *s, uint32_t insn)
 tcg_temp_free_i64(tcg_resl);
 write_vec_element(s, tcg_resh, rd, 1, MO_64);
 tcg_temp_free_i64(tcg_resh);
+clear_vec_high(s, true, rd);
 }
 
 /* ZIP/UZP/TRN
-- 
2.20.1

[PULL 10/52] target/arm: Use bit 55 explicitly for pauth

[Peter Maydell]

From: Richard Henderson 

The psuedocode in aarch64/functions/pac/auth/Auth and
aarch64/functions/pac/strip/Strip always uses bit 55 for
extfield and do not consider if the current regime has 2 ranges.

Suggested-by: Peter Maydell 
Signed-off-by: Richard Henderson 
Reviewed-by: Peter Maydell 
Message-id: 20200216194343.21331-2-richard.hender...@linaro.org
Signed-off-by: Peter Maydell 
---
 target/arm/pauth_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/arm/pauth_helper.c b/target/arm/pauth_helper.c
index 9746e32bf81..b909630317e 100644
--- a/target/arm/pauth_helper.c
+++ b/target/arm/pauth_helper.c
@@ -320,7 +320,8 @@ static uint64_t pauth_addpac(CPUARMState *env, uint64_t 
ptr, uint64_t modifier,
 
 static uint64_t pauth_original_ptr(uint64_t ptr, ARMVAParameters param)
 {
-uint64_t extfield = -param.select;
+/* Note that bit 55 is used whether or not the regime has 2 ranges. */
+uint64_t extfield = sextract64(ptr, 55, 1);
 int bot_pac_bit = 64 - param.tsz;
 int top_pac_bit = 64 - 8 * param.tbi;
 
-- 
2.20.1

[PULL 09/52] target/arm: Flush high bits of sve register after AdvSIMD INS

[Peter Maydell]

From: Richard Henderson 

Writes to AdvSIMD registers flush the bits above 128.

Signed-off-by: Richard Henderson 
Message-id: 20200214194643.23317-5-richard.hender...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target/arm/translate-a64.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index b83d09dbcd7..bd68588a710 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -7412,6 +7412,9 @@ static void handle_simd_inse(DisasContext *s, int rd, int 
rn,
 write_vec_element(s, tmp, rd, dst_index, size);
 
 tcg_temp_free_i64(tmp);
+
+/* INS is considered a 128-bit write for SVE. */
+clear_vec_high(s, true, rd);
 }
 
 
@@ -7441,6 +7444,9 @@ static void handle_simd_insg(DisasContext *s, int rd, int 
rn, int imm5)
 
 idx = extract32(imm5, 1 + size, 4 - size);
 write_vec_element(s, cpu_reg(s, rn), rd, idx, size);
+
+/* INS is considered a 128-bit write for SVE. */
+clear_vec_high(s, true, rd);
 }
 
 /*
-- 
2.20.1

[PULL 15/52] target/arm: Check aa32_pan in take_aarch32_exception(), not aa64_pan

[Peter Maydell]

In take_aarch32_exception(), we know we are dealing with a CPU that
has AArch32, so the right isar_feature test is aa32_pan, not aa64_pan.

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20200214175116.9164-3-peter.mayd...@linaro.org
---
 target/arm/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 9c02d5d6b8e..ad2bfa9ef83 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -8858,7 +8858,7 @@ static void take_aarch32_exception(CPUARMState *env, int 
new_mode,
 env->elr_el[2] = env->regs[15];
 } else {
 /* CPSR.PAN is normally preserved preserved unless...  */
-if (cpu_isar_feature(aa64_pan, env_archcpu(env))) {
+if (cpu_isar_feature(aa32_pan, env_archcpu(env))) {
 switch (new_el) {
 case 3:
 if (!arm_is_secure_below_el3(env)) {
-- 
2.20.1

[PULL 13/52] target/arm: Split out aa64_va_parameter_tbi, aa64_va_parameter_tbid

[Peter Maydell]

From: Richard Henderson 

For the purpose of rebuild_hflags_a64, we do not need to compute
all of the va parameters, only tbi.  Moreover, we can compute them
in a form that is more useful to storing in hflags.

This eliminates the need for aa64_va_parameter_both, so fold that
in to aa64_va_parameter.  The remaining calls to aa64_va_parameter
are in get_phys_addr_lpae and in pauth_helper.c.

This reduces the total cpu consumption of aa64_va_parameter in a
kernel boot plus a kvm guest kernel boot from 3% to 0.5%.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
Message-id: 20200216194343.21331-5-richard.hender...@linaro.org
Signed-off-by: Peter Maydell 
---
 target/arm/internals.h |  3 --
 target/arm/helper.c| 68 +++---
 2 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/target/arm/internals.h b/target/arm/internals.h
index 58c4d707c5d..14328e3f7da 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1127,15 +1127,12 @@ typedef struct ARMVAParameters {
 unsigned tsz: 8;
 unsigned select : 1;
 bool tbi: 1;
-bool tbid   : 1;
 bool epd: 1;
 bool hpd: 1;
 bool using16k   : 1;
 bool using64k   : 1;
 } ARMVAParameters;
 
-ARMVAParameters aa64_va_parameters_both(CPUARMState *env, uint64_t va,
-ARMMMUIdx mmu_idx);
 ARMVAParameters aa64_va_parameters(CPUARMState *env, uint64_t va,
ARMMMUIdx mmu_idx, bool data);
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index eec7b01ab35..8d0f6eca27b 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10234,12 +10234,34 @@ static uint8_t convert_stage2_attrs(CPUARMState *env, 
uint8_t s2attrs)
 }
 #endif /* !CONFIG_USER_ONLY */
 
-ARMVAParameters aa64_va_parameters_both(CPUARMState *env, uint64_t va,
-ARMMMUIdx mmu_idx)
+static int aa64_va_parameter_tbi(uint64_t tcr, ARMMMUIdx mmu_idx)
+{
+if (regime_has_2_ranges(mmu_idx)) {
+return extract64(tcr, 37, 2);
+} else if (mmu_idx == ARMMMUIdx_Stage2) {
+return 0; /* VTCR_EL2 */
+} else {
+return extract32(tcr, 20, 1);
+}
+}
+
+static int aa64_va_parameter_tbid(uint64_t tcr, ARMMMUIdx mmu_idx)
+{
+if (regime_has_2_ranges(mmu_idx)) {
+return extract64(tcr, 51, 2);
+} else if (mmu_idx == ARMMMUIdx_Stage2) {
+return 0; /* VTCR_EL2 */
+} else {
+return extract32(tcr, 29, 1);
+}
+}
+
+ARMVAParameters aa64_va_parameters(CPUARMState *env, uint64_t va,
+   ARMMMUIdx mmu_idx, bool data)
 {
 uint64_t tcr = regime_tcr(env, mmu_idx)->raw_tcr;
-bool tbi, tbid, epd, hpd, using16k, using64k;
-int select, tsz;
+bool epd, hpd, using16k, using64k;
+int select, tsz, tbi;
 
 if (!regime_has_2_ranges(mmu_idx)) {
 select = 0;
@@ -10248,11 +10270,9 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState 
*env, uint64_t va,
 using16k = extract32(tcr, 15, 1);
 if (mmu_idx == ARMMMUIdx_Stage2) {
 /* VTCR_EL2 */
-tbi = tbid = hpd = false;
+hpd = false;
 } else {
-tbi = extract32(tcr, 20, 1);
 hpd = extract32(tcr, 24, 1);
-tbid = extract32(tcr, 29, 1);
 }
 epd = false;
 } else {
@@ -10266,28 +10286,30 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState 
*env, uint64_t va,
 epd = extract32(tcr, 7, 1);
 using64k = extract32(tcr, 14, 1);
 using16k = extract32(tcr, 15, 1);
-tbi = extract64(tcr, 37, 1);
 hpd = extract64(tcr, 41, 1);
-tbid = extract64(tcr, 51, 1);
 } else {
 int tg = extract32(tcr, 30, 2);
 using16k = tg == 1;
 using64k = tg == 3;
 tsz = extract32(tcr, 16, 6);
 epd = extract32(tcr, 23, 1);
-tbi = extract64(tcr, 38, 1);
 hpd = extract64(tcr, 42, 1);
-tbid = extract64(tcr, 52, 1);
 }
 }
 tsz = MIN(tsz, 39);  /* TODO: ARMv8.4-TTST */
 tsz = MAX(tsz, 16);  /* TODO: ARMv8.2-LVA  */
 
+/* Present TBI as a composite with TBID.  */
+tbi = aa64_va_parameter_tbi(tcr, mmu_idx);
+if (!data) {
+tbi &= ~aa64_va_parameter_tbid(tcr, mmu_idx);
+}
+tbi = (tbi >> select) & 1;
+
 return (ARMVAParameters) {
 .tsz = tsz,
 .select = select,
 .tbi = tbi,
-.tbid = tbid,
 .epd = epd,
 .hpd = hpd,
 .using16k = using16k,
@@ -10295,16 +10317,6 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState 
*env, uint64_t va,
 };
 }
 
-ARMVAParameters aa64_va_parameters(CPUARMState *env, uint64_t va,
-   ARMMMUIdx mmu_idx, bool data)
-{
-ARMVAParameters ret = aa64_va_parameters_both(env, va, mmu_idx);
-
-/* Present TBI as a composi

[PULL 11/52] target/arm: Fix select for aa64_va_parameters_both

[Peter Maydell]

From: Richard Henderson 

Select should always be 0 for a regime with one range.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
Message-id: 20200216194343.21331-3-richard.hender...@linaro.org
Signed-off-by: Peter Maydell 
---
 target/arm/helper.c | 46 +++--
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 366dbcf460d..b09a5012841 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10241,13 +10241,8 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState 
*env, uint64_t va,
 bool tbi, tbid, epd, hpd, using16k, using64k;
 int select, tsz;
 
-/*
- * Bit 55 is always between the two regions, and is canonical for
- * determining if address tagging is enabled.
- */
-select = extract64(va, 55, 1);
-
 if (!regime_has_2_ranges(mmu_idx)) {
+select = 0;
 tsz = extract32(tcr, 0, 6);
 using64k = extract32(tcr, 14, 1);
 using16k = extract32(tcr, 15, 1);
@@ -10260,23 +10255,30 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState 
*env, uint64_t va,
 tbid = extract32(tcr, 29, 1);
 }
 epd = false;
-} else if (!select) {
-tsz = extract32(tcr, 0, 6);
-epd = extract32(tcr, 7, 1);
-using64k = extract32(tcr, 14, 1);
-using16k = extract32(tcr, 15, 1);
-tbi = extract64(tcr, 37, 1);
-hpd = extract64(tcr, 41, 1);
-tbid = extract64(tcr, 51, 1);
 } else {
-int tg = extract32(tcr, 30, 2);
-using16k = tg == 1;
-using64k = tg == 3;
-tsz = extract32(tcr, 16, 6);
-epd = extract32(tcr, 23, 1);
-tbi = extract64(tcr, 38, 1);
-hpd = extract64(tcr, 42, 1);
-tbid = extract64(tcr, 52, 1);
+/*
+ * Bit 55 is always between the two regions, and is canonical for
+ * determining if address tagging is enabled.
+ */
+select = extract64(va, 55, 1);
+if (!select) {
+tsz = extract32(tcr, 0, 6);
+epd = extract32(tcr, 7, 1);
+using64k = extract32(tcr, 14, 1);
+using16k = extract32(tcr, 15, 1);
+tbi = extract64(tcr, 37, 1);
+hpd = extract64(tcr, 41, 1);
+tbid = extract64(tcr, 51, 1);
+} else {
+int tg = extract32(tcr, 30, 2);
+using16k = tg == 1;
+using64k = tg == 3;
+tsz = extract32(tcr, 16, 6);
+epd = extract32(tcr, 23, 1);
+tbi = extract64(tcr, 38, 1);
+hpd = extract64(tcr, 42, 1);
+tbid = extract64(tcr, 52, 1);
+}
 }
 tsz = MIN(tsz, 39);  /* TODO: ARMv8.4-TTST */
 tsz = MAX(tsz, 16);  /* TODO: ARMv8.2-LVA  */
-- 
2.20.1

[PULL 12/52] target/arm: Remove ttbr1_valid check from get_phys_addr_lpae

[Peter Maydell]

From: Richard Henderson 

Now that aa64_va_parameters_both sets select based on the number
of ranges in the regime, the ttbr1_valid check is redundant.

Signed-off-by: Richard Henderson 
Message-id: 20200216194343.21331-4-richard.hender...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target/arm/helper.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index b09a5012841..eec7b01ab35 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10390,7 +10390,6 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 TCR *tcr = regime_tcr(env, mmu_idx);
 int ap, ns, xn, pxn;
 uint32_t el = regime_el(env, mmu_idx);
-bool ttbr1_valid;
 uint64_t descaddrmask;
 bool aarch64 = arm_el_is_aa64(env, el);
 bool guarded = false;
@@ -10405,14 +10404,11 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 param = aa64_va_parameters(env, address, mmu_idx,
access_type != MMU_INST_FETCH);
 level = 0;
-ttbr1_valid = regime_has_2_ranges(mmu_idx);
 addrsize = 64 - 8 * param.tbi;
 inputsize = 64 - param.tsz;
 } else {
 param = aa32_va_parameters(env, address, mmu_idx);
 level = 1;
-/* There is no TTBR1 for EL2 */
-ttbr1_valid = (el != 2);
 addrsize = (mmu_idx == ARMMMUIdx_Stage2 ? 40 : 32);
 inputsize = addrsize - param.tsz;
 }
@@ -10429,7 +10425,7 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 if (inputsize < addrsize) {
 target_ulong top_bits = sextract64(address, inputsize,
addrsize - inputsize);
-if (-top_bits != param.select || (param.select && !ttbr1_valid)) {
+if (-top_bits != param.select) {
 /* The gap between the two regions is a Translation fault */
 fault_type = ARMFault_Translation;
 goto do_fault;
-- 
2.20.1

[PULL 14/52] target/arm: Add _aa32_ to isar_feature functions testing 32-bit ID registers

[Peter Maydell]

Enforce a convention that an isar_feature function that tests a
32-bit ID register always has _aa32_ in its name, and one that
tests a 64-bit ID register always has _aa64_ in its name.
We already follow this except for three cases: thumb_div,
arm_div and jazelle, which all need _aa32_ adding.

(As noted in the comment, isar_feature_aa32_fp16_arith()
is an exception in that it currently tests ID_AA64PFR0_EL1,
but will switch to MVFR1 once we've properly implemented
FP16 for AArch32.)

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-2-peter.mayd...@linaro.org
---
 target/arm/cpu.h   | 13 ++---
 target/arm/internals.h |  2 +-
 linux-user/elfload.c   |  4 ++--
 target/arm/cpu.c   |  6 --
 target/arm/helper.c|  2 +-
 target/arm/translate.c |  6 +++---
 6 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index e943ffe8a9a..37d40e57901 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3324,20 +3324,27 @@ static inline uint64_t *aa64_vfp_qreg(CPUARMState *env, 
unsigned regno)
 /* Shared between translate-sve.c and sve_helper.c.  */
 extern const uint64_t pred_esz_masks[4];
 
+/*
+ * Naming convention for isar_feature functions:
+ * Functions which test 32-bit ID registers should have _aa32_ in
+ * their name. Functions which test 64-bit ID registers should have
+ * _aa64_ in their name.
+ */
+
 /*
  * 32-bit feature tests via id registers.
  */
-static inline bool isar_feature_thumb_div(const ARMISARegisters *id)
+static inline bool isar_feature_aa32_thumb_div(const ARMISARegisters *id)
 {
 return FIELD_EX32(id->id_isar0, ID_ISAR0, DIVIDE) != 0;
 }
 
-static inline bool isar_feature_arm_div(const ARMISARegisters *id)
+static inline bool isar_feature_aa32_arm_div(const ARMISARegisters *id)
 {
 return FIELD_EX32(id->id_isar0, ID_ISAR0, DIVIDE) > 1;
 }
 
-static inline bool isar_feature_jazelle(const ARMISARegisters *id)
+static inline bool isar_feature_aa32_jazelle(const ARMISARegisters *id)
 {
 return FIELD_EX32(id->id_isar1, ID_ISAR1, JAZELLE) != 0;
 }
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 14328e3f7da..31aaa0eff87 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1091,7 +1091,7 @@ static inline uint32_t aarch32_cpsr_valid_mask(uint64_t 
features,
 if ((features >> ARM_FEATURE_THUMB2) & 1) {
 valid |= CPSR_IT;
 }
-if (isar_feature_jazelle(id)) {
+if (isar_feature_aa32_jazelle(id)) {
 valid |= CPSR_J;
 }
 if (isar_feature_aa32_pan(id)) {
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f3080a16358..b1a895f24ce 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -475,8 +475,8 @@ static uint32_t get_elf_hwcap(void)
 GET_FEATURE(ARM_FEATURE_VFP3, ARM_HWCAP_ARM_VFPv3);
 GET_FEATURE(ARM_FEATURE_V6K, ARM_HWCAP_ARM_TLS);
 GET_FEATURE(ARM_FEATURE_VFP4, ARM_HWCAP_ARM_VFPv4);
-GET_FEATURE_ID(arm_div, ARM_HWCAP_ARM_IDIVA);
-GET_FEATURE_ID(thumb_div, ARM_HWCAP_ARM_IDIVT);
+GET_FEATURE_ID(aa32_arm_div, ARM_HWCAP_ARM_IDIVA);
+GET_FEATURE_ID(aa32_thumb_div, ARM_HWCAP_ARM_IDIVT);
 /* All QEMU's VFPv3 CPUs have 32 registers, see VFP_DREG in translate.c.
  * Note that the ARM_HWCAP_ARM_VFPv3D16 bit is always the inverse of
  * ARM_HWCAP_ARM_VFPD32 (and so always clear for QEMU); it is unrelated
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index de733aceeb8..56f2ab865da 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1586,7 +1586,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
  * Security Extensions is ARM_FEATURE_EL3.
  */
-assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(arm_div, cpu));
+assert(!tcg_enabled() || no_aa32 ||
+   cpu_isar_feature(aa32_arm_div, cpu));
 set_feature(env, ARM_FEATURE_LPAE);
 set_feature(env, ARM_FEATURE_V7);
 }
@@ -1612,7 +1613,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 if (arm_feature(env, ARM_FEATURE_V6)) {
 set_feature(env, ARM_FEATURE_V5);
 if (!arm_feature(env, ARM_FEATURE_M)) {
-assert(!tcg_enabled() || no_aa32 || cpu_isar_feature(jazelle, 
cpu));
+assert(!tcg_enabled() || no_aa32 ||
+   cpu_isar_feature(aa32_jazelle, cpu));
 set_feature(env, ARM_FEATURE_AUXCR);
 }
 }
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 8d0f6eca27b..9c02d5d6b8e 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7396,7 +7396,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 if (arm_feature(env, ARM_FEATURE_LPAE)) {
 define_arm_cp_regs(cpu, lpae_cp_reginfo);
 }
-if (cpu_isar_feature(jazelle, cpu)) {
+if (cpu_isar_feature(aa32_jazelle, cpu)) {
 define_arm_cp_regs(cpu, 

[PULL 18/52] target/arm: Factor out PMU register definitions

[Peter Maydell]

Pull the code that defines the various PMU registers out
into its own function, matching the pattern we have
already for the debug registers.

Apart from one style fix to a multi-line comment, this
is purely movement of code with no changes to it.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-6-peter.mayd...@linaro.org
---
 target/arm/helper.c | 158 +++-
 1 file changed, 82 insertions(+), 76 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index ab36f33b719..cb2f4d8bbdb 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6317,6 +6317,87 @@ static void define_debug_regs(ARMCPU *cpu)
 }
 }
 
+static void define_pmu_regs(ARMCPU *cpu)
+{
+/*
+ * v7 performance monitor control register: same implementor
+ * field as main ID register, and we implement four counters in
+ * addition to the cycle count register.
+ */
+unsigned int i, pmcrn = 4;
+ARMCPRegInfo pmcr = {
+.name = "PMCR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 0,
+.access = PL0_RW,
+.type = ARM_CP_IO | ARM_CP_ALIAS,
+.fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmcr),
+.accessfn = pmreg_access, .writefn = pmcr_write,
+.raw_writefn = raw_write,
+};
+ARMCPRegInfo pmcr64 = {
+.name = "PMCR_EL0", .state = ARM_CP_STATE_AA64,
+.opc0 = 3, .opc1 = 3, .crn = 9, .crm = 12, .opc2 = 0,
+.access = PL0_RW, .accessfn = pmreg_access,
+.type = ARM_CP_IO,
+.fieldoffset = offsetof(CPUARMState, cp15.c9_pmcr),
+.resetvalue = (cpu->midr & 0xff00) | (pmcrn << PMCRN_SHIFT),
+.writefn = pmcr_write, .raw_writefn = raw_write,
+};
+define_one_arm_cp_reg(cpu, &pmcr);
+define_one_arm_cp_reg(cpu, &pmcr64);
+for (i = 0; i < pmcrn; i++) {
+char *pmevcntr_name = g_strdup_printf("PMEVCNTR%d", i);
+char *pmevcntr_el0_name = g_strdup_printf("PMEVCNTR%d_EL0", i);
+char *pmevtyper_name = g_strdup_printf("PMEVTYPER%d", i);
+char *pmevtyper_el0_name = g_strdup_printf("PMEVTYPER%d_EL0", i);
+ARMCPRegInfo pmev_regs[] = {
+{ .name = pmevcntr_name, .cp = 15, .crn = 14,
+  .crm = 8 | (3 & (i >> 3)), .opc1 = 0, .opc2 = i & 7,
+  .access = PL0_RW, .type = ARM_CP_IO | ARM_CP_ALIAS,
+  .readfn = pmevcntr_readfn, .writefn = pmevcntr_writefn,
+  .accessfn = pmreg_access },
+{ .name = pmevcntr_el0_name, .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 8 | (3 & (i >> 3)),
+  .opc2 = i & 7, .access = PL0_RW, .accessfn = pmreg_access,
+  .type = ARM_CP_IO,
+  .readfn = pmevcntr_readfn, .writefn = pmevcntr_writefn,
+  .raw_readfn = pmevcntr_rawread,
+  .raw_writefn = pmevcntr_rawwrite },
+{ .name = pmevtyper_name, .cp = 15, .crn = 14,
+  .crm = 12 | (3 & (i >> 3)), .opc1 = 0, .opc2 = i & 7,
+  .access = PL0_RW, .type = ARM_CP_IO | ARM_CP_ALIAS,
+  .readfn = pmevtyper_readfn, .writefn = pmevtyper_writefn,
+  .accessfn = pmreg_access },
+{ .name = pmevtyper_el0_name, .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 12 | (3 & (i >> 3)),
+  .opc2 = i & 7, .access = PL0_RW, .accessfn = pmreg_access,
+  .type = ARM_CP_IO,
+  .readfn = pmevtyper_readfn, .writefn = pmevtyper_writefn,
+  .raw_writefn = pmevtyper_rawwrite },
+REGINFO_SENTINEL
+};
+define_arm_cp_regs(cpu, pmev_regs);
+g_free(pmevcntr_name);
+g_free(pmevcntr_el0_name);
+g_free(pmevtyper_name);
+g_free(pmevtyper_el0_name);
+}
+if (FIELD_EX32(cpu->id_dfr0, ID_DFR0, PERFMON) >= 4 &&
+FIELD_EX32(cpu->id_dfr0, ID_DFR0, PERFMON) != 0xf) {
+ARMCPRegInfo v81_pmu_regs[] = {
+{ .name = "PMCEID2", .state = ARM_CP_STATE_AA32,
+  .cp = 15, .opc1 = 0, .crn = 9, .crm = 14, .opc2 = 4,
+  .access = PL0_R, .accessfn = pmreg_access, .type = ARM_CP_CONST,
+  .resetvalue = extract64(cpu->pmceid0, 32, 32) },
+{ .name = "PMCEID3", .state = ARM_CP_STATE_AA32,
+  .cp = 15, .opc1 = 0, .crn = 9, .crm = 14, .opc2 = 5,
+  .access = PL0_R, .accessfn = pmreg_access, .type = ARM_CP_CONST,
+  .resetvalue = extract64(cpu->pmceid1, 32, 32) },
+REGINFO_SENTINEL
+};
+define_arm_cp_regs(cpu, v81_pmu_regs);
+}
+}
+
 /* We don't know until after realize whether there's a GICv3
  * attached, and that is what registers the gicv3 sysregs.
  * So we have to fill in the GIC fields in ID_PFR/ID_PFR1_EL1/ID_AA64PFR0_EL1
@@ -6859,67 +6940,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define

[PULL 19/52] target/arm: Add and use FIELD definitions for ID_AA64DFR0_EL1

[Peter Maydell]

Add FIELD() definitions for the ID_AA64DFR0_EL1 and use them
where we currently have hard-coded bit values.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-7-peter.mayd...@linaro.org
---
 target/arm/cpu.h| 10 ++
 target/arm/cpu.c|  2 +-
 target/arm/helper.c |  6 +++---
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index ef0feb228ab..081955094dc 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1821,6 +1821,16 @@ FIELD(ID_AA64MMFR2, BBM, 52, 4)
 FIELD(ID_AA64MMFR2, EVT, 56, 4)
 FIELD(ID_AA64MMFR2, E0PD, 60, 4)
 
+FIELD(ID_AA64DFR0, DEBUGVER, 0, 4)
+FIELD(ID_AA64DFR0, TRACEVER, 4, 4)
+FIELD(ID_AA64DFR0, PMUVER, 8, 4)
+FIELD(ID_AA64DFR0, BRPS, 12, 4)
+FIELD(ID_AA64DFR0, WRPS, 20, 4)
+FIELD(ID_AA64DFR0, CTX_CMPS, 28, 4)
+FIELD(ID_AA64DFR0, PMSVER, 32, 4)
+FIELD(ID_AA64DFR0, DOUBLELOCK, 36, 4)
+FIELD(ID_AA64DFR0, TRACEFILT, 40, 4)
+
 FIELD(ID_DFR0, COPDBG, 0, 4)
 FIELD(ID_DFR0, COPSDBG, 4, 4)
 FIELD(ID_DFR0, MMAPDBG, 8, 4)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 56f2ab865da..12bf9688007 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1718,7 +1718,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 cpu);
 #endif
 } else {
-cpu->id_aa64dfr0 &= ~0xf00;
+cpu->id_aa64dfr0 = FIELD_DP64(cpu->id_aa64dfr0, ID_AA64DFR0, PMUVER, 
0);
 cpu->id_dfr0 &= ~(0xf << 24);
 cpu->pmceid0 = 0;
 cpu->pmceid1 = 0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index cb2f4d8bbdb..f183ac5cbfe 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6266,9 +6266,9 @@ static void define_debug_regs(ARMCPU *cpu)
  * check that if they both exist then they agree.
  */
 if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
-assert(extract32(cpu->id_aa64dfr0, 12, 4) == brps);
-assert(extract32(cpu->id_aa64dfr0, 20, 4) == wrps);
-assert(extract32(cpu->id_aa64dfr0, 28, 4) == ctx_cmps);
+assert(FIELD_EX64(cpu->id_aa64dfr0, ID_AA64DFR0, BRPS) == brps);
+assert(FIELD_EX64(cpu->id_aa64dfr0, ID_AA64DFR0, WRPS) == wrps);
+assert(FIELD_EX64(cpu->id_aa64dfr0, ID_AA64DFR0, CTX_CMPS) == 
ctx_cmps);
 }
 
 define_one_arm_cp_reg(cpu, &dbgdidr);
-- 
2.20.1

[PULL 16/52] target/arm: Add isar_feature_any_fp16 and document naming/usage conventions

[Peter Maydell]

Our current usage of the isar_feature feature tests almost always
uses an _aa32_ test when the code path is known to be AArch32
specific and an _aa64_ test when the code path is known to be
AArch64 specific. There is just one exception: in the vfp_set_fpscr
helper we check aa64_fp16 to determine whether the FZ16 bit in
the FP(S)CR exists, but this code is also used for AArch32.
There are other places in future where we're likely to want
a general "does this feature exist for either AArch32 or
AArch64" check (typically where architecturally the feature exists
for both CPU states if it exists at all, but the CPU might be
AArch32-only or AArch64-only, and so only have one set of ID
registers).

Introduce a new category of isar_feature_* functions:
isar_feature_any_foo() should be tested when what we want to
know is "does this feature exist for either AArch32 or AArch64",
and always returns the logical OR of isar_feature_aa32_foo()
and isar_feature_aa64_foo().

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-4-peter.mayd...@linaro.org
---
 target/arm/cpu.h| 19 ++-
 target/arm/vfp_helper.c |  2 +-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 37d40e57901..7ccd65bdce3 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3328,7 +3328,16 @@ extern const uint64_t pred_esz_masks[4];
  * Naming convention for isar_feature functions:
  * Functions which test 32-bit ID registers should have _aa32_ in
  * their name. Functions which test 64-bit ID registers should have
- * _aa64_ in their name.
+ * _aa64_ in their name. These must only be used in code where we
+ * know for certain that the CPU has AArch32 or AArch64 respectively
+ * or where the correct answer for a CPU which doesn't implement that
+ * CPU state is "false" (eg when generating A32 or A64 code, if adding
+ * system registers that are specific to that CPU state, for "should
+ * we let this system register bit be set" tests where the 32-bit
+ * flavour of the register doesn't have the bit, and so on).
+ * Functions which simply ask "does this feature exist at all" have
+ * _any_ in their name, and always return the logical OR of the _aa64_
+ * and the _aa32_ function.
  */
 
 /*
@@ -3660,6 +3669,14 @@ static inline bool isar_feature_aa64_bti(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, BT) != 0;
 }
 
+/*
+ * Feature tests for "does this exist in either 32-bit or 64-bit?"
+ */
+static inline bool isar_feature_any_fp16(const ARMISARegisters *id)
+{
+return isar_feature_aa64_fp16(id) || isar_feature_aa32_fp16_arith(id);
+}
+
 /*
  * Forward to the above feature tests given an ARMCPU pointer.
  */
diff --git a/target/arm/vfp_helper.c b/target/arm/vfp_helper.c
index 0ae7d4f34a9..930d6e747f6 100644
--- a/target/arm/vfp_helper.c
+++ b/target/arm/vfp_helper.c
@@ -185,7 +185,7 @@ uint32_t vfp_get_fpscr(CPUARMState *env)
 void HELPER(vfp_set_fpscr)(CPUARMState *env, uint32_t val)
 {
 /* When ARMv8.2-FP16 is not supported, FZ16 is RES0.  */
-if (!cpu_isar_feature(aa64_fp16, env_archcpu(env))) {
+if (!cpu_isar_feature(any_fp16, env_archcpu(env))) {
 val &= ~FPCR_FZ16;
 }
 
-- 
2.20.1

[PULL 21/52] target/arm: Define an aa32_pmu_8_1 isar feature test function

[Peter Maydell]

Instead of open-coding a check on the ID_DFR0 PerfMon ID register
field, create a standardly-named isar_feature for "does AArch32 have
a v8.1 PMUv3" and use it.

This entails moving the id_dfr0 field into the ARMISARegisters struct.

Reviewed-by: Richard Henderson 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-9-peter.mayd...@linaro.org
---
 target/arm/cpu.h  |  9 -
 hw/intc/armv7m_nvic.c |  2 +-
 target/arm/cpu.c  | 28 ++--
 target/arm/cpu64.c|  6 +++---
 target/arm/helper.c   |  5 ++---
 5 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 081955094dc..6c6088eb587 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -865,6 +865,7 @@ struct ARMCPU {
 uint32_t mvfr0;
 uint32_t mvfr1;
 uint32_t mvfr2;
+uint32_t id_dfr0;
 uint64_t id_aa64isar0;
 uint64_t id_aa64isar1;
 uint64_t id_aa64pfr0;
@@ -880,7 +881,6 @@ struct ARMCPU {
 uint32_t reset_sctlr;
 uint32_t id_pfr0;
 uint32_t id_pfr1;
-uint32_t id_dfr0;
 uint64_t pmceid0;
 uint64_t pmceid1;
 uint32_t id_afr0;
@@ -3500,6 +3500,13 @@ static inline bool isar_feature_aa32_ats1e1(const 
ARMISARegisters *id)
 return FIELD_EX64(id->mvfr0, ID_MMFR3, PAN) >= 2;
 }
 
+static inline bool isar_feature_aa32_pmu_8_1(const ARMISARegisters *id)
+{
+/* 0xf means "non-standard IMPDEF PMU" */
+return FIELD_EX32(id->id_dfr0, ID_DFR0, PERFMON) >= 4 &&
+FIELD_EX32(id->id_dfr0, ID_DFR0, PERFMON) != 0xf;
+}
+
 /*
  * 64-bit feature tests via id registers.
  */
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index f9e0eeaace6..5a403fc9704 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -1227,7 +1227,7 @@ static uint32_t nvic_readl(NVICState *s, uint32_t offset, 
MemTxAttrs attrs)
 case 0xd44: /* PFR1.  */
 return cpu->id_pfr1;
 case 0xd48: /* DFR0.  */
-return cpu->id_dfr0;
+return cpu->isar.id_dfr0;
 case 0xd4c: /* AFR0.  */
 return cpu->id_afr0;
 case 0xd50: /* MMFR0.  */
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 1024f506c51..b85040d36bc 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1719,7 +1719,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 #endif
 } else {
 cpu->id_aa64dfr0 = FIELD_DP64(cpu->id_aa64dfr0, ID_AA64DFR0, PMUVER, 
0);
-cpu->id_dfr0 = FIELD_DP32(cpu->id_dfr0, ID_DFR0, PERFMON, 0);
+cpu->isar.id_dfr0 = FIELD_DP32(cpu->isar.id_dfr0, ID_DFR0, PERFMON, 0);
 cpu->pmceid0 = 0;
 cpu->pmceid1 = 0;
 }
@@ -1957,7 +1957,7 @@ static void arm1136_r2_initfn(Object *obj)
 cpu->reset_sctlr = 0x00050078;
 cpu->id_pfr0 = 0x111;
 cpu->id_pfr1 = 0x1;
-cpu->id_dfr0 = 0x2;
+cpu->isar.id_dfr0 = 0x2;
 cpu->id_afr0 = 0x3;
 cpu->id_mmfr0 = 0x01130003;
 cpu->id_mmfr1 = 0x10030302;
@@ -1989,7 +1989,7 @@ static void arm1136_initfn(Object *obj)
 cpu->reset_sctlr = 0x00050078;
 cpu->id_pfr0 = 0x111;
 cpu->id_pfr1 = 0x1;
-cpu->id_dfr0 = 0x2;
+cpu->isar.id_dfr0 = 0x2;
 cpu->id_afr0 = 0x3;
 cpu->id_mmfr0 = 0x01130003;
 cpu->id_mmfr1 = 0x10030302;
@@ -2022,7 +2022,7 @@ static void arm1176_initfn(Object *obj)
 cpu->reset_sctlr = 0x00050078;
 cpu->id_pfr0 = 0x111;
 cpu->id_pfr1 = 0x11;
-cpu->id_dfr0 = 0x33;
+cpu->isar.id_dfr0 = 0x33;
 cpu->id_afr0 = 0;
 cpu->id_mmfr0 = 0x01130003;
 cpu->id_mmfr1 = 0x10030302;
@@ -2052,7 +2052,7 @@ static void arm11mpcore_initfn(Object *obj)
 cpu->ctr = 0x1d192992; /* 32K icache 32K dcache */
 cpu->id_pfr0 = 0x111;
 cpu->id_pfr1 = 0x1;
-cpu->id_dfr0 = 0;
+cpu->isar.id_dfr0 = 0;
 cpu->id_afr0 = 0x2;
 cpu->id_mmfr0 = 0x01100103;
 cpu->id_mmfr1 = 0x10020302;
@@ -2084,7 +2084,7 @@ static void cortex_m3_initfn(Object *obj)
 cpu->pmsav7_dregion = 8;
 cpu->id_pfr0 = 0x0030;
 cpu->id_pfr1 = 0x0200;
-cpu->id_dfr0 = 0x0010;
+cpu->isar.id_dfr0 = 0x0010;
 cpu->id_afr0 = 0x;
 cpu->id_mmfr0 = 0x0030;
 cpu->id_mmfr1 = 0x;
@@ -2115,7 +2115,7 @@ static void cortex_m4_initfn(Object *obj)
 cpu->isar.mvfr2 = 0x;
 cpu->id_pfr0 = 0x0030;
 cpu->id_pfr1 = 0x0200;
-cpu->id_dfr0 = 0x0010;
+cpu->isar.id_dfr0 = 0x0010;
 cpu->id_afr0 = 0x;
 cpu->id_mmfr0 = 0x0030;
 cpu->id_mmfr1 = 0x;
@@ -2146,7 +2146,7 @@ static void cortex_m7_initfn(Object *obj)
 cpu->isar.mvfr2 = 0x0040;
 cpu->id_pfr0 = 0x0030;
 cpu->id_pfr1 = 0x0200;
-cpu->id_dfr0 = 0x0010;
+cpu->isar.id_dfr0 = 0x0010;
 cpu->id_afr0 = 0x;
 cpu->id_mmfr0 = 0x00100030;
 cpu->id_mmfr1 = 0x;
@@ -2179,7 +2179,7 @@ static void cortex_m33_initfn(Object *obj)
 cpu->isar.mvfr2 = 0x0040;
 cpu->id_pfr0 = 0x0030;
 cpu->

[PULL 23/52] target/arm: Stop assuming DBGDIDR always exists

[Peter Maydell]

The AArch32 DBGDIDR defines properties like the number of
breakpoints, watchpoints and context-matching comparators.  On an
AArch64 CPU, the register may not even exist if AArch32 is not
supported at EL1.

Currently we hard-code use of DBGDIDR to identify the number of
breakpoints etc; this works for all our TCG CPUs, but will break if
we ever add an AArch64-only CPU.  We also have an assert() that the
AArch32 and AArch64 registers match, which currently works only by
luck for KVM because we don't populate either of these ID registers
from the KVM vCPU and so they are both zero.

Clean this up so we have functions for finding the number
of breakpoints, watchpoints and context comparators which look
in the appropriate ID register.

This allows us to drop the "check that AArch64 and AArch32 agree
on the number of breakpoints etc" asserts:
 * we no longer look at the AArch32 versions unless that's the
   right place to be looking
 * it's valid to have a CPU (eg AArch64-only) where they don't match
 * we shouldn't have been asserting the validity of ID registers
   in a codepath used with KVM anyway

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20200214175116.9164-11-peter.mayd...@linaro.org
---
 target/arm/cpu.h  |  7 +++
 target/arm/internals.h| 42 +++
 target/arm/debug_helper.c |  6 +++---
 target/arm/helper.c   | 21 +---
 4 files changed, 57 insertions(+), 19 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 98240224c0c..0f21b6ed803 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1840,6 +1840,13 @@ FIELD(ID_DFR0, MPROFDBG, 20, 4)
 FIELD(ID_DFR0, PERFMON, 24, 4)
 FIELD(ID_DFR0, TRACEFILT, 28, 4)
 
+FIELD(DBGDIDR, SE_IMP, 12, 1)
+FIELD(DBGDIDR, NSUHD_IMP, 14, 1)
+FIELD(DBGDIDR, VERSION, 16, 4)
+FIELD(DBGDIDR, CTX_CMPS, 20, 4)
+FIELD(DBGDIDR, BRPS, 24, 4)
+FIELD(DBGDIDR, WRPS, 28, 4)
+
 FIELD(MVFR0, SIMDREG, 0, 4)
 FIELD(MVFR0, FPSP, 4, 4)
 FIELD(MVFR0, FPDP, 8, 4)
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 31aaa0eff87..e07a7306c77 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -931,6 +931,48 @@ static inline uint32_t arm_debug_exception_fsr(CPUARMState 
*env)
 }
 }
 
+/**
+ * arm_num_brps: Return number of implemented breakpoints.
+ * Note that the ID register BRPS field is "number of bps - 1",
+ * and we return the actual number of breakpoints.
+ */
+static inline int arm_num_brps(ARMCPU *cpu)
+{
+if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
+return FIELD_EX64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, BRPS) + 1;
+} else {
+return FIELD_EX32(cpu->dbgdidr, DBGDIDR, BRPS) + 1;
+}
+}
+
+/**
+ * arm_num_wrps: Return number of implemented watchpoints.
+ * Note that the ID register WRPS field is "number of wps - 1",
+ * and we return the actual number of watchpoints.
+ */
+static inline int arm_num_wrps(ARMCPU *cpu)
+{
+if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
+return FIELD_EX64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, WRPS) + 1;
+} else {
+return FIELD_EX32(cpu->dbgdidr, DBGDIDR, WRPS) + 1;
+}
+}
+
+/**
+ * arm_num_ctx_cmps: Return number of implemented context comparators.
+ * Note that the ID register CTX_CMPS field is "number of cmps - 1",
+ * and we return the actual number of comparators.
+ */
+static inline int arm_num_ctx_cmps(ARMCPU *cpu)
+{
+if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
+return FIELD_EX64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, CTX_CMPS) + 1;
+} else {
+return FIELD_EX32(cpu->dbgdidr, DBGDIDR, CTX_CMPS) + 1;
+}
+}
+
 /* Note make_memop_idx reserves 4 bits for mmu_idx, and MO_BSWAP is bit 3.
  * Thus a TCGMemOpIdx, without any MO_ALIGN bits, fits in 8 bits.
  */
diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index 2e3e90c6a57..2ff72d47d19 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -16,8 +16,8 @@ static bool linked_bp_matches(ARMCPU *cpu, int lbn)
 {
 CPUARMState *env = &cpu->env;
 uint64_t bcr = env->cp15.dbgbcr[lbn];
-int brps = extract32(cpu->dbgdidr, 24, 4);
-int ctx_cmps = extract32(cpu->dbgdidr, 20, 4);
+int brps = arm_num_brps(cpu);
+int ctx_cmps = arm_num_ctx_cmps(cpu);
 int bt;
 uint32_t contextidr;
 uint64_t hcr_el2;
@@ -29,7 +29,7 @@ static bool linked_bp_matches(ARMCPU *cpu, int lbn)
  * case DBGWCR_EL1.LBN must indicate that breakpoint).
  * We choose the former.
  */
-if (lbn > brps || lbn < (brps - ctx_cmps)) {
+if (lbn >= brps || lbn < (brps - ctx_cmps)) {
 return false;
 }
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 679f340c55f..87e71fb8c78 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6256,23 +6256,12 @@ static void define_debug_regs(ARMCPU *cpu)
 };
 
 /* Note that all these register fields hold "number of Xs minus 1". */
-brps = extract32(cpu-

[PULL 30/52] target/arm: Correct handling of PMCR_EL0.LC bit

[Peter Maydell]

The LC bit in the PMCR_EL0 register is supposed to be:
 * read/write
 * RES1 on an AArch64-only implementation
 * an architecturally UNKNOWN value on reset
(and use of LC==0 by software is deprecated).

We were implementing it incorrectly as read-only always zero,
though we do have all the code needed to test it and behave
accordingly.

Instead make it a read-write bit which resets to 1 always, which
satisfies all the architectural requirements above.

Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Peter Maydell 
Message-id: 20200214175116.9164-18-peter.mayd...@linaro.org
---
 target/arm/helper.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index e868b08cc18..15a840f530b 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1023,6 +1023,11 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {
 #define PMCRC   0x4
 #define PMCRP   0x2
 #define PMCRE   0x1
+/*
+ * Mask of PMCR bits writeable by guest (not including WO bits like C, P,
+ * which can be written as 1 to trigger behaviour but which stay RAZ).
+ */
+#define PMCR_WRITEABLE_MASK (PMCRLC | PMCRDP | PMCRX | PMCRD | PMCRE)
 
 #define PMXEVTYPER_P  0x8000
 #define PMXEVTYPER_U  0x4000
@@ -1577,9 +1582,8 @@ static void pmcr_write(CPUARMState *env, const 
ARMCPRegInfo *ri,
 }
 }
 
-/* only the DP, X, D and E bits are writable */
-env->cp15.c9_pmcr &= ~0x39;
-env->cp15.c9_pmcr |= (value & 0x39);
+env->cp15.c9_pmcr &= ~PMCR_WRITEABLE_MASK;
+env->cp15.c9_pmcr |= (value & PMCR_WRITEABLE_MASK);
 
 pmu_op_finish(env);
 }
@@ -6370,7 +6374,8 @@ static void define_pmu_regs(ARMCPU *cpu)
 .access = PL0_RW, .accessfn = pmreg_access,
 .type = ARM_CP_IO,
 .fieldoffset = offsetof(CPUARMState, cp15.c9_pmcr),
-.resetvalue = (cpu->midr & 0xff00) | (pmcrn << PMCRN_SHIFT),
+.resetvalue = (cpu->midr & 0xff00) | (pmcrn << PMCRN_SHIFT) |
+  PMCRLC,
 .writefn = pmcr_write, .raw_writefn = raw_write,
 };
 define_one_arm_cp_reg(cpu, &pmcr);
-- 
2.20.1