Re: [PATCH 0/3] qom: Replace INTERFACE_CHECK with OBJECT_CHECK

2020-09-17 Thread Markus Armbruster
Eduardo Habkost  writes:

> This series replaces INTERFACE_CHECK with OBJECT_CHECK because
> both macros are exactly the same.

See also issue#2 in

Subject: Issues around TYPE_INTERFACE
Date: Tue, 12 Mar 2019 11:50:54 +0100
Message-ID: <87h8c82woh@dusky.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2019-03/msg03840.html

> The last patch is a new run of the OBJECT_CHECK ->
> DECLARE*_CHECKER* converter script that will convert the former
> INTERFACE_CHECK-based macros.




Re: [PATCH v5 09/11] piix4: don't reserve hw resources when hotplug is off globally

2020-09-17 Thread Igor Mammedov
On Thu, 17 Sep 2020 12:09:46 +0530
Ani Sinha  wrote:

> On Thu, Sep 17, 2020 at 11:46 AM Igor Mammedov  wrote:
> >
> > On Wed, 16 Sep 2020 13:49:08 +0530
> > Ani Sinha  wrote:
> >  
> > > When acpi hotplug is turned off for both root pci bus as well as for pci
> > > bridges, we should not generate the related acpi code for DSDT table or
> > > initialize related hw ports or reserve hw resources. This change makes
> > > sure all those operations are turned off in the case acpi pci hotplug is
> > > off globally.
> > >
> > > In this change, we also make sure AMLs for the PCNT method are only added 
> > > when
> > > bsel is enabled for the corresponding pci bus or bridge hotplug is turned 
> > > on.
> > > As a result, when the hotplug for both the root pci device and bridge are
> > > disabled, this AML in the DSDT acpi table is turned off.
> > >
> > > As q35 machines do not use bsel for it's pci buses at this point in time, 
> > > this
> > > change affects DSDT acpi table for q35 machines as well. Therefore, we 
> > > also
> > > commit the updated golden master DSDT table acpi binary blobs as well.  
> >
> > Please split binary blobs into separate patch, as described in process.
> > Otherwise the patch is very likely to become un-merge-able due to 
> > conflicts.  
> 
> I wanted to make sure that the changes in this patch and the blobs go
> together as a single atomic commit since the unit test will break if
> one has the patch but not the blobs.

it would work if it were the only patch that touches ACPI,
process instructs splitting acpi changes in 3 part to avoid issues
with merging and bisecting. (it saves time not only of maintainer
but your as well)

Additionally, one can not review (without going into trouble of 
testing/disassembling)
binary blobs, so it's good to split them out into a separate patch.

> >  
> > > Following is a typical diff between the q35 acpi DSDT table blobs:
> > >
> > > @@ -1,30 +1,30 @@
> > >  /*
> > >   * Intel ACPI Component Architecture
> > >   * AML/ASL+ Disassembler version 20180105 (64-bit version)
> > >   * Copyright (c) 2000 - 2018 Intel Corporation
> > >   *
> > >   * Disassembling to symbolic ASL+ operators
> > >   *
> > > - * Disassembly of tests/data/acpi/q35/DSDT, Tue Sep 15 18:52:47 2020
> > > + * Disassembly of /tmp/aml-3O0DR0, Tue Sep 15 18:52:47 2020
> > >   *
> > >   * Original Table Header:
> > >   * Signature"DSDT"
> > > - * Length   0x1DFE (7678)
> > > + * Length   0x1DF6 (7670)
> > >   * Revision 0x01  32-bit table (V1), no 64-bit math 
> > > support
> > > - * Checksum 0xAC
> > > + * Checksum 0x17
> > >   * OEM ID   "BOCHS "
> > >   * OEM Table ID "BXPCDSDT"
> > >   * OEM Revision 0x0001 (1)
> > >   * Compiler ID  "BXPC"
> > >   * Compiler Version 0x0001 (1)
> > >   */
> > >  DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPCDSDT", 0x0001)
> > >  {
> > >  Scope (\)
> > >  {
> > >  OperationRegion (DBG, SystemIO, 0x0402, One)
> > >  Field (DBG, ByteAcc, NoLock, Preserve)
> > >  {
> > >  DBGB,   8
> > >  }
> > >
> > > @@ -3113,24 +3113,20 @@
> > >  Name (_ADR, 0x0001)  // _ADR: Address
> > >  Method (_S1D, 0, NotSerialized)  // _S1D: S1 Device State
> > >  {
> > >  Return (Zero)
> > >  }
> > >
> > >  Method (_S2D, 0, NotSerialized)  // _S2D: S2 Device State
> > >  {
> > >  Return (Zero)
> > >  }
> > >
> > >  Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
> > >  {
> > >  Return (Zero)
> > >  }
> > >  }
> > > -
> > > -Method (PCNT, 0, NotSerialized)
> > > -{
> > > -}
> > >  }
> > >  }
> > >  }
> > >
> > > Signed-off-by: Ani Sinha 
> > > ---
> > >  hw/acpi/piix4.c   |   6 --
> > >  hw/i386/acpi-build.c  |  25 ++---
> > >  tests/data/acpi/q35/DSDT  | Bin 7678 -> 7670 bytes
> > >  tests/data/acpi/q35/DSDT.acpihmat | Bin 9002 -> 8994 bytes
> > >  tests/data/acpi/q35/DSDT.bridge   | Bin 7695 -> 7688 bytes
> > >  tests/data/acpi/q35/DSDT.cphp | Bin 8141 -> 8133 bytes
> > >  tests/data/acpi/q35/DSDT.dimmpxm  | Bin 9331 -> 9323 bytes
> > >  tests/data/acpi/q35/DSDT.ipmibt   | Bin 7753 -> 7745 bytes
> > >  tests/data/acpi/q35/DSDT.memhp| Bin 9037 -> 9029 bytes
> > >  tests/data/acpi/q35/DSDT.mmio64   | Bin 8808 -> 8801 bytes
> > >  tests/data/acpi/q35/DSDT.numamem  | Bin 7684 -> 7676 bytes
> > >  tests/data/acpi/q35/DSDT.tis  | Bin 8283 -> 8276 bytes
> > >  12 files changed, 22 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > index e6163bb6ce..b70b1f98af 100644
> > > --- a/hw/acpi/piix4.

Re: [PATCH 3/5] qom: Remove module_obj_name parameter from OBJECT_DECLARE* macros

2020-09-17 Thread Igor Mammedov
On Wed, 16 Sep 2020 14:25:17 -0400
Eduardo Habkost  wrote:

> One of the goals of having less boilerplate on QOM declarations
> is to avoid human error.  Requiring an extra argument that is
> never used is an opportunity for mistakes.
> 
> Remove the unused argument from OBJECT_DECLARE_TYPE and
> OBJECT_DECLARE_SIMPLE_TYPE.
> 
> Coccinelle patch used to convert all users of the macros:
> 
>   @@
>   declarer name OBJECT_DECLARE_TYPE;
>   identifier InstanceType, ClassType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_TYPE(InstanceType, ClassType,
>   -lowercase,
>UPPERCASE);
> 
>   @@
>   declarer name OBJECT_DECLARE_SIMPLE_TYPE;
>   identifier InstanceType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_SIMPLE_TYPE(InstanceType,
>   -lowercase,
>UPPERCASE);
> 
> Signed-off-by: Eduardo Habkost 

for x86/virtio/hostmem/QOM
Acked-by: Igor Mammedov 

> ---
> Cc: "Marc-André Lureau" 
> Cc: Gerd Hoffmann 
> Cc: "Michael S. Tsirkin" 
> Cc: "Daniel P. Berrangé" 
> Cc: Peter Maydell 
> Cc: Corey Minyard 
> Cc: "Cédric Le Goater" 
> Cc: David Gibson 
> Cc: Cornelia Huck 
> Cc: Thomas Huth 
> Cc: Halil Pasic 
> Cc: Christian Borntraeger 
> Cc: "Philippe Mathieu-Daudé" 
> Cc: Alistair Francis 
> Cc: David Hildenbrand 
> Cc: Laurent Vivier 
> Cc: Amit Shah 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: Paolo Bonzini 
> Cc: Eduardo Habkost 
> Cc: Fam Zheng 
> Cc: "Gonglei (Arei)" 
> Cc: Igor Mammedov 
> Cc: Stefan Berger 
> Cc: Richard Henderson 
> Cc: Michael Rolnik 
> Cc: Sarah Harris 
> Cc: "Edgar E. Iglesias" 
> Cc: Michael Walle 
> Cc: Aleksandar Markovic 
> Cc: Aurelien Jarno 
> Cc: Jiaxun Yang 
> Cc: Aleksandar Rikalo 
> Cc: Anthony Green 
> Cc: Chris Wulff 
> Cc: Marek Vasut 
> Cc: Stafford Horne 
> Cc: Palmer Dabbelt 
> Cc: Sagar Karandikar 
> Cc: Bastian Koppelmann 
> Cc: Yoshinori Sato 
> Cc: Mark Cave-Ayland 
> Cc: Artyom Tarasenko 
> Cc: Guan Xuetao 
> Cc: Max Filippov 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-s3...@nongnu.org
> Cc: qemu-bl...@nongnu.org
> Cc: xen-de...@lists.xenproject.org
> Cc: qemu-ri...@nongnu.org
> ---
>  hw/audio/intel-hda.h| 2 +-
>  hw/display/virtio-vga.h | 2 +-
>  include/authz/base.h| 2 +-
>  include/authz/list.h| 2 +-
>  include/authz/listfile.h| 2 +-
>  include/authz/pamacct.h | 2 +-
>  include/authz/simple.h  | 2 +-
>  include/crypto/secret_common.h  | 2 +-
>  include/crypto/secret_keyring.h | 2 +-
>  include/hw/arm/armsse.h | 2 +-
>  include/hw/hyperv/vmbus.h   | 2 +-
>  include/hw/i2c/i2c.h| 2 +-
>  include/hw/i2c/smbus_slave.h| 2 +-
>  include/hw/ipack/ipack.h| 2 +-
>  include/hw/ipmi/ipmi.h  | 2 +-
>  include/hw/mem/pc-dimm.h| 2 +-
>  include/hw/ppc/pnv.h| 2 +-
>  include/hw/ppc/pnv_core.h   | 2 +-
>  include/hw/ppc/pnv_homer.h  | 2 +-
>  include/hw/ppc/pnv_occ.h| 2 +-
>  include/hw/ppc/pnv_psi.h| 2 +-
>  include/hw/ppc/pnv_xive.h   | 2 +-
>  include/hw/ppc/spapr_cpu_core.h | 2 +-
>  include/hw/ppc/spapr_vio.h  | 2 +-
>  include/hw/ppc/xics.h   | 2 +-
>  include/hw/ppc/xive.h   | 2 +-
>  include/hw/s390x/event-facility.h   | 2 +-
>  include/hw/s390x/s390_flic.h| 2 +-
>  include/hw/s390x/sclp.h | 2 +-
>  include/hw/sd/sd.h  | 2 +-
>  include/hw/ssi/ssi.h| 2 +-
>  include/hw/sysbus.h | 2 +-
>  include/hw/virtio/virtio-gpu.h  | 2 +-
>  include/hw/virtio/virtio-input.h| 2 +-
>  include/hw/virtio/virtio-mem.h  | 2 +-
>  include/hw/virtio/virtio-pmem.h | 2 +-
>  include/hw/virtio/virtio-serial.h   | 2 +-
>  include/hw/xen/xen-bus.h| 2 +-
>  include/io/channel.h| 2 +-
>  include/io/dns-resolver.h   | 2 +-
>  include/io/net-listener.h   | 2 +-
>  include/qom/object.h| 6 ++
>  include/scsi/pr-manager.h   | 2 +-
>  include/sysemu/cryptodev.h  | 2 +-
>  include/sysemu/hostmem.h| 2 +-
>  include/sysemu/rng.h| 2 +-
>  include/sysemu/tpm_backend.h| 2 +-
>  include/sysemu/vhost-user-backend.h | 2 +-
>  target/alpha/cpu-qom.h  | 2 +-
>  target/arm/cpu-qom.h| 2 +-
>  target/avr/cpu-qom.h| 2 +-
>  target/cris/cpu-qom.h   | 2 +-
>  target/hppa/cpu-qom.h   | 2 +-
>  target/i386/cpu-qom.h   | 2 +-
>  target/lm32/cpu-qom.h   | 2 +-
>  target/m68k/cpu-qom.h   | 2 +-
>  target/microblaze/cpu-qom.h | 2 +-
>  target/mips/cpu-qom.h   | 2 +-
>  target/moxie/cpu.h  | 2 +-
>  target/nios2/cpu.h  | 2 +-
>  

Re: [PATCH 07/14] block/blklogwrites: drop error propagation

2020-09-17 Thread Markus Armbruster
Ari Sundholm  writes:

> Hi,
>
> On 9/11/20 11:03 AM, Markus Armbruster wrote:
>> Ari Sundholm  writes:
>> 
>>> Hi Vladimir!
>>>
>>> Thank you for working on this. My comments below.
>>>
>>> On 9/9/20 9:59 PM, Vladimir Sementsov-Ogievskiy wrote:
 It's simple to avoid error propagation in blk_log_writes_open(), we
 just need to refactor blk_log_writes_find_cur_log_sector() a bit.
 Signed-off-by: Vladimir Sementsov-Ogievskiy
 
 ---
block/blklogwrites.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
 diff --git a/block/blklogwrites.c b/block/blklogwrites.c
 index 7ef046cee9..c7da507b2d 100644
 --- a/block/blklogwrites.c
 +++ b/block/blklogwrites.c
 @@ -96,10 +96,10 @@ static inline bool 
 blk_log_writes_sector_size_valid(uint32_t sector_size)
sector_size < (1ull << 24);
}
-static uint64_t blk_log_writes_find_cur_log_sector(BdrvChild
 *log,
 -   uint32_t sector_size,
 -   uint64_t nr_entries,
 -   Error **errp)
 +static int64_t blk_log_writes_find_cur_log_sector(BdrvChild *log,
>>>
>>> I'd rather not change the return type for reasons detailed below.
>>>
 +  uint32_t sector_size,
 +  uint64_t nr_entries,
 +  Error **errp)
{
uint64_t cur_sector = 1;
uint64_t cur_idx = 0;
 @@ -112,13 +112,13 @@ static uint64_t 
 blk_log_writes_find_cur_log_sector(BdrvChild *log,
if (read_ret < 0) {
error_setg_errno(errp, -read_ret,
 "Failed to read log entry %"PRIu64, 
 cur_idx);
 -return (uint64_t)-1ull;
 +return read_ret;
>>>
>>> This is OK, provided the change in return type signedness is necessary
>>> in the first place.
>>>
}
  if (cur_entry.flags & ~cpu_to_le64(LOG_FLAG_MASK)) {
error_setg(errp, "Invalid flags 0x%"PRIx64" in log entry 
 %"PRIu64,
   le64_to_cpu(cur_entry.flags), cur_idx);
 -return (uint64_t)-1ull;
 +return -EINVAL;
>>>
>>> This is OK, provided the return type signedness change is necessary,
>>> although we already do have errp to indicate any errors.
>>>
}
  /* Account for the sector of the entry itself */
 @@ -143,7 +143,6 @@ static int blk_log_writes_open(BlockDriverState *bs, 
 QDict *options, int flags,
{
BDRVBlkLogWritesState *s = bs->opaque;
QemuOpts *opts;
 -Error *local_err = NULL;
int ret;
uint64_t log_sector_size;
bool log_append;
 @@ -215,15 +214,15 @@ static int blk_log_writes_open(BlockDriverState *bs, 
 QDict *options, int flags,
s->nr_entries = 0;
  if (blk_log_writes_sector_size_valid(log_sector_size)) {
 -s->cur_log_sector =
 +int64_t cur_log_sector =
blk_log_writes_find_cur_log_sector(s->log_file, 
 log_sector_size,
 -le64_to_cpu(log_sb.nr_entries), 
 &local_err);
 -if (local_err) {
 -ret = -EINVAL;
 -error_propagate(errp, local_err);
 +le64_to_cpu(log_sb.nr_entries), errp);
 +if (cur_log_sector < 0) {
 +ret = cur_log_sector;
>>>
>>> This changes the semantics slightly. Changing the return type to int64
>>> may theoretically cause valid return values to be interpreted as
>>> errors. Since we already do have a dedicated out pointer for the error
>>> value (errp), why not use it?
>> Error.h's big comment:
>>   * Error reporting system loosely patterned after Glib's GError.
>>   *
>>   * = Rules =
>>   [...]
>>   * - Whenever practical, also return a value that indicates success /
>>   *   failure.  This can make the error checking more concise, and can
>>   *   avoid useless error object creation and destruction.  Note that
>>   *   we still have many functions returning void.  We recommend
>>   *   • bool-valued functions return true on success / false on failure,
>>   *   • pointer-valued functions return non-null / null pointer, and
>>   *   • integer-valued functions return non-negative / negative.
>> blk_log_writes_find_cur_log_sector() does return such an error value
>> before the patch: (uint64_t)-1.
>> The caller does not use it to check for errors.  It uses @err
>> instead.
>> Awkward, has to error_propagate().
>> Avoiding error_propagate() reduces the error handling boileplate.
>> It
>> also improves b

Re: [PATCH] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Paolo Bonzini
On 17/09/20 08:30, Thomas Huth wrote:
> On 16/09/2020 19.19, Thomas Huth wrote:
>> GCC 9.3.0 on Ubuntu complains:
>>
>> In file included from /usr/include/string.h:495,
>>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>>  from ../migration/global_state.c:13:
>> In function ‘strncpy’,
>> inlined from ‘global_state_store_running’ at 
>> ../migration/global_state.c:47:5:
>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
>> ‘__builtin_strncpy’ specified bound 100 equals destination size 
>> [-Werror=stringop-truncation]
>>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
>> (__dest));
>>   |  
>> ^~
>>
>> ... but we apparently really want to do the strncpy here. Silence the
>> warning with QEMU_NONSTRING.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  migration/global_state.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/migration/global_state.c b/migration/global_state.c
>> index 25311479a4..f1355d7d97 100644
>> --- a/migration/global_state.c
>> +++ b/migration/global_state.c
>> @@ -43,9 +43,9 @@ int global_state_store(void)
>>  void global_state_store_running(void)
>>  {
>>  const char *state = RunState_str(RUN_STATE_RUNNING);
>> +QEMU_NONSTRING char *dest = (char *)global_state.runstate;
>>  assert(strlen(state) < sizeof(global_state.runstate));
>> -strncpy((char *)global_state.runstate,
>> -   state, sizeof(global_state.runstate));
>> +strncpy(dest, state, sizeof(global_state.runstate));
>>  }
> 
> Darn, I was sending too fast here, sorry, but seems like this does *not*
> fix the issue with GCC 9.3:
> 
>  https://travis-ci.com/github/huth/qemu/jobs/385871010#L2930
> 
> ... so maybe we should simply switch to strpadcpy() instead?

Yes, and probably do so everywhere that strncpy is used.

Paolo






Re: [PATCH 0/3] qom: Replace INTERFACE_CHECK with OBJECT_CHECK

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/16/20 11:31 PM, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Sep 16, 2020 at 11:35 PM Eduardo Habkost  > wrote:
> 
> This series replaces INTERFACE_CHECK with OBJECT_CHECK because
> both macros are exactly the same.
> 
> The last patch is a new run of the OBJECT_CHECK ->
> DECLARE*_CHECKER* converter script that will convert the former
> INTERFACE_CHECK-based macros.
> 
> 
> Well, at least having a different macro allows to tweak qom
> implementation or replace it with something different more easily.
> 
> I have some wip branch somewhere where I actually made Interface a
> different beast than Object (it was saving some fields, and avoiding
> some potentially wrong casts iirc - I didn't bother to upstream that
> yet). Also I have a different branch where I played with GObject to
> replace qom. In both cases, your proposal would have, or would make, the
> work more complicated.

Considering "wip branch not bothered to upstream" as "fork",
your comment from [*] applies here...

  You can't blame upstream from doing cleanups and modernization, or
  stagnating. Forks are forks, with all the pain they carry. If they
  want to avoid the maintenance cost, they have to do the extra effort
  to get it upstream. This is also a "sneaky way" to remind them that
  effort is better spent in this direction.

[*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg720284.html




Re: Should we apply for GitLab's open source program?

2020-09-17 Thread Paolo Bonzini
On 17/09/20 01:39, Bradley M. Kuhn wrote:
> One thing to note is that my understanding is that most of what you're
> getting access to through this program is proprietary software features that
> GitLab offers as add-ons.

Basically all we need is the increased access to the CI environment (not
just 400 minutes), and none of the add-on features.  Self-hosting would
of course help but we'd have to pay for the hardware resources to run
the CI, and have someone that can keep the hardware running.

Paolo



Re: [PATCH v2] linux-user: Add most IFTUN ioctls

2020-09-17 Thread Shu-Chun Weng
Ping.

On Wed, Aug 5, 2020 at 4:22 PM Shu-Chun Weng  wrote:

> Ping: https://patchew.org/QEMU/20200723231020.769893-1-...@google.com/
>
> On Thu, Jul 23, 2020 at 4:10 PM Shu-Chun Weng  wrote:
>
>> The three options handling `struct sock_fprog` (TUNATTACHFILTER,
>> TUNDETACHFILTER, and TUNGETFILTER) are not implemented. Linux kernel
>> keeps a user space pointer in them which we cannot correctly handle.
>>
>> Signed-off-by: Josh Kunz 
>> Signed-off-by: Shu-Chun Weng 
>> ---
>> v2:
>>   Title changed from "linux-user: Add several IFTUN ioctls"
>>
>>   Properly specify the argument types for various options, including a
>> custom
>>   implementation for TUNSETTXFILTER.
>>
>>   #ifdef guards for macros introduced up to 5 years ago.
>>
>>  linux-user/ioctls.h   | 45 +++
>>  linux-user/syscall.c  | 36 +++
>>  linux-user/syscall_defs.h | 32 
>>  3 files changed, 113 insertions(+)
>>
>> diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
>> index 0713ae1311..b9fb01f558 100644
>> --- a/linux-user/ioctls.h
>> +++ b/linux-user/ioctls.h
>> @@ -593,3 +593,48 @@
>>IOCTL(KCOV_DISABLE, 0, TYPE_NULL)
>>IOCTL(KCOV_INIT_TRACE, IOC_R, TYPE_ULONG)
>>  #endif
>> +
>> +  IOCTL(TUNSETDEBUG, IOC_W, TYPE_INT)
>> +  IOCTL(TUNSETIFF,   IOC_RW, MK_PTR(MK_STRUCT(STRUCT_short_ifreq)))
>> +  IOCTL(TUNSETPERSIST,   IOC_W, TYPE_INT)
>> +  IOCTL(TUNSETOWNER, IOC_W, TYPE_INT)
>> +  IOCTL(TUNSETLINK,  IOC_W, TYPE_INT)
>> +  IOCTL(TUNSETGROUP, IOC_W, TYPE_INT)
>> +  IOCTL(TUNGETFEATURES,  IOC_R, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNSETOFFLOAD,   IOC_W, TYPE_LONG)
>> +  IOCTL_SPECIAL(TUNSETTXFILTER, IOC_W, do_ioctl_TUNSETTXFILTER,
>> +/*
>> + * We can't represent `struct tun_filter` in thunk so
>> leaving
>> + * this empty. do_ioctl_TUNSETTXFILTER will do the
>> conversion.
>> + */
>> +TYPE_NULL)
>> +  IOCTL(TUNGETIFF,   IOC_R, MK_PTR(MK_STRUCT(STRUCT_short_ifreq)))
>> +  IOCTL(TUNGETSNDBUF,IOC_R, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNSETSNDBUF,IOC_W, MK_PTR(TYPE_INT))
>> +  /*
>> +   * TUNATTACHFILTER and TUNDETACHFILTER are not supported. Linux kernel
>> keeps a
>> +   * user pointer in TUNATTACHFILTER, which we are not able to correctly
>> handle.
>> +   */
>> +  IOCTL(TUNGETVNETHDRSZ, IOC_R, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNSETVNETHDRSZ, IOC_W, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNSETQUEUE, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq)))
>> +  IOCTL(TUNSETIFINDEX ,  IOC_W, MK_PTR(TYPE_INT))
>> +  /* TUNGETFILTER is not supported: see TUNATTACHFILTER. */
>> +  IOCTL(TUNSETVNETLE,IOC_W, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNGETVNETLE,IOC_R, MK_PTR(TYPE_INT))
>> +#ifdef TUNSETVNETBE
>> +  IOCTL(TUNSETVNETBE,IOC_W, MK_PTR(TYPE_INT))
>> +  IOCTL(TUNGETVNETBE,IOC_R, MK_PTR(TYPE_INT))
>> +#endif
>> +#ifdef TUNSETSTEERINGEBPF
>> +  IOCTL(TUNSETSTEERINGEBPF, IOC_W, MK_PTR(TYPE_INT))
>> +#endif
>> +#ifdef TUNSETFILTEREBPF
>> +  IOCTL(TUNSETFILTEREBPF, IOC_W, MK_PTR(TYPE_INT))
>> +#endif
>> +#ifdef TUNSETCARRIER
>> +  IOCTL(TUNSETCARRIER,   IOC_W, MK_PTR(TYPE_INT))
>> +#endif
>> +#ifdef TUNGETDEVNETNS
>> +  IOCTL(TUNGETDEVNETNS,  IOC_R, TYPE_NULL)
>> +#endif
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 1211e759c2..7f1efed189 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -56,6 +56,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #ifdef CONFIG_TIMERFD
>> @@ -5422,6 +5423,41 @@ static abi_long do_ioctl_drm(const IOCTLEntry *ie,
>> uint8_t *buf_temp,
>>
>>  #endif
>>
>> +static abi_long do_ioctl_TUNSETTXFILTER(const IOCTLEntry *ie, uint8_t
>> *buf_temp,
>> +int fd, int cmd, abi_long arg)
>> +{
>> +struct tun_filter *filter = (struct tun_filter *)buf_temp;
>> +struct tun_filter *target_filter;
>> +char *target_addr;
>> +
>> +assert(ie->access == IOC_W);
>> +
>> +target_filter = lock_user(VERIFY_READ, arg, sizeof(*filter), 1);
>> +if (!target_filter) {
>> +return -TARGET_EFAULT;
>> +}
>> +filter->flags = tswap16(target_filter->flags);
>> +filter->count = tswap16(target_filter->count);
>> +unlock_user(target_filter, arg, sizeof(*filter));
>> +
>> +if (filter->count) {
>> +if (sizeof(*filter) + filter->count * ETH_ALEN >
>> MAX_STRUCT_SIZE) {
>> +return -TARGET_EFAULT;
>> +}
>> +
>> +target_addr = lock_user(VERIFY_READ, arg + sizeof(*filter),
>> +filter->count * ETH_ALEN, 1);
>> +if (!target_addr) {
>> +return -TARGET_EFAULT;
>> +}
>> +memcpy(filter->addr, target_addr, filter->count * ETH_ALEN);
>> +unlock_user(target_addr, arg + sizeof(*filter),
>> +filter->count * ETH_ALEN);
>> +}
>> +
>> +return get_errno(safe_ioctl(

Re: [PATCH 0/3] qom: Replace INTERFACE_CHECK with OBJECT_CHECK

2020-09-17 Thread Marc-André Lureau
Hi

On Thu, Sep 17, 2020 at 11:19 AM Philippe Mathieu-Daudé 
wrote:

> On 9/16/20 11:31 PM, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Sep 16, 2020 at 11:35 PM Eduardo Habkost  > > wrote:
> >
> > This series replaces INTERFACE_CHECK with OBJECT_CHECK because
> > both macros are exactly the same.
> >
> > The last patch is a new run of the OBJECT_CHECK ->
> > DECLARE*_CHECKER* converter script that will convert the former
> > INTERFACE_CHECK-based macros.
> >
> >
> > Well, at least having a different macro allows to tweak qom
> > implementation or replace it with something different more easily.
> >
> > I have some wip branch somewhere where I actually made Interface a
> > different beast than Object (it was saving some fields, and avoiding
> > some potentially wrong casts iirc - I didn't bother to upstream that
> > yet). Also I have a different branch where I played with GObject to
> > replace qom. In both cases, your proposal would have, or would make, the
> > work more complicated.
>
> Considering "wip branch not bothered to upstream" as "fork",
> your comment from [*] applies here...
>
>   You can't blame upstream from doing cleanups and modernization, or
>   stagnating. Forks are forks, with all the pain they carry. If they
>   want to avoid the maintenance cost, they have to do the extra effort
>   to get it upstream. This is also a "sneaky way" to remind them that
>   effort is better spent in this direction.
>
> [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg720284.html
>
>
Fair enough. Note I didn't nack it, but in general the proposal seems to
blurry some worthy semantic difference between object & interface. Maybe
#define alias INTERFACE_CHECK with OBJECT_CHECK instead ?

-- 
Marc-André Lureau


Re: [PATCH 0/2] Instruction set detection for clang.

2020-09-17 Thread Shu-Chun Weng
Ping.

On Wed, Aug 5, 2020 at 4:23 PM Shu-Chun Weng  wrote:

> Ping: https://patchew.org/QEMU/cover.1595463707.git@google.com/
>
> On Wed, Jul 22, 2020 at 5:27 PM Shu-Chun Weng  wrote:
>
>> Currently when configuring QEMU with clang, AVX2, AVX512F, ATOMIC64, and
>> ATOMIC128 are all disabled because the detection code is GCC-only. With
>> these
>> two patches, I am able to configure, build, and run tests with clang with
>> all of
>> the above enabled.
>>
>> Shu-Chun Weng (2):
>>   configure: avx2 and avx512f detection for clang
>>   configure: atomic64/128 detection for clang
>>
>>  configure   | 34 +++---
>>  util/bufferiszero.c | 33 +++--
>>  2 files changed, 46 insertions(+), 21 deletions(-)
>>
>> --
>> 2.28.0.rc0.105.gf9edc3c819-goog
>>
>>


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH v2 4/8] linux-user: Add IPv6 options to do_print_sockopt()

2020-09-17 Thread Shu-Chun Weng
Ping -- this one was broken off into its own patch from v1 due to the
amount of addition. Hence I did not add Review-by.

On Tue, Aug 11, 2020 at 12:10 AM Shu-Chun Weng  wrote:

> Signed-off-by: Shu-Chun Weng 
> ---
> v1 -> v2:
>   New: Add all IPV6 options to do_print_sockopt(), including the newly
> supported
>   IPV6_ADDR_PREFERENCES.
>
>  linux-user/strace.c | 108 
>  1 file changed, 108 insertions(+)
>
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 854b54a2ad..089fb3968e 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2307,6 +2308,113 @@ print_optint:
>  break;
>  }
>  break;
> +case SOL_IPV6:
> +qemu_log("SOL_IPV6,");
> +switch (optname) {
> +case IPV6_MTU_DISCOVER:
> +qemu_log("IPV6_MTU_DISCOVER,");
> +goto print_optint;
> +case IPV6_MTU:
> +qemu_log("IPV6_MTU,");
> +goto print_optint;
> +case IPV6_V6ONLY:
> +qemu_log("IPV6_V6ONLY,");
> +goto print_optint;
> +case IPV6_RECVPKTINFO:
> +qemu_log("IPV6_RECVPKTINFO,");
> +goto print_optint;
> +case IPV6_UNICAST_HOPS:
> +qemu_log("IPV6_UNICAST_HOPS,");
> +goto print_optint;
> +case IPV6_MULTICAST_HOPS:
> +qemu_log("IPV6_MULTICAST_HOPS,");
> +goto print_optint;
> +case IPV6_MULTICAST_LOOP:
> +qemu_log("IPV6_MULTICAST_LOOP,");
> +goto print_optint;
> +case IPV6_RECVERR:
> +qemu_log("IPV6_RECVERR,");
> +goto print_optint;
> +case IPV6_RECVHOPLIMIT:
> +qemu_log("IPV6_RECVHOPLIMIT,");
> +goto print_optint;
> +case IPV6_2292HOPLIMIT:
> +qemu_log("IPV6_2292HOPLIMIT,");
> +goto print_optint;
> +case IPV6_CHECKSUM:
> +qemu_log("IPV6_CHECKSUM,");
> +goto print_optint;
> +case IPV6_ADDRFORM:
> +qemu_log("IPV6_ADDRFORM,");
> +goto print_optint;
> +case IPV6_2292PKTINFO:
> +qemu_log("IPV6_2292PKTINFO,");
> +goto print_optint;
> +case IPV6_RECVTCLASS:
> +qemu_log("IPV6_RECVTCLASS,");
> +goto print_optint;
> +case IPV6_RECVRTHDR:
> +qemu_log("IPV6_RECVRTHDR,");
> +goto print_optint;
> +case IPV6_2292RTHDR:
> +qemu_log("IPV6_2292RTHDR,");
> +goto print_optint;
> +case IPV6_RECVHOPOPTS:
> +qemu_log("IPV6_RECVHOPOPTS,");
> +goto print_optint;
> +case IPV6_2292HOPOPTS:
> +qemu_log("IPV6_2292HOPOPTS,");
> +goto print_optint;
> +case IPV6_RECVDSTOPTS:
> +qemu_log("IPV6_RECVDSTOPTS,");
> +goto print_optint;
> +case IPV6_2292DSTOPTS:
> +qemu_log("IPV6_2292DSTOPTS,");
> +goto print_optint;
> +case IPV6_TCLASS:
> +qemu_log("IPV6_TCLASS,");
> +goto print_optint;
> +case IPV6_ADDR_PREFERENCES:
> +qemu_log("IPV6_ADDR_PREFERENCES,");
> +goto print_optint;
> +#ifdef IPV6_RECVPATHMTU
> +case IPV6_RECVPATHMTU:
> +qemu_log("IPV6_RECVPATHMTU,");
> +goto print_optint;
> +#endif
> +#ifdef IPV6_TRANSPARENT
> +case IPV6_TRANSPARENT:
> +qemu_log("IPV6_TRANSPARENT,");
> +goto print_optint;
> +#endif
> +#ifdef IPV6_FREEBIND
> +case IPV6_FREEBIND:
> +qemu_log("IPV6_FREEBIND,");
> +goto print_optint;
> +#endif
> +#ifdef IPV6_RECVORIGDSTADDR
> +case IPV6_RECVORIGDSTADDR:
> +qemu_log("IPV6_RECVORIGDSTADDR,");
> +goto print_optint;
> +#endif
> +case IPV6_PKTINFO:
> +qemu_log("IPV6_PKTINFO,");
> +print_pointer(optval, 0);
> +break;
> +case IPV6_ADD_MEMBERSHIP:
> +qemu_log("IPV6_ADD_MEMBERSHIP,");
> +print_pointer(optval, 0);
> +break;
> +case IPV6_DROP_MEMBERSHIP:
> +qemu_log("IPV6_DROP_MEMBERSHIP,");
> +print_pointer(optval, 0);
> +break;
> +default:
> +print_raw_param(TARGET_ABI_FMT_ld, optname, 0);
> +print_pointer(optval, 0);
> +break;
> +}
> +break;
>  default:
>  print_raw_param(TARGET_ABI_FMT_ld, level, 0);
>  print_raw_param(TARGET_ABI_FMT_ld, optname, 0);
> --
> 2.28.0.220.ged08abb693-goog
>
>


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Thomas Huth
On 17/09/2020 09.18, Paolo Bonzini wrote:
> On 17/09/20 08:30, Thomas Huth wrote:
>> On 16/09/2020 19.19, Thomas Huth wrote:
>>> GCC 9.3.0 on Ubuntu complains:
>>>
>>> In file included from /usr/include/string.h:495,
>>>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>>>  from ../migration/global_state.c:13:
>>> In function ‘strncpy’,
>>> inlined from ‘global_state_store_running’ at 
>>> ../migration/global_state.c:47:5:
>>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
>>> ‘__builtin_strncpy’ specified bound 100 equals destination size 
>>> [-Werror=stringop-truncation]
>>>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
>>> (__dest));
>>>   |  
>>> ^~
>>>
>>> ... but we apparently really want to do the strncpy here. Silence the
>>> warning with QEMU_NONSTRING.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>  migration/global_state.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/migration/global_state.c b/migration/global_state.c
>>> index 25311479a4..f1355d7d97 100644
>>> --- a/migration/global_state.c
>>> +++ b/migration/global_state.c
>>> @@ -43,9 +43,9 @@ int global_state_store(void)
>>>  void global_state_store_running(void)
>>>  {
>>>  const char *state = RunState_str(RUN_STATE_RUNNING);
>>> +QEMU_NONSTRING char *dest = (char *)global_state.runstate;
>>>  assert(strlen(state) < sizeof(global_state.runstate));
>>> -strncpy((char *)global_state.runstate,
>>> -   state, sizeof(global_state.runstate));
>>> +strncpy(dest, state, sizeof(global_state.runstate));
>>>  }
>>
>> Darn, I was sending too fast here, sorry, but seems like this does *not*
>> fix the issue with GCC 9.3:
>>
>>  https://travis-ci.com/github/huth/qemu/jobs/385871010#L2930
>>
>> ... so maybe we should simply switch to strpadcpy() instead?
> 
> Yes, and probably do so everywhere that strncpy is used.

I think the trick with QEMU_NONSTRING should work fine in all cases
where we have a real array, see e.g. buf[] in find_vdi_name() in
block/sheepdog.c. It just does not seem to work in case you have a char*
pointer instead of an array...

 Thomas




Re: [PATCH v2 5/8] linux-user: Update SO_TIMESTAMP to SO_TIMESTAMP_OLD/NEW

2020-09-17 Thread Shu-Chun Weng
Ping -- any comments on the four patches start with this?
https://patchew.org/QEMU/cover.1597129029.git@google.com/

On Tue, Aug 11, 2020 at 12:10 AM Shu-Chun Weng  wrote:

> Both guest options map to host SO_TIMESTAMP while keeping a global bit to
> remember if the guest expects the old or the new format. Don't support
> programs mixing two formats.
>
> Added a multiarch test to verify.
>
> Signed-off-by: Shu-Chun Weng 
> ---
> v1 -> v2:
>   Only keep track of old or new format globally, remove support for
> different
>   sockets mixing different formats.
>   Fix style problems.
>
>  linux-user/alpha/sockbits.h|   8 +-
>  linux-user/generic/sockbits.h  |   9 +-
>  linux-user/hppa/sockbits.h |   8 +-
>  linux-user/mips/sockbits.h |   8 +-
>  linux-user/sparc/sockbits.h|   8 +-
>  linux-user/strace.c|   7 +-
>  linux-user/syscall.c   |  91 ++--
>  tests/tcg/multiarch/socket_timestamp.c | 296 +
>  8 files changed, 408 insertions(+), 27 deletions(-)
>  create mode 100644 tests/tcg/multiarch/socket_timestamp.c
>
> diff --git a/linux-user/alpha/sockbits.h b/linux-user/alpha/sockbits.h
> index d54dc98c09..40f0644df0 100644
> --- a/linux-user/alpha/sockbits.h
> +++ b/linux-user/alpha/sockbits.h
> @@ -48,8 +48,6 @@
>  #define TARGET_SO_DETACH_FILTER27
>
>  #define TARGET_SO_PEERNAME  28
> -#define TARGET_SO_TIMESTAMP 29
> -#define TARGET_SCM_TIMESTAMPTARGET_SO_TIMESTAMP
>
>  #define TARGET_SO_PEERSEC   30
>  #define TARGET_SO_PASSSEC   34
> @@ -75,6 +73,12 @@
>  /* Instruct lower device to use last 4-bytes of skb data as FCS */
>  #define TARGET_SO_NOFCS 43
>
> +#define TARGET_SO_TIMESTAMP_OLD29
> +#define TARGET_SCM_TIMESTAMP_OLD   TARGET_SO_TIMESTAMP_OLD
> +
> +#define TARGET_SO_TIMESTAMP_NEW63
> +#define TARGET_SCM_TIMESTAMP_NEW   TARGET_SO_TIMESTAMP_NEW
> +
>  /* TARGET_O_NONBLOCK clashes with the bits used for socket types.
> Therefore we
>   * have to define SOCK_NONBLOCK to a different value here.
>   */
> diff --git a/linux-user/generic/sockbits.h b/linux-user/generic/sockbits.h
> index e44733c601..532cf2d3dc 100644
> --- a/linux-user/generic/sockbits.h
> +++ b/linux-user/generic/sockbits.h
> @@ -49,10 +49,15 @@
>  #define TARGET_SO_DETACH_FILTER27
>
>  #define TARGET_SO_PEERNAME 28
> -#define TARGET_SO_TIMESTAMP29
> -#define TARGET_SCM_TIMESTAMP   TARGET_SO_TIMESTAMP
>
>  #define TARGET_SO_ACCEPTCONN   30
>
>  #define TARGET_SO_PEERSEC  31
> +
> +#define TARGET_SO_TIMESTAMP_OLD29
> +#define TARGET_SCM_TIMESTAMP_OLD   TARGET_SO_TIMESTAMP_OLD
> +
> +#define TARGET_SO_TIMESTAMP_NEW63
> +#define TARGET_SCM_TIMESTAMP_NEW   TARGET_SO_TIMESTAMP_NEW
> +
>  #endif
> diff --git a/linux-user/hppa/sockbits.h b/linux-user/hppa/sockbits.h
> index 23f69a3293..284a47e74e 100644
> --- a/linux-user/hppa/sockbits.h
> +++ b/linux-user/hppa/sockbits.h
> @@ -29,8 +29,6 @@
>  #define TARGET_SO_BSDCOMPAT0x400e
>  #define TARGET_SO_PASSCRED 0x4010
>  #define TARGET_SO_PEERCRED 0x4011
> -#define TARGET_SO_TIMESTAMP0x4012
> -#define TARGET_SCM_TIMESTAMP   TARGET_SO_TIMESTAMP
>  #define TARGET_SO_TIMESTAMPNS  0x4013
>  #define TARGET_SCM_TIMESTAMPNS TARGET_SO_TIMESTAMPNS
>
> @@ -67,6 +65,12 @@
>
>  #define TARGET_SO_CNX_ADVICE   0x402E
>
> +#define TARGET_SO_TIMESTAMP_OLD0x4012
> +#define TARGET_SCM_TIMESTAMP_OLD   TARGET_SO_TIMESTAMP_OLD
> +
> +#define TARGET_SO_TIMESTAMP_NEW0x4038
> +#define TARGET_SCM_TIMESTAMP_NEW   TARGET_SO_TIMESTAMP_NEW
> +
>  /* TARGET_O_NONBLOCK clashes with the bits used for socket types.
> Therefore we
>   * have to define SOCK_NONBLOCK to a different value here.
>   */
> diff --git a/linux-user/mips/sockbits.h b/linux-user/mips/sockbits.h
> index 0f022cd598..b4c39d9588 100644
> --- a/linux-user/mips/sockbits.h
> +++ b/linux-user/mips/sockbits.h
> @@ -61,14 +61,18 @@
>  #define TARGET_SO_DETACH_FILTER27
>
>  #define TARGET_SO_PEERNAME 28
> -#define TARGET_SO_TIMESTAMP29
> -#define SCM_TIMESTAMP  SO_TIMESTAMP
>
>  #define TARGET_SO_PEERSEC  30
>  #define TARGET_SO_SNDBUFFORCE  31
>  #define TARGET_SO_RCVBUFFORCE  33
>  #define TARGET_SO_PASSSEC  34
>
> +#define TARGET_SO_TIMESTAMP_OLD29
> +#define TARGET_SCM_TIMESTAMP_OLD   TARGET_SO_TIMESTAMP_OLD
> +
> +#define TARGET_SO_TIMESTAMP_NEW63
> +#define TARGET_SCM_TIMESTAMP_NEW   TARGET_SO_TIMESTAMP_NEW
> +
>  /** sock_type - Socket types
>   *
>   * Please notice that for binary compat reasons MIPS has to
> diff --git a/linux-user/sparc/sockbits.h b/linux-user/sparc/sockbits.h
> index 0a822e3e1f..07440efd14 100644
> --- a/linux-user/sparc/sockbits.h
> +++ b/linux-user/sparc/sockbits.h
> @@ -48,8 +48,6 @@
>  #define TARGET_SO_GET_FILTER   TA

Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions

2020-09-17 Thread Zhenyu Ye
Hi Stefan,

On 2020/9/14 21:27, Stefan Hajnoczi wrote:
>>
>> Theoretically, everything running in an iothread is asynchronous. However,
>> some 'asynchronous' actions are not non-blocking entirely, such as
>> io_submit().  This will block while the iodepth is too big and I/O pressure
>> is too high.  If we do some qmp actions, such as 'info block', at this time,
>> may cause vm soft lockup.  This series can make these qmp actions safer.
>>
>> I constructed the scene as follow:
>> 1. create a vm with 4 disks, using iothread.
>> 2. add press to the CPU on the host.  In my scene, the CPU usage exceeds 95%.
>> 3. add press to the 4 disks in the vm at the same time.  I used the fio and
>> some parameters are:
>>
>>   fio -rw=randrw -bs=1M -size=1G -iodepth=512 -ioengine=libaio -numjobs=4
>>
>> 4. do block query actions, for example, by virsh:
>>
>>  virsh qemu-monitor-command [vm name] --hmp info block
>>
>> Then the vm will soft lockup, the calltrace is:
>>
>> [  192.311393] watchdog: BUG: soft lockup - CPU#1 stuck for 42s! 
>> [kworker/1:1:33]
> 
> Hi,
> Sorry I haven't had time to investigate this myself yet.
> 
> Do you also have a QEMU backtrace when the hang occurs?
> 
> Let's find out if QEMU is stuck in the io_submit(2) syscall or whether
> there's an issue in QEMU itself that causes the softlockup (for example,
> aio_poll() with the global mutex held).

Sorry for the delay.

I traced the io_submit() within the guest. The maximum execution time exceeds 
16s:

guest# perf trace -p `pidof -s fio` --duration 1
14.808 (3843.082 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
  3861.336 (11470.608 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 15341.998 (479.283 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 15831.380 (3704.997 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 19547.869 (3412.839 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 22966.953 (1080.854 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 24062.689 (6939.813 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 31019.219 (532.147 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 31556.610 (3469.920 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 35038.885 (9007.175 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 44053.578 (16006.405 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 60068.944 (3068.748 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
 63138.474 (13012.499 ms): io_getevents(ctx_id: 281472924459008, 
min_nr: 511, nr: 511, events: 0x19a83150) = 511
 76191.073 (2872.657 ms): io_submit(ctx_id: 281472924459008, nr: 1, 
iocbpp: 0x19a87160  ) = 1
...

And in the host, the information of sys_enter_io_submit() is:

Samples: 3K of event 'syscalls:sys_enter_io_submit', Event count 
(approx.): 3150
Children  Self  Trace output
-   66.70%66.70%  ctx_id: 0x9c044000, nr: 0x0001, iocbpp: 
0x9f7fad28
0xae7f871c
0xae8a27c4
qemu_thread_start
iothread_run
aio_poll
aio_dispatch_ready_handlers
aio_dispatch_handler
virtio_queue_host_notifier_aio_read
virtio_queue_notify_aio_vq
virtio_blk_data_plane_handle_output
virtio_blk_handle_vq
blk_io_unplug
bdrv_io_unplug
bdrv_io_unplug
raw_aio_unplug
laio_io_unplug
syscall


When the hang occurs, the QEMU is blocked at:

#0  0x95762b64 in ?? () from target:/usr/lib64/libpthread.so.0
#1  0x9575bd88 in pthread_mutex_lock () from 
target:/usr/lib64/libpthread.so.0
#2  0xbb1f5948 in qemu_mutex_lock_impl (mutex=0xcc8e1860,
file=0xbb4e1bd0 
"/Images/eillon/CODE/5-opensource/qemu/util/async.c", line=605)
#3  0xbb20acd4 in aio_context_acquire (ctx=0xcc8e1800)
#4  0xbb105e90 in bdrv_query_image_info (bs=0xcc934620,
p_info=0xccc41e18, errp=0xca669118)
#5  0xbb105968 in bdrv_block_device_info (blk=0xcdca19f0, 
bs=0xcc934620,
flat=false, errp=0xca6692b8)
#6  0xbb1063dc in bdrv_query_info (blk=0xcdca19f0, 
p_info=0xcd29c9a8,
errp=0xca6692b8)
#7  0xbb106c14 in qmp_query_block (errp=0x0)
#8  0xbacb8e6c in hmp_info_block (mon=0xca6693d0, 
qdict=0xcd089790)
#9  0xbb0068f0 in handle_hmp_command (mon=0xca6693d0,
cmdline

Re: [PATCH v2 2/2] qom: Use DECLARE_INTERFACE_CHECKER macro

2020-09-17 Thread Cédric Le Goater
On 9/17/20 4:49 AM, Eduardo Habkost wrote:
> Mechanical search/replace to use the new
> DECLARE_INTERFACE_CHECKER macro instead of manually defining
> macros using INTERFACE_CHECK.
> 
> Acked-by: David Gibson 
> Signed-off-by: Eduardo Habkost 
> ---
> This is an alternative to the patches submitted at
> https://lore.kernel.org/qemu-devel/20200916193101.511600-3-ehabk...@redhat.com/
> https://lore.kernel.org/qemu-devel/20200916193101.511600-4-ehabk...@redhat.com/
> ---
> Changes v1 -> v2:
> * Build fix: move declarations after typedef

Would it be possible to move the typedef in the DECLARE_INTERFACE_CHECKER 
macro ? 

C.

> 
> ---
> Cc: "Michael S. Tsirkin" 
> Cc: Igor Mammedov 
> Cc: Corey Minyard 
> Cc: "Cédric Le Goater" 
> Cc: David Gibson 
> Cc: "Hervé Poussineau" 
> Cc: "Edgar E. Iglesias" 
> Cc: Juan Quintela 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Paolo Bonzini 
> Cc: "Daniel P. Berrangé" 
> Cc: Eduardo Habkost 
> Cc: Stefan Berger 
> Cc: Peter Maydell 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-...@nongnu.org
> Signed-off-by: Eduardo Habkost 
> ---
>  include/hw/acpi/acpi_dev_interface.h |  7 +++
>  include/hw/arm/linux-boot-if.h   |  6 +++---
>  include/hw/fw-path-provider.h|  6 +++---
>  include/hw/hotplug.h |  6 +++---
>  include/hw/intc/intc.h   |  7 +++
>  include/hw/ipmi/ipmi.h   |  6 +++---
>  include/hw/isa/isa.h |  4 ++--
>  include/hw/mem/memory-device.h   |  6 +++---
>  include/hw/nmi.h |  6 +++---
>  include/hw/ppc/pnv_xscom.h   |  4 ++--
>  include/hw/ppc/spapr_irq.h   |  4 ++--
>  include/hw/ppc/xics.h|  4 ++--
>  include/hw/ppc/xive.h| 12 ++--
>  include/hw/rdma/rdma.h   |  7 +++
>  include/hw/rtc/m48t59.h  |  6 +++---
>  include/hw/stream.h  |  6 +++---
>  include/hw/vmstate-if.h  |  6 +++---
>  include/qom/object_interfaces.h  |  7 +++
>  include/sysemu/tpm.h |  6 +++---
>  target/arm/idau.h|  6 +++---
>  tests/check-qom-interface.c  |  6 +++---
>  21 files changed, 62 insertions(+), 66 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi_dev_interface.h 
> b/include/hw/acpi/acpi_dev_interface.h
> index 9adf1e4706..58bf64052d 100644
> --- a/include/hw/acpi/acpi_dev_interface.h
> +++ b/include/hw/acpi/acpi_dev_interface.h
> @@ -21,11 +21,10 @@ typedef enum {
>  typedef struct AcpiDeviceIfClass AcpiDeviceIfClass;
>  DECLARE_CLASS_CHECKERS(AcpiDeviceIfClass, ACPI_DEVICE_IF,
> TYPE_ACPI_DEVICE_IF)
> -#define ACPI_DEVICE_IF(obj) \
> - INTERFACE_CHECK(AcpiDeviceIf, (obj), \
> - TYPE_ACPI_DEVICE_IF)
> -
>  typedef struct AcpiDeviceIf AcpiDeviceIf;
> +DECLARE_INTERFACE_CHECKER(AcpiDeviceIf, ACPI_DEVICE_IF,
> +  TYPE_ACPI_DEVICE_IF)
> +
>  
>  void acpi_send_event(DeviceState *dev, AcpiEventStatusBits event);
>  
> diff --git a/include/hw/arm/linux-boot-if.h b/include/hw/arm/linux-boot-if.h
> index c85f33b2c5..17b8083f95 100644
> --- a/include/hw/arm/linux-boot-if.h
> +++ b/include/hw/arm/linux-boot-if.h
> @@ -12,10 +12,10 @@
>  typedef struct ARMLinuxBootIfClass ARMLinuxBootIfClass;
>  DECLARE_CLASS_CHECKERS(ARMLinuxBootIfClass, ARM_LINUX_BOOT_IF,
> TYPE_ARM_LINUX_BOOT_IF)
> -#define ARM_LINUX_BOOT_IF(obj) \
> -INTERFACE_CHECK(ARMLinuxBootIf, (obj), TYPE_ARM_LINUX_BOOT_IF)
> -
>  typedef struct ARMLinuxBootIf ARMLinuxBootIf;
> +DECLARE_INTERFACE_CHECKER(ARMLinuxBootIf, ARM_LINUX_BOOT_IF,
> +  TYPE_ARM_LINUX_BOOT_IF)
> +
>  
>  struct ARMLinuxBootIfClass {
>  /*< private >*/
> diff --git a/include/hw/fw-path-provider.h b/include/hw/fw-path-provider.h
> index 8e1d45651c..639fe9d821 100644
> --- a/include/hw/fw-path-provider.h
> +++ b/include/hw/fw-path-provider.h
> @@ -25,10 +25,10 @@
>  typedef struct FWPathProviderClass FWPathProviderClass;
>  DECLARE_CLASS_CHECKERS(FWPathProviderClass, FW_PATH_PROVIDER,
> TYPE_FW_PATH_PROVIDER)
> -#define FW_PATH_PROVIDER(obj) \
> - INTERFACE_CHECK(FWPathProvider, (obj), TYPE_FW_PATH_PROVIDER)
> -
>  typedef struct FWPathProvider FWPathProvider;
> +DECLARE_INTERFACE_CHECKER(FWPathProvider, FW_PATH_PROVIDER,
> +  TYPE_FW_PATH_PROVIDER)
> +
>  
>  struct FWPathProviderClass {
>  InterfaceClass parent_class;
> diff --git a/include/hw/hotplug.h b/include/hw/hotplug.h
> index e15f59c8b3..5dc7435a4c 100644
> --- a/include/hw/hotplug.h
> +++ b/include/hw/hotplug.h
> @@ -19,10 +19,10 @@
>  typedef struct HotplugHandlerClass HotplugHandlerClass;
>  DECLARE_CLASS_CHECKERS(HotplugHandlerClass, HOTPLUG_HANDLER,
> TYPE_HOTPLUG_HANDLER)
> -#define HOTPLUG_HANDLER(obj) \
> - INTERFACE_CHECK(HotplugHandler, (obj), TYPE_HOTPLUG_HANDLER)
> -
>  typedef struct HotplugHandler HotplugHand

Re: [SPAM] Re: [PATCH 14/15] spapr: Simplify error handling in spapr_memory_plug()

2020-09-17 Thread Markus Armbruster
David Gibson  writes:

> On Tue, Sep 15, 2020 at 01:43:40PM +0200, Greg Kurz wrote:
>> On Tue, 15 Sep 2020 13:58:53 +0300
>> Vladimir Sementsov-Ogievskiy  wrote:
>> 
>> > 14.09.2020 15:35, Greg Kurz wrote:
>> > > As recommended in "qapi/error.h", add a bool return value to
>> > > spapr_add_lmbs() and spapr_add_nvdimm(), and use them instead
>> > > of local_err in spapr_memory_plug().
>> > > 
>> > > Since object_property_get_uint() only returns 0 on failure, use
>> > > that as well.
>> > 
>> > Why are you sure? Can't the property be 0 itself?
>> > 
>> 
>> Hmmm... I've based this assumption on the header:
>> 
>>  * Returns: the value of the property, converted to an unsigned integer, or 0
>>  * an error occurs (including when the property value is not an integer).
>> 
>> but looking at the implementation, I don't see any check that
>> a property cannot be 0 indeed...
>
> Yeah, indeed I'm pretty sure it can.

Correct.

Corollary: you can't use to return value to check for failure, except
when you know the property cannot be zero (you commonly don't).

The function predates our (rather late) realization that returning a
recognizable error value in addition to setting an error leads to more
readable code.  Today, we'd perhaps do it the way you describe below.

>> It's a bit misleading to mention this in the header though. I
>> understand that the function should return something, which
>> should have a some explicitly assigned value to avoid compilers
>> or static analyzers to yell, but the written contract should be
>> that the value is _undefined_ IMHO.
>
> Hrm... I think the description could be clearer, but returning 0
> explicitly on the failure case has some benefits too.  If 0 is a
> reasonable default for when the property isn't present (which is a
> plausibly common case) then it means you can just get a value and
> ignore errors.

Matter of taste.

There's no shortage of _undefined_ in C...

>> In its present form, the only way to know if the property is
>> valid is to pass a non-NULL errp actually. I'd rather even see
>> that in the contract, and an assert() in the code.
>
> Maybe... see above.

If you think the contract could be improved, please post a patch.

What assertion do you have in mind?  If it's adding assert(errp) to
object_property_get_uint(), I'll object.  Functions should not place
additional restrictions on @errp arguments without a compelling reason.

>> An alternative would be to convert it to have a bool return
>> value and get the actual uint result with a pointer argument.
>
> I don't think this is a good idea.  Returning success/failure as the
> return value is a good rule of thumb because it reduces the amount of
> checking of out-of-band information you need to do.  If you move to
> returning the actual value you're trying to get out of band in this
> sense, it kind of defeats that purpose.
>
> I think this one is a case where it is reasonable to make it required
> to explicitly check the error value.

If almost all calls assign the value to a variable, like

val = object_property_get_uint(obj, name, &err);
if (err) {
error_propagate(errp, err)
... bail out ...
}
... use val ...

then the alternative Greg proposed is easier on the eyes:

if (!object_property_get_uint(obj, name, &val, errp)) {
... bail out ...
}
... use val ...

It isn't for calls that use the value without storing it in a variable
first.

>> > > Also call ERRP_GUARD() to be able to check the status of void
>> > > function pc_dimm_plug() with *errp.
>> 
>> I'm now hesitating to either check *errp for object_property_get_uint()
>> too or simply drop this patch...




Re: Why QEMU translates one instruction to a TB?

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/17/20 8:25 AM, casmac wrote:
> Hi all,
> ?0?2?0?2 ?0?2 We try to add DSP architecure to QEMU 4.2. To load the COFF 
> format
> object file, we have added loader code to load content from
> ?0?2 the object file. The rom_add_blob() function is used. We firstly
> analyze the COFF file to figure out which sections are chained
> ?0?2 together(so each chain forms a "memory blob"), and then allocate the
> memory blobs.
> ?0?2
> ?0?2 The psuedo code looks like:
> ?0?2
> ?0?2?0?2?0?2 ?0?2 ?0?2 ?0?2 for(i=0; i ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 if(ary_sect_chain[i].exist) ?0?2 //there is a 
> chain of sections
> to allocate
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 {
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ary_sect_chain[i].mem_region = 
> g_new(MemoryRegion, 1);
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 memory_region_init_ram(...);
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 memory_region_add_subregion(sysmem, 
> );
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 rom_add_blob();
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 }
> ?0?2 ?0?2 ?0?2?0?2 ?0?2 }

Why do this silly mapping when you know your DSP memory map?

> --
> ok.lds file:
> 
> MEMORY ?0?2 /* MEMORY directive */
> {
> ?0?2 ?0?2 ROM:?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2 ?0?2 origin = 00h?0?2 
> ?0?2 length = 001000h?0?2?0?2 ?0?2 /* 4K
> 32-bit words on-chip ROM (C31/VC33) */

Per the TI spru031f datasheet, this is external (there is no
on-chip ROM).

I have my doubts there is actually a ROM mapped here...
Is this linkscript used to *test* a BIOS written in SRAM by
some JTAG?

> ?0?2 ?0?2 /* 256K 32-bit word off-chip SRAM (D.Module.VC33-150-S2) */
> ?0?2 ?0?2 BIOS:?0?2?0?2?0?2?0?2 ?0?2 origin = 001000h?0?2?0?2?0?2 ?0?2 length 
> = 000300h
> ?0?2 ?0?2 CONF_UTL: ?0?2 origin = 001300h?0?2?0?2?0?2 ?0?2 length = 000800h
> ?0?2 ?0?2 FREE:?0?2?0?2?0?2?0?2 ?0?2 origin = 001B00h?0?2?0?2?0?2 ?0?2 length 
> = 03F500h?0?2 /* 259328 32-bit
> words */
> ?0?2 ?0?2 RAM_0_1:?0?2?0?2 ?0?2 origin = 809800h?0?2 ?0?2 length = 
> 000800h?0?2?0?2 ?0?2 /* 2 x 1K
> 32-bit word on-chip SRAM (C31/VC33) */
> ?0?2 ?0?2 RAM_2_3:?0?2?0?2 ?0?2 origin = 80h?0?2 ?0?2 length = 
> 008000h?0?2?0?2 ?0?2 /* 2 x 16K
> 32-bit word on-chip SRAM (VC33 only) */
> }

You probably want to use:

  memory_region_init_ram(&s->extsram, OBJECT(dev), "eSRAM",
 256 * KiB, &error_fatal);
  memory_region_add_subregion(get_system_memory(),
  0x00, &s->extsram);

  memory_region_init_ram(&s->ocsram, OBJECT(dev), "iSRAM",
 2 * KiB, &error_fatal);
  memory_region_add_subregion(get_system_memory(),
  0x809800, &s->ocsram);

Then different areas of the object file will be loaded into
the either the iSRAM or the eSRAM.



[PATCH v2] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Thomas Huth
GCC 9.3.0 on Ubuntu complains:

In file included from /usr/include/string.h:495,
 from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
 from ../migration/global_state.c:13:
In function ‘strncpy’,
inlined from ‘global_state_store_running’ at 
../migration/global_state.c:47:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
 ‘__builtin_strncpy’ specified bound 100 equals destination size 
[-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
  |  ^~

... but we apparently really want to do a strncpy here - the size is already
checked with the assert() statement right in front of it. To silence the
warning, simply replace it with our strpadcpy() function.

Signed-off-by: Thomas Huth 
---
 v2: Use strpadcpy instead of QEMU_NONSTRING (and yes, this time it seems
 to really silence the compiler warning :-))

 migration/global_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/migration/global_state.c b/migration/global_state.c
index 25311479a4..a33947ca32 100644
--- a/migration/global_state.c
+++ b/migration/global_state.c
@@ -44,8 +44,8 @@ void global_state_store_running(void)
 {
 const char *state = RunState_str(RUN_STATE_RUNNING);
 assert(strlen(state) < sizeof(global_state.runstate));
-strncpy((char *)global_state.runstate,
-   state, sizeof(global_state.runstate));
+strpadcpy((char *)global_state.runstate, sizeof(global_state.runstate),
+  state, '\0');
 }
 
 bool global_state_received(void)
-- 
2.18.2




Re: [PATCH 3/5] qom: Remove module_obj_name parameter from OBJECT_DECLARE* macros

2020-09-17 Thread Cédric Le Goater
On 9/16/20 8:25 PM, Eduardo Habkost wrote:
> One of the goals of having less boilerplate on QOM declarations
> is to avoid human error.  Requiring an extra argument that is
> never used is an opportunity for mistakes.
> 
> Remove the unused argument from OBJECT_DECLARE_TYPE and
> OBJECT_DECLARE_SIMPLE_TYPE.
> 
> Coccinelle patch used to convert all users of the macros:
> 
>   @@
>   declarer name OBJECT_DECLARE_TYPE;
>   identifier InstanceType, ClassType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_TYPE(InstanceType, ClassType,
>   -lowercase,
>UPPERCASE);
> 
>   @@
>   declarer name OBJECT_DECLARE_SIMPLE_TYPE;
>   identifier InstanceType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_SIMPLE_TYPE(InstanceType,
>   -lowercase,
>UPPERCASE);
> 
> Signed-off-by: Eduardo Habkost 

For the ppc part,

Reviewed-by: Cédric Le Goater 



> ---
> Cc: "Marc-André Lureau" 
> Cc: Gerd Hoffmann 
> Cc: "Michael S. Tsirkin" 
> Cc: "Daniel P. Berrangé" 
> Cc: Peter Maydell 
> Cc: Corey Minyard 
> Cc: "Cédric Le Goater" 
> Cc: David Gibson 
> Cc: Cornelia Huck 
> Cc: Thomas Huth 
> Cc: Halil Pasic 
> Cc: Christian Borntraeger 
> Cc: "Philippe Mathieu-Daudé" 
> Cc: Alistair Francis 
> Cc: David Hildenbrand 
> Cc: Laurent Vivier 
> Cc: Amit Shah 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: Paolo Bonzini 
> Cc: Eduardo Habkost 
> Cc: Fam Zheng 
> Cc: "Gonglei (Arei)" 
> Cc: Igor Mammedov 
> Cc: Stefan Berger 
> Cc: Richard Henderson 
> Cc: Michael Rolnik 
> Cc: Sarah Harris 
> Cc: "Edgar E. Iglesias" 
> Cc: Michael Walle 
> Cc: Aleksandar Markovic 
> Cc: Aurelien Jarno 
> Cc: Jiaxun Yang 
> Cc: Aleksandar Rikalo 
> Cc: Anthony Green 
> Cc: Chris Wulff 
> Cc: Marek Vasut 
> Cc: Stafford Horne 
> Cc: Palmer Dabbelt 
> Cc: Sagar Karandikar 
> Cc: Bastian Koppelmann 
> Cc: Yoshinori Sato 
> Cc: Mark Cave-Ayland 
> Cc: Artyom Tarasenko 
> Cc: Guan Xuetao 
> Cc: Max Filippov 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-s3...@nongnu.org
> Cc: qemu-bl...@nongnu.org
> Cc: xen-de...@lists.xenproject.org
> Cc: qemu-ri...@nongnu.org
> ---
>  hw/audio/intel-hda.h| 2 +-
>  hw/display/virtio-vga.h | 2 +-
>  include/authz/base.h| 2 +-
>  include/authz/list.h| 2 +-
>  include/authz/listfile.h| 2 +-
>  include/authz/pamacct.h | 2 +-
>  include/authz/simple.h  | 2 +-
>  include/crypto/secret_common.h  | 2 +-
>  include/crypto/secret_keyring.h | 2 +-
>  include/hw/arm/armsse.h | 2 +-
>  include/hw/hyperv/vmbus.h   | 2 +-
>  include/hw/i2c/i2c.h| 2 +-
>  include/hw/i2c/smbus_slave.h| 2 +-
>  include/hw/ipack/ipack.h| 2 +-
>  include/hw/ipmi/ipmi.h  | 2 +-
>  include/hw/mem/pc-dimm.h| 2 +-
>  include/hw/ppc/pnv.h| 2 +-
>  include/hw/ppc/pnv_core.h   | 2 +-
>  include/hw/ppc/pnv_homer.h  | 2 +-
>  include/hw/ppc/pnv_occ.h| 2 +-
>  include/hw/ppc/pnv_psi.h| 2 +-
>  include/hw/ppc/pnv_xive.h   | 2 +-
>  include/hw/ppc/spapr_cpu_core.h | 2 +-
>  include/hw/ppc/spapr_vio.h  | 2 +-
>  include/hw/ppc/xics.h   | 2 +-
>  include/hw/ppc/xive.h   | 2 +-
>  include/hw/s390x/event-facility.h   | 2 +-
>  include/hw/s390x/s390_flic.h| 2 +-
>  include/hw/s390x/sclp.h | 2 +-
>  include/hw/sd/sd.h  | 2 +-
>  include/hw/ssi/ssi.h| 2 +-
>  include/hw/sysbus.h | 2 +-
>  include/hw/virtio/virtio-gpu.h  | 2 +-
>  include/hw/virtio/virtio-input.h| 2 +-
>  include/hw/virtio/virtio-mem.h  | 2 +-
>  include/hw/virtio/virtio-pmem.h | 2 +-
>  include/hw/virtio/virtio-serial.h   | 2 +-
>  include/hw/xen/xen-bus.h| 2 +-
>  include/io/channel.h| 2 +-
>  include/io/dns-resolver.h   | 2 +-
>  include/io/net-listener.h   | 2 +-
>  include/qom/object.h| 6 ++
>  include/scsi/pr-manager.h   | 2 +-
>  include/sysemu/cryptodev.h  | 2 +-
>  include/sysemu/hostmem.h| 2 +-
>  include/sysemu/rng.h| 2 +-
>  include/sysemu/tpm_backend.h| 2 +-
>  include/sysemu/vhost-user-backend.h | 2 +-
>  target/alpha/cpu-qom.h  | 2 +-
>  target/arm/cpu-qom.h| 2 +-
>  target/avr/cpu-qom.h| 2 +-
>  target/cris/cpu-qom.h   | 2 +-
>  target/hppa/cpu-qom.h   | 2 +-
>  target/i386/cpu-qom.h   | 2 +-
>  target/lm32/cpu-qom.h   | 2 +-
>  target/m68k/cpu-qom.h   | 2 +-
>  target/microblaze/cpu-qom.h | 2 +-
>  target/mips/cpu-qom.h   | 2 +-
>  target/moxie/cpu.h  | 2 +-
>  target/nios2/cpu.h  | 2 +-
>  target/openrisc/c

Re: [PATCH 04/37] qapi: move generator entrypoint into module

2020-09-17 Thread Markus Armbruster
John Snow  writes:

> On 9/16/20 7:54 AM, Markus Armbruster wrote:
>> John Snow  writes:
>> 
>>> As part of delinting and adding type hints to the QAPI generator, it's
>>> helpful for the entrypoint to be part of the module, only leaving a very
>>> tiny entrypoint shim outside of the module.
>>>
>>> As a result, all of the include statements are reworked to be module-aware,
>>> as explicit relative imports.
>> Should this be split into two commits, one for each of the
>> paragraphs
>> above?
>> 
>
> Hmm ... I hadn't considered it was possible, but actually ... I guess
> I can split those out, yeah.
>
>> PEP 8 recommends absolute imports, with one exception:
>>  However, explicit relative imports are an acceptable
>> alternative to
>>  absolute imports, especially when dealing with complex package
>>  layouts where using absolute imports would be unnecessarily verbose:
>>  from . import sibling
>>  from .sibling import example
>>  Standard library code should avoid complex package layouts and
>>  always use absolute imports.
>> Do you think it covers your use of relative imports?
>> 
>
> Admittedly I am going by trial and error; my experience is that the
> relative imports behave the nicest.
>
> There is a historical fear of explicit relative imports because they
> are "new" and years of Python2 compatibility

Having to struggle with that for years was bound to damage brains.

>  rendered many afraid of
> them. It is advice safely ignored in my opinion.
>
> Using absolute imports (e.g. from qapi.sibling import foo) gets messy
> in virtual environments when you have *installed* the module in
> question: it becomes ambiguous as to *which* qapi you meant: the one
> in this folder, or the one installed to the environment?
>
> Python, mypy, pylint, flake8 etc disagree sometimes, or can get
> confused; thinking there are two copies of each module.
>
> Just my experience that relative imports seem to give me the least trouble.
>
>>> This is done primarily for the benefit of python tooling (pylint, mypy,
>>> flake8, et al) which otherwise has trouble consistently resolving
>>> "qapi.x" to mean "a sibling file in this folder."
>> Can you give me an example of some tool having troube?
>> 
>
> I'd have to code up some examples. I have some hobby code unrelated to
> QEMU where I struggled to get flake8, mypy, and pylint all cooperating 
> with an import regime until I gave up and used explicit relative imports.

I'd make the switch when we actually do run into trouble.

But I'm willing to take your advice and switch now.

[...]




Re: Why QEMU translates one instruction to a TB?

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/17/20 8:25 AM, casmac wrote:
> Hi all,
> ?0?2?0?2 ?0?2 We try to add DSP architecure to QEMU 4.2. To load the COFF 
> format
> object file, we have added loader code to load content from
> ?0?2 the object file. 
[...]

> ?0?2 ?0?2 The COFF loader works functionally, but we then found that sometimes
> QEMU is down-graded - it treats each instruction as one TB. In version
> 4.2,?0?2 debugging shows
> that get_page_addr_code_host() from accel/tcg/cputlb.c returns -1, as
> shown below.
> 
> accel/tcg/cputlb.c:
> tb_page_addr_t get_page_addr_code_hostp(CPUArchState *env, target_ulong
> addr,
> ?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2
>  ?0?2 void **hostp)
> {
> ?0?2 ?0?2 uintptr_t mmu_idx = cpu_mmu_index(env, true);
> ?0?2 ?0?2 uintptr_t index = tlb_index(env, mmu_idx, addr);
> ?0?2 ?0?2 CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr);
> ?0?2 ?0?2 void *p;
> 
> ?0?2 ?0?2 //.
> ?0?2 ?0?2 if (unlikely(entry->addr_code & TLB_MMIO)) {
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 /* The region is not backed by RAM.?0?2 */
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 if (hostp) {
> ?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2 ?0?2 *hostp = NULL;
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 }
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 return -1;?0?2 ?0?2 ?0?2 ?0?2 /* debugging falls to 
> this branch, after this
> point QEMU translate one instruction to a TB?0?2 */
> ?0?2 ?0?2 }
> ?0?2 ?0?2 //...
> }?0?2 ?0?2
> 
> ?0?2 ?0?2 One intresting fact is that this somehow depends on the linker
> command file. The object file generated by the following linker command
> file(per_instr.lds)
> will "trigger" the problem. But QEMU work well with the object file
> linked by the other linker command file (ok.lds).
> ?0?2 ?0?2 What cause get_page_addr_code_hostp() function to return -1? I have
> no clue at all. Any advise is appreciated!!

Maybe the "execute from small-MMU-region RAM" problem?

See:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg549660.html



Re: [PATCH v2] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/17/20 9:43 AM, Thomas Huth wrote:
> GCC 9.3.0 on Ubuntu complains:
> 
> In file included from /usr/include/string.h:495,
>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>  from ../migration/global_state.c:13:
> In function ‘strncpy’,
> inlined from ‘global_state_store_running’ at 
> ../migration/global_state.c:47:5:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
>  ‘__builtin_strncpy’ specified bound 100 equals destination size 
> [-Werror=stringop-truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
>   |  
> ^~
> 
> ... but we apparently really want to do a strncpy here - the size is already
> checked with the assert() statement right in front of it. To silence the
> warning, simply replace it with our strpadcpy() function.
> 
> Signed-off-by: Thomas Huth 
> ---
>  v2: Use strpadcpy instead of QEMU_NONSTRING (and yes, this time it seems
>  to really silence the compiler warning :-))
> 
>  migration/global_state.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/global_state.c b/migration/global_state.c
> index 25311479a4..a33947ca32 100644
> --- a/migration/global_state.c
> +++ b/migration/global_state.c
> @@ -44,8 +44,8 @@ void global_state_store_running(void)
>  {
>  const char *state = RunState_str(RUN_STATE_RUNNING);
>  assert(strlen(state) < sizeof(global_state.runstate));
> -strncpy((char *)global_state.runstate,
> -   state, sizeof(global_state.runstate));
> +strpadcpy((char *)global_state.runstate, sizeof(global_state.runstate),
> +  state, '\0');

https://www.mail-archive.com/qemu-block@nongnu.org/msg44925.html
;)

>  }
>  
>  bool global_state_received(void)
> 




[PATCH v6 01/12] tests/acpi: mark addition of table DSDT.roothp for unit testing root pci hotplug

2020-09-17 Thread Ani Sinha
A new binary acpi table tests/data/acpi/pc/DSDT.roothp is added in order to
unit test the feature flag that can disable/enable root pci bus hotplug on
i440fx. This feature was added with the commit:
3d7e78aaf0 ("Introduce a new flag for i440fx to disable PCI hotplug on
the root bus")

This change documents the fact that this new file addition was made as a part
of the unit test change.

Signed-off-by: Ani Sinha 
Reviewed-by: Igor Mammedov 
---
 tests/qtest/bios-tables-test-allowed-diff.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..ac864fc982 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,2 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/DSDT.roothp",
-- 
2.17.1




[PATCH v6 02/12] tests/acpi: add new unit test to test hotplug off/on feature on the root pci bus

2020-09-17 Thread Ani Sinha
Ability to turn hotplug off on the pci root bus for i440fx was added in commit:
3d7e78aaf0 ("Introduce a new flag for i440fx to disable PCI hotplug on the
root bus")

This change adds a unit test in order to test this feature.

Signed-off-by: Ani Sinha 
Reviewed-by: Igor Mammedov 
---
 tests/qtest/bios-tables-test.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 504b810af5..ad157ef05d 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -740,6 +740,20 @@ static void test_acpi_piix4_tcg_bridge(void)
 free_test_data(&data);
 }
 
+static void test_acpi_piix4_no_root_hotplug(void)
+{
+test_data data;
+
+memset(&data, 0, sizeof(data));
+data.machine = MACHINE_PC;
+data.variant = ".roothp";
+data.required_struct_types = base_required_struct_types;
+data.required_struct_types_len = ARRAY_SIZE(base_required_struct_types);
+test_acpi_one("-global PIIX4_PM.acpi-root-pci-hotplug=off "
+  "-device pci-bridge,chassis_nr=1", &data);
+free_test_data(&data);
+}
+
 static void test_acpi_q35_tcg(void)
 {
 test_data data;
@@ -1144,6 +1158,8 @@ int main(int argc, char *argv[])
 qtest_add_func("acpi/q35/tpm-tis", test_acpi_q35_tcg_tpm_tis);
 qtest_add_func("acpi/piix4", test_acpi_piix4_tcg);
 qtest_add_func("acpi/piix4/bridge", test_acpi_piix4_tcg_bridge);
+qtest_add_func("acpi/piix4/pci-hotplug/no_root_hotplug",
+   test_acpi_piix4_no_root_hotplug);
 qtest_add_func("acpi/q35", test_acpi_q35_tcg);
 qtest_add_func("acpi/q35/bridge", test_acpi_q35_tcg_bridge);
 qtest_add_func("acpi/q35/mmio64", test_acpi_q35_tcg_mmio64);
-- 
2.17.1




Re: [PATCH 3/5] qom: Remove module_obj_name parameter from OBJECT_DECLARE* macros

2020-09-17 Thread Cornelia Huck
On Wed, 16 Sep 2020 14:25:17 -0400
Eduardo Habkost  wrote:

> One of the goals of having less boilerplate on QOM declarations
> is to avoid human error.  Requiring an extra argument that is
> never used is an opportunity for mistakes.
> 
> Remove the unused argument from OBJECT_DECLARE_TYPE and
> OBJECT_DECLARE_SIMPLE_TYPE.
> 
> Coccinelle patch used to convert all users of the macros:
> 
>   @@
>   declarer name OBJECT_DECLARE_TYPE;
>   identifier InstanceType, ClassType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_TYPE(InstanceType, ClassType,
>   -lowercase,
>UPPERCASE);
> 
>   @@
>   declarer name OBJECT_DECLARE_SIMPLE_TYPE;
>   identifier InstanceType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_SIMPLE_TYPE(InstanceType,
>   -lowercase,
>UPPERCASE);
> 
> Signed-off-by: Eduardo Habkost 

Acked-by: Cornelia Huck 




[PATCH v6 03/12] tests/acpi: add a new ACPI table in order to test root pci hotplug on/off

2020-09-17 Thread Ani Sinha
A new binary ACPI table tests/data/acpi/pc/DSDT.roothp is added in order
to unit test hotplug on/off capability on the root pci bus for i440fx.
The diff between the table DSDT.bridge and DSDT.roothp is listed below:

@@ -1,30 +1,30 @@
 /*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20180105 (64-bit version)
  * Copyright (c) 2000 - 2018 Intel Corporation
  *
  * Disassembling to symbolic ASL+ operators
  *
- * Disassembly of tests/data/acpi/pc/DSDT.bridge, Fri Sep 11 22:51:04 2020
+ * Disassembly of /tmp/aml-UGIHQ0, Fri Sep 11 22:51:04 2020
  *
  * Original Table Header:
  * Signature"DSDT"
- * Length   0x1A89 (6793)
+ * Length   0x140A (5130)
  * Revision 0x01  32-bit table (V1), no 64-bit math support
- * Checksum 0x09
+ * Checksum 0xE6
  * OEM ID   "BOCHS "
  * OEM Table ID "BXPCDSDT"
  * OEM Revision 0x0001 (1)
  * Compiler ID  "BXPC"
  * Compiler Version 0x0001 (1)
  */
 DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPCDSDT", 0x0001)
 {
 Scope (\)
 {
 OperationRegion (DBG, SystemIO, 0x0402, One)
 Field (DBG, ByteAcc, NoLock, Preserve)
 {
 DBGB,   8
 }

@@ -831,61 +831,60 @@
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
 IO (Decode16,
 0x0510, // Range Minimum
 0x0510, // Range Maximum
 0x01,   // Alignment
 0x0C,   // Length
 )
 })
 }
 }

 Scope (\_SB)
 {
 Scope (PCI0)
 {
-Name (BSEL, Zero)
 Device (S00)
 {
 Name (_ADR, Zero)  // _ADR: Address
 }

 Device (S10)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 Method (_S1D, 0, NotSerialized)  // _S1D: S1 Device State
 {
 Return (Zero)
 }

 Method (_S2D, 0, NotSerialized)  // _S2D: S2 Device State
 {
 Return (Zero)
 }

 Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
 {
 Return (Zero)
 }
 }

 Device (S18)
 {
 Name (_ADR, 0x0003)  // _ADR: Address
-Name (BSEL, One)
+Name (BSEL, Zero)
 Device (S00)
 {
 Name (_SUN, Zero)  // _SUN: Slot User Number
 Name (_ADR, Zero)  // _ADR: Address
 Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
 {
 PCEJ (BSEL, _SUN)
 }
 }

 Device (S08)
 {
 Name (_SUN, One)  // _SUN: Slot User Number
 Name (_ADR, 0x0001)  // _ADR: Address
 Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
 {
@@ -1345,456 +1344,30 @@
 Notify (SE8, Arg1)
 }

 If ((Arg0 & 0x4000))
 {
 Notify (SF0, Arg1)
 }

 If ((Arg0 & 0x8000))
 {
 Notify (SF8, Arg1)
 }
 }

 Method (PCNT, 0, NotSerialized)
 {
-BNUM = One
+BNUM = Zero
 DVNT (PCIU, One)
 DVNT (PCID, 0x03)
 }
 }

-Device (S20)
-{
-Name (_SUN, 0x04)  // _SUN: Slot User Number
-Name (_ADR, 0x0004)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S28)
-{
-Name (_SUN, 0x05)  // _SUN: Slot User Number
-Name (_ADR, 0x0005)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S30)
-{
-Name (_SUN, 0x06)  // _SUN: Slot User Number
-Name (_ADR, 0x0006)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S38)
-{
-Name (_SUN, 0x07)  // _SUN: Slot User Number
- 

Re: [PATCH 2/5] qom: Remove ParentClassType argument from OBJECT_DECLARE_SIMPLE_TYPE

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/16/20 8:25 PM, Eduardo Habkost wrote:
> The requirement to specify the parent class type makes the macro
> harder to use and easy to misuse (silent bugs can be introduced
> if the wrong struct type is specified).
> 
> Simplify the macro by just not declaring any class struct,
> allowing us to remove the class_size field from the TypeInfo
> variables for those types.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Cc: "Daniel P. Berrangé" 
> Cc: "Marc-André Lureau" 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: Eduardo Habkost 
> Cc: Gerd Hoffmann 
> Cc: qemu-devel@nongnu.org
> ---
>  include/authz/list.h|  2 +-
>  include/authz/listfile.h|  2 +-
>  include/authz/pamacct.h |  2 +-
>  include/authz/simple.h  |  2 +-
>  include/crypto/secret_keyring.h |  2 +-
>  include/io/dns-resolver.h   |  2 +-
>  include/io/net-listener.h   |  2 +-
>  include/qom/object.h| 16 
>  include/sysemu/vhost-user-backend.h |  2 +-
>  authz/list.c|  1 -
>  authz/listfile.c|  1 -
>  authz/pamacct.c |  1 -
>  authz/simple.c  |  1 -
>  backends/dbus-vmstate.c |  3 +--
>  backends/vhost-user.c   |  1 -
>  crypto/secret_keyring.c |  1 -
>  io/dns-resolver.c   |  1 -
>  io/net-listener.c   |  1 -
>  ui/input-barrier.c  |  3 +--
>  ui/input-linux.c|  3 +--
>  20 files changed, 19 insertions(+), 30 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 




[PATCH v6 04/12] Fix a gap where acpi_pcihp_find_hotplug_bus() returns a non-hotpluggable bus

2020-09-17 Thread Ani Sinha
When ACPI hotplug for the root bus is disabled, the bsel property for that
bus is not set. Please see the following commit:

3d7e78aaf ("Introduce a new flag for i440fx to disable PCI hotplug on the
root bus").

As a result, when acpi_pcihp_find_hotplug_bus() is called
with bsel set to 0, it may return the root bus. This can cause devices
attached to the root bus to get hot-unplugged if the user issues the following
set of commmands:

outl 0xae10 0
outl 0xae08 your_slot

Thanks to Julia for pointing this out here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg734548.html

In this patch, we fix the issue in this function by checking if the bus which
is returned by the function is actually hotpluggable. If not, we simply return
NULL. This avoids the scenario where we were returning a non-hotpluggable bus.

Signed-off-by: Ani Sinha 
Reviewed-by: Igor Mammedov 
---
 hw/acpi/pcihp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 39b1f74442..32ae8b2c0a 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -147,6 +147,21 @@ static PCIBus *acpi_pcihp_find_hotplug_bus(AcpiPciHpState 
*s, int bsel)
 if (!bsel && !find.bus) {
 find.bus = s->root;
 }
+
+/*
+ * Check if find.bus is actually hotpluggable. If bsel is set to
+ * NULL for example on the root bus in order to make it
+ * non-hotpluggable, find.bus will match the root bus when bsel
+ * is 0. See acpi_pcihp_test_hotplug_bus() above. Since the
+ * bus is not hotpluggable however, we should not select the bus.
+ * Instead, we should set find.bus to NULL in that case. In the check
+ * below, we generalize this case for all buses, not just the root bus.
+ * The callers of this function check for a null return value and
+ * handle them appropriately.
+ */
+if (find.bus && !qbus_is_hotpluggable(BUS(find.bus))) {
+find.bus = NULL;
+}
 return find.bus;
 }
 
-- 
2.17.1




[PATCH v6 00/12] i440fx/acpi: addition of feature and bug fixes.

2020-09-17 Thread Ani Sinha
In v6:
- added Acked-by and Reviewed-by for additional patches
- checked 80 col/line limit for commit logs.
- s/amls/acpi code in commit log
- split acpi binary gold master table blobs for q35 into a separate patch
  (hence 12 patch series as opposed to 11).
 

Ani Sinha (12):
  tests/acpi: mark addition of table DSDT.roothp for unit testing root
pci hotplug
  tests/acpi: add new unit test to test hotplug off/on feature on the
root pci bus
  tests/acpi: add a new ACPI table in order to test root pci hotplug
on/off
  Fix a gap where acpi_pcihp_find_hotplug_bus() returns a
non-hotpluggable bus
  i440fx/acpi: do not add hotplug related amls for cold plugged bridges
  tests/acpi: list added acpi table binary file for pci bridge hotplug
test
  tests/acpi: unit test for 'acpi-pci-hotplug-with-bridge-support'
bridge flag
  tests/acpi: add newly added acpi DSDT table blob for pci bridge
hotplug flag
  piix4: don't reserve hw resources when hotplug is off globally
  tests/acpi: update golden master DSDT binary table blobs for q35
  tests/acpi: unit test exercising global pci hotplug off for i440fx
  tests/acpi: add DSDT.hpbrroot DSDT table blob to test global i440fx
hotplug

 hw/acpi/pcihp.c   |  15 +
 hw/acpi/piix4.c   |   6 ++--
 hw/i386/acpi-build.c  |  37 ++
 tests/data/acpi/pc/DSDT.hpbridge  | Bin 0 -> 4895 bytes
 tests/data/acpi/pc/DSDT.hpbrroot  | Bin 0 -> 2953 bytes
 tests/data/acpi/pc/DSDT.roothp| Bin 0 -> 5130 bytes
 tests/data/acpi/q35/DSDT  | Bin 7678 -> 7670 bytes
 tests/data/acpi/q35/DSDT.acpihmat | Bin 9002 -> 8994 bytes
 tests/data/acpi/q35/DSDT.bridge   | Bin 7695 -> 7688 bytes
 tests/data/acpi/q35/DSDT.cphp | Bin 8141 -> 8133 bytes
 tests/data/acpi/q35/DSDT.dimmpxm  | Bin 9331 -> 9323 bytes
 tests/data/acpi/q35/DSDT.ipmibt   | Bin 7753 -> 7745 bytes
 tests/data/acpi/q35/DSDT.memhp| Bin 9037 -> 9029 bytes
 tests/data/acpi/q35/DSDT.mmio64   | Bin 8808 -> 8801 bytes
 tests/data/acpi/q35/DSDT.numamem  | Bin 7684 -> 7676 bytes
 tests/data/acpi/q35/DSDT.tis  | Bin 8283 -> 8276 bytes
 tests/qtest/bios-tables-test.c|  49 ++
 17 files changed, 92 insertions(+), 15 deletions(-)
 create mode 100644 tests/data/acpi/pc/DSDT.hpbridge
 create mode 100644 tests/data/acpi/pc/DSDT.hpbrroot
 create mode 100644 tests/data/acpi/pc/DSDT.roothp

-- 
2.17.1




[PATCH v6 08/12] tests/acpi: add newly added acpi DSDT table blob for pci bridge hotplug flag

2020-09-17 Thread Ani Sinha
This patch adds a binary blob corresponding to the DSDT acpi table. It is used
to unit test the flag 'acpi-pci-hotplug-with-bridge-support' used with pci
bridges.

This change also clears the file tests/qtest/bios-tables-test-allowed-diff.h
so that future changes which affect the table can be caught.

The following is the diff between files tests/data/acpi/pc/DSDT.bridge and
tests/data/acpi/pc/DSDT.hpbridge after disassembly :

@@ -1,30 +1,30 @@
 /*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20180105 (64-bit version)
  * Copyright (c) 2000 - 2018 Intel Corporation
  *
  * Disassembling to symbolic ASL+ operators
  *
- * Disassembly of tests/data/acpi/pc/DSDT.bridge, Fri Sep 11 23:21:34 2020
+ * Disassembly of /tmp/aml-7UURQ0, Fri Sep 11 23:21:34 2020
  *
  * Original Table Header:
  * Signature"DSDT"
- * Length   0x1A89 (6793)
+ * Length   0x131F (4895)
  * Revision 0x01  32-bit table (V1), no 64-bit math support
- * Checksum 0x09
+ * Checksum 0xF9
  * OEM ID   "BOCHS "
  * OEM Table ID "BXPCDSDT"
  * OEM Revision 0x0001 (1)
  * Compiler ID  "BXPC"
  * Compiler Version 0x0001 (1)
  */
 DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPCDSDT", 0x0001)
 {
 Scope (\)
 {
 OperationRegion (DBG, SystemIO, 0x0402, One)
 Field (DBG, ByteAcc, NoLock, Preserve)
 {
 DBGB,   8
 }

@@ -859,522 +859,32 @@
 }

 Method (_S2D, 0, NotSerialized)  // _S2D: S2 Device State
 {
 Return (Zero)
 }

 Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
 {
 Return (Zero)
 }
 }

 Device (S18)
 {
 Name (_ADR, 0x0003)  // _ADR: Address
-Name (BSEL, One)
-Device (S00)
-{
-Name (_SUN, Zero)  // _SUN: Slot User Number
-Name (_ADR, Zero)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S08)
-{
-Name (_SUN, One)  // _SUN: Slot User Number
-Name (_ADR, 0x0001)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S10)
-{
-Name (_SUN, 0x02)  // _SUN: Slot User Number
-Name (_ADR, 0x0002)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S18)
-{
-Name (_SUN, 0x03)  // _SUN: Slot User Number
-Name (_ADR, 0x0003)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S20)
-{
-Name (_SUN, 0x04)  // _SUN: Slot User Number
-Name (_ADR, 0x0004)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S28)
-{
-Name (_SUN, 0x05)  // _SUN: Slot User Number
-Name (_ADR, 0x0005)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S30)
-{
-Name (_SUN, 0x06)  // _SUN: Slot User Number
-Name (_ADR, 0x0006)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S38)
-{
-Name (_SUN, 0x07)  // _SUN: Slot User Number
-Name (_ADR, 0x0007)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
-}
-
-Device (S40)
-{
-Name (_SUN, 0x08)  // _SUN: Slo

[PATCH v6 05/12] i440fx/acpi: do not add hotplug related amls for cold plugged bridges

2020-09-17 Thread Ani Sinha
Cold plugged bridges are not hot unpluggable, even when their hotplug
property (acpi-pci-hotplug-with-bridge-support) is turned off. Please see
the function acpi_pcihp_pc_no_hotplug(). However, with
the current implementaton, Windows would try to hot-unplug a pci bridge when
it's hotplug switch is off. This is regardless of whether there are devices
attached to the bridge since we add ACPI code like _EJ0 etc for the
pci slot where the bridge is cold plugged.

In this fix, we identify a cold plugged bridge and for cold plugged bridges,
we do not add the appropriate acpi methods that are used by the OS
to identify a hot-pluggable/unpluggable pci device. After this change, Windows
does not detect the cold plugged pci bridge as ejectable.

As a result of the patch, the following are the changes to the DSDT ACPI
table:

@@ -858,38 +858,33 @@
 Return (Zero)
 }

 Method (_S2D, 0, NotSerialized)  // _S2D: S2 Device State
 {
 Return (Zero)
 }

 Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
 {
 Return (Zero)
 }
 }

 Device (S18)
 {
-Name (_SUN, 0x03)  // _SUN: Slot User Number
 Name (_ADR, 0x0003)  // _ADR: Address
-Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
-{
-PCEJ (BSEL, _SUN)
-}
 }

 Device (S20)
 {
 Name (_SUN, 0x04)  // _SUN: Slot User Number
 Name (_ADR, 0x0004)  // _ADR: Address
 Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
 {
 PCEJ (BSEL, _SUN)
 }
 }

 Device (S28)
 {
 Name (_SUN, 0x05)  // _SUN: Slot User Number
 Name (_ADR, 0x0005)  // _ADR: Address
@@ -1148,37 +1143,32 @@
 PCEJ (BSEL, _SUN)
 }
 }

 Device (SF8)
 {
 Name (_SUN, 0x1F)  // _SUN: Slot User Number
 Name (_ADR, 0x001F)  // _ADR: Address
 Method (_EJ0, 1, NotSerialized)  // _EJx: Eject Device
 {
 PCEJ (BSEL, _SUN)
 }
 }

 Method (DVNT, 2, NotSerialized)
 {
-If ((Arg0 & 0x08))
-{
-Notify (S18, Arg1)
-}
-
 If ((Arg0 & 0x10))
 {
 Notify (S20, Arg1)
 }

 If ((Arg0 & 0x20))
 {
 Notify (S28, Arg1)
 }

 If ((Arg0 & 0x40))
 {
 Notify (S30, Arg1)
 }

 If ((Arg0 & 0x80))

While at it, I have also updated a stale comment.

Signed-off-by: Ani Sinha 
Suggested-by: Julia Suvorova 
Reviewed-by: Julia Suvorova 
Reviewed-by: Igor Mammedov 
---
 hw/i386/acpi-build.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 7a5a8b3521..e079b686f5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -359,6 +359,7 @@ static void build_append_pci_bus_devices(Aml *parent_scope, 
PCIBus *bus,
 int slot = PCI_SLOT(i);
 bool hotplug_enabled_dev;
 bool bridge_in_acpi;
+bool cold_plugged_bridge;
 
 if (!pdev) {
 if (bsel) { /* add hotplug slots for non present devices */
@@ -380,15 +381,14 @@ static void build_append_pci_bus_devices(Aml 
*parent_scope, PCIBus *bus,
 pc = PCI_DEVICE_GET_CLASS(pdev);
 dc = DEVICE_GET_CLASS(pdev);
 
-/* When hotplug for bridges is enabled, bridges are
- * described in ACPI separately (see build_pci_bus_end).
- * In this case they aren't themselves hot-pluggable.
+/*
+ * Cold plugged bridges aren't themselves hot-pluggable.
  * Hotplugged bridges *are* hot-pluggable.
  */
-bridge_in_acpi = pc->is_bridge && pcihp_bridge_en &&
-!DEVICE(pdev)->hotplugged;
+cold_plugged_bridge = pc->is_bridge && !DEVICE(pdev)->hotplugged;
+bridge_in_acpi =  cold_plugged_bridge && pcihp_bridge_en;
 
-hotplug_enabled_dev = bsel && dc->hotpluggable && !bridge_in_acpi;
+hotplug_enabled_dev = bsel && dc->hotpluggable && !cold_plugged_bridge;
 
 if (pc->class_id == PCI_CLASS_BRIDGE_ISA) {
 continue;
-- 
2.17.1




Re: [PATCH 4/5] [automated] Use OBJECT_DECLARE_TYPE when possible

2020-09-17 Thread Cédric Le Goater
On 9/16/20 8:25 PM, Eduardo Habkost wrote:
> This converts existing DECLARE_OBJ_CHECKERS usage to
> OBJECT_DECLARE_TYPE when possible.
> 
>  $ ./scripts/codeconverter/converter.py -i \
>--pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')
> 
> Signed-off-by: Eduardo Habkost 

For the aspeed part,

Reviewed-by: Cédric Le Goater 


> ---
> Cc: Peter Maydell 
> Cc: Andrzej Zaborowski 
> Cc: Alistair Francis 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> Cc: Mark Cave-Ayland 
> Cc: David Gibson 
> Cc: Richard Henderson 
> Cc: David Hildenbrand 
> Cc: Cornelia Huck 
> Cc: Thomas Huth 
> Cc: Halil Pasic 
> Cc: Christian Borntraeger 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: Fam Zheng 
> Cc: Dmitry Fleytman 
> Cc: Gerd Hoffmann 
> Cc: "Marc-André Lureau" 
> Cc: "Cédric Le Goater" 
> Cc: Andrew Jeffery 
> Cc: Joel Stanley 
> Cc: Andrew Baumann 
> Cc: "Philippe Mathieu-Daudé" 
> Cc: Eric Auger 
> Cc: Eduardo Habkost 
> Cc: Marcel Apfelbaum 
> Cc: Laurent Vivier 
> Cc: Sergio Lopez 
> Cc: John Snow 
> Cc: Xiao Guangrong 
> Cc: Peter Chubb 
> Cc: "Daniel P. Berrangé" 
> Cc: Beniamino Galvani 
> Cc: "Edgar E. Iglesias" 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: Jason Wang 
> Cc: qemu-...@nongnu.org
> Cc: qemu-devel@nongnu.org
> Cc: qemu-bl...@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: qemu-s3...@nongnu.org
> Cc: xen-de...@lists.xenproject.org
> ---
>  hw/ppc/e500.h | 5 +
>  hw/s390x/ccw-device.h | 4 +---
>  hw/s390x/virtio-ccw.h | 5 +
>  hw/usb/ccid.h | 5 +
>  hw/usb/hcd-dwc2.h | 3 +--
>  hw/usb/hcd-ehci.h | 5 +
>  hw/virtio/virtio-pci.h| 5 +
>  include/chardev/char.h| 4 +---
>  include/hw/arm/aspeed_soc.h   | 5 +
>  include/hw/arm/bcm2836.h  | 5 +
>  include/hw/arm/smmu-common.h  | 5 +
>  include/hw/arm/smmuv3.h   | 5 +
>  include/hw/arm/virt.h | 5 +
>  include/hw/boards.h   | 3 +--
>  include/hw/display/macfb.h| 5 +
>  include/hw/gpio/aspeed_gpio.h | 5 +
>  include/hw/i2c/aspeed_i2c.h   | 5 +
>  include/hw/i386/ioapic_internal.h | 5 +
>  include/hw/i386/microvm.h | 5 +
>  include/hw/i386/pc.h  | 4 +---
>  include/hw/i386/x86-iommu.h   | 5 +
>  include/hw/i386/x86.h | 5 +
>  include/hw/ide/internal.h | 4 +---
>  include/hw/input/adb.h| 4 +---
>  include/hw/isa/i8259_internal.h   | 5 +
>  include/hw/isa/isa.h  | 4 +---
>  include/hw/mem/nvdimm.h   | 5 +
>  include/hw/misc/aspeed_scu.h  | 5 +
>  include/hw/misc/aspeed_sdmc.h | 5 +
>  include/hw/misc/imx_ccm.h | 5 +
>  include/hw/misc/mos6522.h | 5 +
>  include/hw/pci-host/pnv_phb4.h| 5 +
>  include/hw/pci/pci.h  | 4 +---
>  include/hw/pci/pci_host.h | 4 +---
>  include/hw/pcmcia.h   | 5 +
>  include/hw/ppc/spapr.h| 5 +
>  include/hw/qdev-core.h| 4 +---
>  include/hw/rtc/allwinner-rtc.h| 5 +
>  include/hw/s390x/3270-ccw.h   | 5 +
>  include/hw/s390x/s390-virtio-ccw.h| 5 +
>  include/hw/s390x/storage-attributes.h | 5 +
>  include/hw/s390x/storage-keys.h   | 5 +
>  include/hw/s390x/tod.h| 5 +
>  include/hw/scsi/scsi.h| 4 +---
>  include/hw/sd/allwinner-sdhost.h  | 5 +
>  include/hw/sd/sd.h| 5 +
>  include/hw/ssi/aspeed_smc.h   | 5 +
>  include/hw/ssi/xilinx_spips.h | 4 +---
>  include/hw/timer/aspeed_timer.h   | 5 +
>  include/hw/timer/i8254.h  | 5 +
>  include/hw/usb.h  | 4 +---
>  include/hw/virtio/virtio.h| 4 +---
>  include/hw/watchdog/wdt_aspeed.h  | 5 +
>  include/hw/xen/xen-block.h| 4 +---
>  include/hw/xen/xen-bus.h  | 4 +---
>  include/net/can_host.h| 5 +
>  include/net/filter.h  | 4 +---
>  include/ui/console.h  | 4 +---
>  hw/arm/mps2-tz.c  | 5 +
>  hw/arm/mps2.c | 5 +
>  hw/arm/musca.c| 5 +
>  hw/arm/spitz.c| 5 +
>  hw/arm/vexpress.c | 5 +
>  hw/block/m25p80.c | 5 +
>  hw/input/adb-kbd.c| 5 +
>  hw/input/adb-mouse.c  | 5 +
>  hw/misc/tmp421.c  | 5 +
>  hw/scsi/scsi-disk.c   | 5 +
>  hw/scsi/vmw_pvscsi.c  | 5 +
>  69 files changed, 69 insertions(+), 255 deletions(-)
> 
> diff --git a/hw/ppc/e500.h b/hw/p

[PATCH v6 07/12] tests/acpi: unit test for 'acpi-pci-hotplug-with-bridge-support' bridge flag

2020-09-17 Thread Ani Sinha
This change adds a new unit test for the global flag
'acpi-pci-hotplug-with-bridge-support' which is available for cold plugged pci
bridges in i440fx. The flag can be used to turn off acpi based hotplug support
on all pci bridges.

Signed-off-by: Ani Sinha 
Reviewed-by: Igor Mammedov 
---
 tests/qtest/bios-tables-test.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index ad157ef05d..c970556795 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -754,6 +754,20 @@ static void test_acpi_piix4_no_root_hotplug(void)
 free_test_data(&data);
 }
 
+static void test_acpi_piix4_no_bridge_hotplug(void)
+{
+test_data data;
+
+memset(&data, 0, sizeof(data));
+data.machine = MACHINE_PC;
+data.variant = ".hpbridge";
+data.required_struct_types = base_required_struct_types;
+data.required_struct_types_len = ARRAY_SIZE(base_required_struct_types);
+test_acpi_one("-global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off "
+  "-device pci-bridge,chassis_nr=1", &data);
+free_test_data(&data);
+}
+
 static void test_acpi_q35_tcg(void)
 {
 test_data data;
@@ -1160,6 +1174,8 @@ int main(int argc, char *argv[])
 qtest_add_func("acpi/piix4/bridge", test_acpi_piix4_tcg_bridge);
 qtest_add_func("acpi/piix4/pci-hotplug/no_root_hotplug",
test_acpi_piix4_no_root_hotplug);
+qtest_add_func("acpi/piix4/pci-hotplug/no_bridge_hotplug",
+   test_acpi_piix4_no_bridge_hotplug);
 qtest_add_func("acpi/q35", test_acpi_q35_tcg);
 qtest_add_func("acpi/q35/bridge", test_acpi_q35_tcg_bridge);
 qtest_add_func("acpi/q35/mmio64", test_acpi_q35_tcg_mmio64);
-- 
2.17.1




[PATCH v6 06/12] tests/acpi: list added acpi table binary file for pci bridge hotplug test

2020-09-17 Thread Ani Sinha
The file 'tests/data/acpi/pc/DSDT.hpbridge' is a newly added acpi table file
for testing the pci bridge option 'acpi-pci-hotplug-with-bridge-support' under
i440fx. This change documents this fact.

Signed-off-by: Ani Sinha 
Reviewed-by: Igor Mammedov 
---
 tests/qtest/bios-tables-test-allowed-diff.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..96a9237355 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,2 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/DSDT.hpbridge",
-- 
2.17.1




[PATCH V3 01/10] qemu/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the folder.

Signed-off-by: zhaolichang 
Reviewed-by: Alex Bennee 
---
 Changelog   | 2 +-
 accel/tcg/user-exec.c   | 2 +-
 audio/audio.c   | 2 +-
 block.c | 2 +-
 configure   | 2 +-
 fsdev/virtfs-proxy-helper.c | 2 +-
 hmp-commands.hx | 2 +-
 libdecnumber/decNumber.c| 2 +-
 qemu-img.c  | 2 +-
 qobject/qdict.c | 2 +-
 scsi/pr-manager-helper.c| 2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Changelog b/Changelog
index 4a90bb9e8b..f7e178ccc0 100644
--- a/Changelog
+++ b/Changelog
@@ -241,7 +241,7 @@ version 0.8.0:
 version 0.7.2:
 
   - x86_64 fixes (Win2000 and Linux 2.6 boot in 32 bit)
-  - merge self modifying code handling in dirty ram page mecanism.
+  - merge self modifying code handling in dirty ram page mechanism.
   - MIPS fixes (Ralf Baechle)
   - better user net performances
 
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index bb039eb32d..5c96819ded 100644
--- a/accel/tcg/user-exec.c
+++ b/accel/tcg/user-exec.c
@@ -88,7 +88,7 @@ static inline int handle_cpu_signal(uintptr_t pc, siginfo_t 
*info,
  * use that value directly.  Within cpu_restore_state_from_tb, we
  * assume PC comes from GETPC(), as used by the helper functions,
  * so we adjust the address by -GETPC_ADJ to form an address that
- * is within the call insn, so that the address does not accidentially
+ * is within the call insn, so that the address does not accidentally
  * match the beginning of the next guest insn.  However, when the
  * pc comes from the signal frame it points to the actual faulting
  * host memory insn and not the return from a call insn.
diff --git a/audio/audio.c b/audio/audio.c
index ce8c6dec5f..1a68cfaafb 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1674,7 +1674,7 @@ static AudioState *audio_init(Audiodev *dev, const char 
*name)
 head = audio_handle_legacy_opts();
 /*
  * In case of legacy initialization, all Audiodevs in the list will 
have
- * the same configuration (except the driver), so it does't matter 
which
+ * the same configuration (except the driver), so it doesn't matter 
which
  * one we chose.  We need an Audiodev to set up AudioState before we 
can
  * init a driver.  Also note that dev at this point is still in the
  * list.
diff --git a/block.c b/block.c
index 9538af4884..11ab55f80b 100644
--- a/block.c
+++ b/block.c
@@ -2602,7 +2602,7 @@ static void bdrv_replace_child_noperm(BdrvChild *child,
 
 /*
  * Updates @child to change its reference to point to @new_bs, including
- * checking and applying the necessary permisson updates both to the old node
+ * checking and applying the necessary permission updates both to the old node
  * and to @new_bs.
  *
  * NULL is passed as @new_bs for removing the reference before freeing @child.
diff --git a/configure b/configure
index ce27eafb0a..c74d79bfbc 100755
--- a/configure
+++ b/configure
@@ -3411,7 +3411,7 @@ EOF
 xfs="yes"
   else
 if test "$xfs" = "yes" ; then
-  feature_not_found "xfs" "Instal xfsprogs/xfslibs devel"
+  feature_not_found "xfs" "Install xfsprogs/xfslibs devel"
 fi
 xfs=no
   fi
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index de061a8a0e..15c0e79b06 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -518,7 +518,7 @@ static void statfs_to_prstatfs(ProxyStatFS *pr_stfs, struct 
statfs *stfs)
 
 /*
  * Gets stat/statfs information and packs in out_iovec structure
- * on success returns number of bytes packed in out_iovec struture
+ * on success returns number of bytes packed in out_iovec structure
  * otherwise returns -errno
  */
 static int do_stat(int type, struct iovec *iovec, struct iovec *out_iovec)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 60f395c276..27c4bbe0f2 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1267,7 +1267,7 @@ ERST
 },
 SRST
 ``drive_backup``
-  Start a point-in-time copy of a block device to a specificed target.
+  Start a point-in-time copy of a block device to a specified target.
 ERST
 
 {
diff --git a/libdecnumber/decNumber.c b/libdecnumber/decNumber.c
index 8c197023f4..1ffe458ad8 100644
--- a/libdecnumber/decNumber.c
+++ b/libdecnumber/decNumber.c
@@ -5626,7 +5626,7 @@ static const uShort LNnn[90] = {
 /*would certainly save at least one if it were made ten times */
 /*bigger, too (for truncated fractions 0.100 through 0.999).  */
 /*However, for most practical evaluations, at least four or five  */
-/*iterations will be neede -- so this would only speed up by  */
+/*iterations will be needed -- so this would only speed 

[PATCH v6 11/12] tests/acpi: unit test exercising global pci hotplug off for i440fx

2020-09-17 Thread Ani Sinha
This change adds a unit test to exercise the case when hotplug is disabled
both for pci root bus and the pci bridges by passing the following two
switches to qemu:

  -global PIIX4_PM.acpi-root-pci-hotplug=off
  -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off

bios-tables-test-allowed-diff.h documents the fact that a new DSDT acpi gold
master binary blob we need to be added to test this. We will do the actual
addition in the next patch in the series.

Signed-off-by: Ani Sinha 
---
 tests/qtest/bios-tables-test-allowed-diff.h |  1 +
 tests/qtest/bios-tables-test.c  | 17 +
 2 files changed, 18 insertions(+)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..dea61d94f1 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,2 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/DSDT.hpbrroot",
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index c970556795..3f7f1a8107 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -768,6 +768,21 @@ static void test_acpi_piix4_no_bridge_hotplug(void)
 free_test_data(&data);
 }
 
+static void test_acpi_piix4_no_acpi_pci_hotplug(void)
+{
+test_data data;
+
+memset(&data, 0, sizeof(data));
+data.machine = MACHINE_PC;
+data.variant = ".hpbrroot";
+data.required_struct_types = base_required_struct_types;
+data.required_struct_types_len = ARRAY_SIZE(base_required_struct_types);
+test_acpi_one("-global PIIX4_PM.acpi-root-pci-hotplug=off "
+  "-global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off "
+  "-device pci-bridge,chassis_nr=1", &data);
+free_test_data(&data);
+}
+
 static void test_acpi_q35_tcg(void)
 {
 test_data data;
@@ -1176,6 +1191,8 @@ int main(int argc, char *argv[])
test_acpi_piix4_no_root_hotplug);
 qtest_add_func("acpi/piix4/pci-hotplug/no_bridge_hotplug",
test_acpi_piix4_no_bridge_hotplug);
+qtest_add_func("acpi/piix4/pci-hotplug/off",
+   test_acpi_piix4_no_acpi_pci_hotplug);
 qtest_add_func("acpi/q35", test_acpi_q35_tcg);
 qtest_add_func("acpi/q35/bridge", test_acpi_q35_tcg_bridge);
 qtest_add_func("acpi/q35/mmio64", test_acpi_q35_tcg_mmio64);
-- 
2.17.1




[PATCH v6 09/12] piix4: don't reserve hw resources when hotplug is off globally

2020-09-17 Thread Ani Sinha
When acpi hotplug is turned off for both root pci bus as well as for pci
bridges, we should not generate the related ACPI code for DSDT table or
initialize related hw ports or reserve hw resources. This change makes
sure all those operations are turned off in the case ACPI pci hotplug is
off globally.

In this change, we also make sure ACPI code for the PCNT method are only
added when bsel is enabled for the corresponding pci bus or bridge hotplug
is turned on.

As q35 machines do not use bsel for it's pci buses at this point in time, this
change affects DSDT acpi table for q35 machines as well. Therefore, we will
also need to commit the updated golden master DSDT table acpi binary blobs as
well. This is done in the following commit. Without the updated table blobs,
the unit tests would fail with this patch.

Signed-off-by: Ani Sinha 
---
 hw/acpi/piix4.c  |  6 --
 hw/i386/acpi-build.c | 25 ++---
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index e6163bb6ce..b70b1f98af 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -596,8 +596,10 @@ static void piix4_acpi_system_hot_add_init(MemoryRegion 
*parent,
   "acpi-gpe0", GPE_LEN);
 memory_region_add_subregion(parent, GPE_BASE, &s->io_gpe);
 
-acpi_pcihp_init(OBJECT(s), &s->acpi_pci_hotplug, bus, parent,
-s->use_acpi_hotplug_bridge);
+if (s->use_acpi_hotplug_bridge || s->use_acpi_root_pci_hotplug) {
+acpi_pcihp_init(OBJECT(s), &s->acpi_pci_hotplug, bus, parent,
+s->use_acpi_hotplug_bridge);
+}
 
 s->cpu_hotplug_legacy = true;
 object_property_add_bool(OBJECT(s), "cpu-hotplug-legacy",
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e079b686f5..e41bb0992b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -95,6 +95,7 @@ typedef struct AcpiPmInfo {
 bool s3_disabled;
 bool s4_disabled;
 bool pcihp_bridge_en;
+bool pcihp_root_en;
 uint8_t s4_val;
 AcpiFadtData fadt;
 uint16_t cpu_hp_io_base;
@@ -245,6 +246,9 @@ static void acpi_get_pm_info(MachineState *machine, 
AcpiPmInfo *pm)
 pm->pcihp_bridge_en =
 object_property_get_bool(obj, "acpi-pci-hotplug-with-bridge-support",
  NULL);
+pm->pcihp_root_en =
+object_property_get_bool(obj, "acpi-root-pci-hotplug",
+ NULL);
 }
 
 static void acpi_get_misc_info(AcpiMiscInfo *info)
@@ -450,10 +454,12 @@ static void build_append_pci_bus_devices(Aml 
*parent_scope, PCIBus *bus,
 }
 
 /* Append PCNT method to notify about events on local and child buses.
- * Add unconditionally for root since DSDT expects it.
+ * Add this method for root bus only when hotplug is enabled since DSDT
+ * expects it.
  */
-method = aml_method("PCNT", 0, AML_NOTSERIALIZED);
-
+if (bsel || pcihp_bridge_en) {
+method = aml_method("PCNT", 0, AML_NOTSERIALIZED);
+}
 /* If bus supports hotplug select it and notify about local events */
 if (bsel) {
 uint64_t bsel_val = qnum_get_uint(qobject_to(QNum, bsel));
@@ -479,7 +485,10 @@ static void build_append_pci_bus_devices(Aml 
*parent_scope, PCIBus *bus,
 aml_append(method, aml_name("^S%.02X.PCNT", devfn));
 }
 }
-aml_append(parent_scope, method);
+
+if (bsel || pcihp_bridge_en) {
+aml_append(parent_scope, method);
+}
 qobject_unref(bsel);
 }
 
@@ -1504,7 +1513,9 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 build_hpet_aml(dsdt);
 build_piix4_isa_bridge(dsdt);
 build_isa_devices_aml(dsdt);
-build_piix4_pci_hotplug(dsdt);
+if (pm->pcihp_bridge_en || pm->pcihp_root_en) {
+build_piix4_pci_hotplug(dsdt);
+}
 build_piix4_pci0_int(dsdt);
 } else {
 sb_scope = aml_scope("_SB");
@@ -1546,7 +1557,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 {
 aml_append(scope, aml_name_decl("_HID", aml_string("ACPI0006")));
 
-if (misc->is_piix4) {
+if (misc->is_piix4 && (pm->pcihp_bridge_en || pm->pcihp_root_en)) {
 method = aml_method("_E01", 0, AML_NOTSERIALIZED);
 aml_append(method,
 aml_acquire(aml_name("\\_SB.PCI0.BLCK"), 0x));
@@ -1698,7 +1709,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 crs_range_set_free(&crs_range_set);
 
 /* reserve PCIHP resources */
-if (pm->pcihp_io_len) {
+if (pm->pcihp_io_len && (pm->pcihp_bridge_en || pm->pcihp_root_en)) {
 dev = aml_device("PHPR");
 aml_append(dev, aml_name_decl("_HID", aml_string("PNP0A06")));
 aml_append(dev,
-- 
2.17.1




[PATCH V3 07/10] block/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the block folder.

Signed-off-by: zhaolichang 
---
 block/block-copy.c | 2 +-
 block/linux-aio.c  | 2 +-
 block/mirror.c | 2 +-
 block/vhdx.c   | 2 +-
 block/vhdx.h   | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/block/block-copy.c b/block/block-copy.c
index cd9bc47c8f..5eb8912e0a 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -321,7 +321,7 @@ static coroutine_fn int block_copy_task_run(AioTaskPool 
*pool,
  * Do copy of cluster-aligned chunk. Requested region is allowed to exceed
  * s->len only to cover last cluster when s->len is not aligned to clusters.
  *
- * No sync here: nor bitmap neighter intersecting requests handling, only copy.
+ * No sync here: neither bitmap nor intersecting requests handling, only copy.
  *
  * Returns 0 on success.
  */
diff --git a/block/linux-aio.c b/block/linux-aio.c
index 3c0527c2bf..772ff860ea 100644
--- a/block/linux-aio.c
+++ b/block/linux-aio.c
@@ -222,7 +222,7 @@ static void qemu_laio_process_completions(LinuxAioState *s)
 
 /* If we are nested we have to notify the level above that we are done
  * by setting event_max to zero, upper level will then jump out of it's
- * own `for` loop.  If we are the last all counters droped to zero. */
+ * own `for` loop.  If we are the last all counters dropped to zero. */
 s->event_max = 0;
 s->event_idx = 0;
 }
diff --git a/block/mirror.c b/block/mirror.c
index 26acf4af6f..c798a1e54e 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -479,7 +479,7 @@ static uint64_t coroutine_fn 
mirror_iteration(MirrorBlockJob *s)
 
 job_pause_point(&s->common.job);
 
-/* Find the number of consective dirty chunks following the first dirty
+/* Find the number of consecutive dirty chunks following the first dirty
  * one, and wait for in flight requests in them. */
 bdrv_dirty_bitmap_lock(s->dirty_bitmap);
 while (nb_chunks * s->granularity < s->buf_size) {
diff --git a/block/vhdx.c b/block/vhdx.c
index 356ec4c455..99cc3d12bb 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1073,7 +1073,7 @@ static int vhdx_open(BlockDriverState *bs, QDict 
*options, int flags,
 goto fail;
 }
 
-/* endian convert populated BAT field entires */
+/* endian convert populated BAT field entries */
 for (i = 0; i < s->bat_entries; i++) {
 s->bat[i] = le64_to_cpu(s->bat[i]);
 }
diff --git a/block/vhdx.h b/block/vhdx.h
index 0b74924cee..e385e484b4 100644
--- a/block/vhdx.h
+++ b/block/vhdx.h
@@ -212,7 +212,7 @@ typedef struct QEMU_PACKED VHDXLogDataSector {
 uint32_tsequence_high;  /* 4 MSB of 8 byte sequence_number */
 uint8_t data[4084]; /* raw data, bytes 8-4091 (inclusive).
see the data descriptor field for 
the
-   other mising bytes */
+   other missing bytes */
 uint32_tsequence_low;   /* 4 LSB of 8 byte sequence_number */
 } VHDXLogDataSector;
 
@@ -257,7 +257,7 @@ typedef struct QEMU_PACKED VHDXMetadataTableHeader {
 
 #define VHDX_META_FLAGS_IS_USER 0x01/* max 1024 entries */
 #define VHDX_META_FLAGS_IS_VIRTUAL_DISK 0x02/* virtual disk metadata if 
set,
-   otherwise file metdata */
+   otherwise file metadata */
 #define VHDX_META_FLAGS_IS_REQUIRED 0x04/* parse must understand this
entry to open the file */
 typedef struct QEMU_PACKED VHDXMetadataTableEntry {
-- 
2.26.2.windows.1




[PATCH V3 02/10] migration/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the migration folder.

Signed-off-by: zhaolichang 
Reviewed-by: Peter Maydell 
---
 migration/colo-failover.c |  2 +-
 migration/colo.c  |  2 +-
 migration/multifd.c   |  4 ++--
 migration/postcopy-ram.c  |  4 ++--
 migration/postcopy-ram.h  |  2 +-
 migration/ram.c   | 10 +-
 migration/rdma.c  |  8 
 migration/savevm.c|  4 ++--
 8 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/migration/colo-failover.c b/migration/colo-failover.c
index e9ca0b4774..b717edc8e2 100644
--- a/migration/colo-failover.c
+++ b/migration/colo-failover.c
@@ -46,7 +46,7 @@ void failover_request_active(Error **errp)
 {
if (failover_set_state(FAILOVER_STATUS_NONE,
 FAILOVER_STATUS_REQUIRE) != FAILOVER_STATUS_NONE) {
-error_setg(errp, "COLO failover is already actived");
+error_setg(errp, "COLO failover is already activated");
 return;
 }
 failover_bh = qemu_bh_new(colo_failover_bh, NULL);
diff --git a/migration/colo.c b/migration/colo.c
index ea7d1e9d4e..80788d46b5 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -632,7 +632,7 @@ out:
 /*
  * It is safe to unregister notifier after failover finished.
  * Besides, colo_delay_timer and colo_checkpoint_sem can't be
- * released befor unregister notifier, or there will be use-after-free
+ * released before unregister notifier, or there will be use-after-free
  * error.
  */
 colo_compare_unregister_notifier(&packets_compare_notifier);
diff --git a/migration/multifd.c b/migration/multifd.c
index d0441202aa..ac84a61797 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -731,7 +731,7 @@ static void multifd_new_send_channel_async(QIOTask *task, 
gpointer opaque)
 qemu_sem_post(&p->sem_sync);
 /*
  * Although multifd_send_thread is not created, but main migration
- * thread neet to judge whether it is running, so we need to mark
+ * thread needs to judge whether it is running, so we need to mark
  * its status.
  */
 p->quit = true;
@@ -1042,7 +1042,7 @@ bool multifd_recv_all_channels_created(void)
 
 /*
  * Try to receive all multifd channels to get ready for the migration.
- * - Return true and do not set @errp when correctly receving all channels;
+ * - Return true and do not set @errp when correctly receiving all channels;
  * - Return false and do not set @errp when correctly receiving the current 
one;
  * - Return false and set @errp when failing to receive the current channel.
  */
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 1bb22f2b6c..baf094ba3a 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -237,7 +237,7 @@ release_ufd:
  * request_ufd_features: this function should be called only once on a newly
  * opened ufd, subsequent calls will lead to error.
  *
- * Returns: true on succes
+ * Returns: true on success
  *
  * @ufd: fd obtained from userfaultfd syscall
  * @features: bit mask see UFFD_API_FEATURES
@@ -807,7 +807,7 @@ static void mark_postcopy_blocktime_end(uintptr_t addr)
 
 low_time_offset = get_low_time_offset(dc);
 /* lookup cpu, to clear it,
- * that algorithm looks straighforward, but it's not
+ * that algorithm looks straightforward, but it's not
  * optimal, more optimal algorithm is keeping tree or hash
  * where key is address value is a list of  */
 for (i = 0; i < smp_cpus; i++) {
diff --git a/migration/postcopy-ram.h b/migration/postcopy-ram.h
index 9941feb63a..6d2b3cf124 100644
--- a/migration/postcopy-ram.h
+++ b/migration/postcopy-ram.h
@@ -161,7 +161,7 @@ struct PostCopyFD {
  */
 void postcopy_register_shared_ufd(struct PostCopyFD *pcfd);
 void postcopy_unregister_shared_ufd(struct PostCopyFD *pcfd);
-/* Call each of the shared 'waker's registerd telling them of
+/* Call each of the shared 'waker's registered telling them of
  * availability of a block.
  */
 int postcopy_notify_shared_wake(RAMBlock *rb, uint64_t offset);
diff --git a/migration/ram.c b/migration/ram.c
index 76d4fee5d5..c5f36aeae5 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -256,7 +256,7 @@ int64_t ramblock_recv_bitmap_send(QEMUFile *file,
 /*
  * Always use little endian when sending the bitmap. This is
  * required that when source and destination VMs are not using the
- * same endianess. (Note: big endian won't work.)
+ * same endianness. (Note: big endian won't work.)
  */
 bitmap_to_le(le_bitmap, block->receivedmap, nbits);
 
@@ -275,7 +275,7 @@ int64_t ramblock_recv_bitmap_send(QEMUFile *file,
 qemu_put_buffer(file, (const uint8_t *)le_bitmap, size);
 /*
  * Mark as an end, in case the middle part is screwed up due to
- * some "misterious" reason.
+ * some "mysteri

[PATCH v6 12/12] tests/acpi: add DSDT.hpbrroot DSDT table blob to test global i440fx hotplug

2020-09-17 Thread Ani Sinha
This change adds a new DSDT golden master table blob to test disabling
hotplug on both pci root bus and pci bridges. Also reverts the change
in file bios-tables-test-allowed-diff.h to make sure its now empty so that
future modifications to acpi tables can be caught.

The following is the disassembled diff between DSDT.hpbridge and DSDT.hpbrroot:

@@ -1,30 +1,30 @@
 /*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20180105 (64-bit version)
  * Copyright (c) 2000 - 2018 Intel Corporation
  *
  * Disassembling to symbolic ASL+ operators
  *
- * Disassembly of tests/data/acpi/pc/DSDT.hpbridge, Wed Sep 16 09:45:56 2020
+ * Disassembly of /tmp/aml-ECV9Q0, Wed Sep 16 09:45:56 2020
  *
  * Original Table Header:
  * Signature"DSDT"
- * Length   0x131F (4895)
+ * Length   0x0B89 (2953)
  * Revision 0x01  32-bit table (V1), no 64-bit math support
- * Checksum 0xF9
+ * Checksum 0xA2
  * OEM ID   "BOCHS "
  * OEM Table ID "BXPCDSDT"
  * OEM Revision 0x0001 (1)
  * Compiler ID  "BXPC"
  * Compiler Version 0x0001 (1)
  */
 DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPCDSDT", 0x0001)
 {
 Scope (\)
 {
 OperationRegion (DBG, SystemIO, 0x0402, One)
 Field (DBG, ByteAcc, NoLock, Preserve)
 {
 DBGB,   8
 }

@@ -234,64 +234,32 @@
 {
 Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: 
Hardware ID
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
 IO (Decode16,
 0x0070, // Range Minimum
 0x0070, // Range Maximum
 0x01,   // Alignment
 0x08,   // Length
 )
 IRQNoFlags ()
 {8}
 })
 }
 }

-Scope (_SB.PCI0)
-{
-OperationRegion (PCST, SystemIO, 0xAE00, 0x08)
-Field (PCST, DWordAcc, NoLock, WriteAsZeros)
-{
-PCIU,   32,
-PCID,   32
-}
-
-OperationRegion (SEJ, SystemIO, 0xAE08, 0x04)
-Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
-{
-B0EJ,   32
-}
-
-OperationRegion (BNMR, SystemIO, 0xAE10, 0x04)
-Field (BNMR, DWordAcc, NoLock, WriteAsZeros)
-{
-BNUM,   32
-}
-
-Mutex (BLCK, 0x00)
-Method (PCEJ, 2, NotSerialized)
-{
-Acquire (BLCK, 0x)
-BNUM = Arg0
-B0EJ = (One << Arg1)
-Release (BLCK)
-Return (Zero)
-}
-}
-
 Scope (_SB)
 {
 Scope (PCI0)
 {
 Method (_PRT, 0, NotSerialized)  // _PRT: PCI Routing Table
 {
 Local0 = Package (0x80){}
 Local1 = Zero
 While ((Local1 < 0x80))
 {
 Local2 = (Local1 >> 0x02)
 Local3 = ((Local1 + Local2) & 0x03)
 If ((Local3 == Zero))
 {
 Local4 = Package (0x04)
 {
@@ -690,38 +658,32 @@
 Method (_OST, 3, Serialized)  // _OST: OSPM Status Indication
 {
 COST (Zero, Arg0, Arg1, Arg2)
 }
 }
 }
 }

 Method (\_GPE._E02, 0, NotSerialized)  // _Exx: Edge-Triggered GPE
 {
 \_SB.CPUS.CSCN ()
 }

 Scope (_GPE)
 {
 Name (_HID, "ACPI0006" /* GPE Block Device */)  // _HID: Hardware ID
-Method (_E01, 0, NotSerialized)  // _Exx: Edge-Triggered GPE
-{
-Acquire (\_SB.PCI0.BLCK, 0x)
-\_SB.PCI0.PCNT ()
-Release (\_SB.PCI0.BLCK)
-}
 }

 Scope (\_SB.PCI0)
 {
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
 WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
 0x, // Granularity
 0x, // Range Minimum
 0x00FF, // Range Maximum
 0x, // Translation Offset
 0x0100, // Length
 ,, )
 IO (Decode16,
 0x0CF8, // Range Minimum
 0x0CF8, // Range Maximum
@@ -766,48 +728,32 @@
 })
 Device (GPE0)
 {
 Name (_HID, "PNP0A06" /* Generic Container Device */)  // _HID: 
Hardware ID
 Name (_UID, "GPE0 resources")  // _UID: Unique ID
 Name (_STA, 0x0B)  // _STA: Status
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
 IO (Decode16,
  

[PATCH v6 10/12] tests/acpi: update golden master DSDT binary table blobs for q35

2020-09-17 Thread Ani Sinha
In the change d7f82561fe ("piix4: don't reserve hw resources when
hotplug is off globally"), we make changes to the ACPI DSDT tables
such that some ACPI code are not generated when bsel is absent. Since
as of this point in time, in q35 machines, we do not use bsel for pci
buses, we need to update the DSDT table blobs.
This patch updates the golden master table blobs.

Signed-off-by: Ani Sinha 
---
 tests/data/acpi/q35/DSDT  | Bin 7678 -> 7670 bytes
 tests/data/acpi/q35/DSDT.acpihmat | Bin 9002 -> 8994 bytes
 tests/data/acpi/q35/DSDT.bridge   | Bin 7695 -> 7688 bytes
 tests/data/acpi/q35/DSDT.cphp | Bin 8141 -> 8133 bytes
 tests/data/acpi/q35/DSDT.dimmpxm  | Bin 9331 -> 9323 bytes
 tests/data/acpi/q35/DSDT.ipmibt   | Bin 7753 -> 7745 bytes
 tests/data/acpi/q35/DSDT.memhp| Bin 9037 -> 9029 bytes
 tests/data/acpi/q35/DSDT.mmio64   | Bin 8808 -> 8801 bytes
 tests/data/acpi/q35/DSDT.numamem  | Bin 7684 -> 7676 bytes
 tests/data/acpi/q35/DSDT.tis  | Bin 8283 -> 8276 bytes
 10 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/tests/data/acpi/q35/DSDT b/tests/data/acpi/q35/DSDT
index 
bba8884073a27427b88ac0d733c9c87330a59366..4fad91b72e279b744b0528fd687c862d3a3d5cfa
 100644
GIT binary patch
delta 33
pcmexo{mq)oCDEHUxHPVoYElb9FB)33dtLkYiwAT)&ZPnJlLVYfOBwQ@nt~9^r>33dtLmt$aH^xnv|OqSE1H6}jTDPF*R@=jTQb`iD!XTJ~z0NaZSF#rGn

diff --git a/tests/data/acpi/q35/DSDT.cphp b/tests/data/acpi/q35/DSDT.cphp
index 
57d859cef9fa16a8f125c4b338611c8472699f38..8d2395e3cb4383b30e3840caed0d09ccad0c7323
 100644
GIT binary patch
delta 33
ocmX?Wf7G7KCDY0kO^r)&Kwi

delta 42
xcmX?Vf7YJMCDvmYDcpr+5K3mdPFRw(KHo0nUCQ3;+bB3f%wz

diff --git a/tests/data/acpi/q35/DSDT.dimmpxm b/tests/data/acpi/q35/DSDT.dimmpxm
index 
9d5bd5744e2ba2e0f6126c3aba0bb36af865e499..df7422051c6feadeaa3b6733ad7efa67c339b49d
 100644
GIT binary patch
delta 33
ocmezD@!EsSCD)i9vcGQi_CDc=Kufz

delta 42
xcmX@=cGiu{CD^

diff --git a/tests/data/acpi/q35/DSDT.mmio64 b/tests/data/acpi/q35/DSDT.mmio64
index 
efd3f1188f2b55da1514212d4be081a61c2a96e9..d8dd702b69cc24a6b58b8eaa79ea02439a2a7dd9
 100644
GIT binary patch
delta 33
ocmaFi^3a9LCD)i>_Ld&VC^b00^lI82|tP

diff --git a/tests/data/acpi/q35/DSDT.numamem b/tests/data/acpi/q35/DSDT.numamem
index 
1978b55f1255402bf9bade0b91150b5cb49789a4..f36d22063a6eed4fb107ffd0e10477a2d6d7a983
 100644
GIT binary patch
delta 33
pcmZp%`D4xH66_N4N0xzs@!&?THL{#;EHUxHPVoYElMl$+0sy+k3XK2&

delta 42
xcmexk-D1P#66_MfBFDhM7`l;bjVzZROH6#QQ@ns1%jEsCw(KHo0nUCQ3;^@W3X}i<

diff --git a/tests/data/acpi/q35/DSDT.tis b/tests/data/acpi/q35/DSDT.tis
index 
638de3872673d17b1958497d0e62c83653de1602..203030a61a92c204bb93c43fe79e546471ae2985
 100644
GIT binary patch
delta 38
ucmccZaK(YkCDUZRU~-WC8&31`DbH

delta 45
zcmccOaNB{)CD

[PATCH V3 00/10] fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors, this series fixed 
this
spelling errors.

v2 -> v3:
  fix coding style problems in v2 version

v1 -> v2:
  address Peter Maydell's comments
  address Alex Bennee's comments
  add reviewed-by for patch 1,2,3,4,5,6,9,10

zhaolichang (10):
  qemu/: fix some comment spelling errors
  migration/: fix some comment spelling errors
  docs/: fix some comment spelling errors
  scripts/: fix some comment spelling errors
  util/: fix some comment spelling errors
  linux-user/: fix some comment spelling errors
  block/: fix some comment spelling errors
  disas/: fix some comment spelling errors
  qapi/: fix some comment spelling errors
  contrib/: fix some comment spelling errors

 Changelog|  2 +-
 accel/tcg/user-exec.c|  2 +-
 audio/audio.c|  2 +-
 block.c  |  2 +-
 block/block-copy.c   |  2 +-
 block/linux-aio.c|  2 +-
 block/mirror.c   |  2 +-
 block/vhdx.c |  2 +-
 block/vhdx.h |  4 ++--
 configure|  2 +-
 contrib/gitdm/filetypes.txt  |  6 +++---
 contrib/ivshmem-client/ivshmem-client.h  |  2 +-
 contrib/libvhost-user/libvhost-user.c|  4 ++--
 contrib/libvhost-user/libvhost-user.h|  2 +-
 disas/hppa.c |  2 +-
 disas/m68k.c |  8 
 disas/ppc.c  |  2 +-
 docs/COLO-FT.txt |  6 +++---
 docs/devel/blkdebug.txt  |  2 +-
 docs/devel/migration.rst |  2 +-
 docs/devel/testing.rst   |  2 +-
 docs/devel/tracing.txt   |  2 +-
 docs/interop/bitmaps.rst |  2 +-
 docs/interop/dbus.rst|  4 ++--
 docs/interop/nbd.txt |  2 +-
 docs/interop/vhost-user-gpu.rst  |  2 +-
 docs/interop/vhost-user.rst  |  4 ++--
 docs/rdma.txt|  2 +-
 docs/specs/ppc-spapr-hotplug.txt |  4 ++--
 docs/specs/ppc-spapr-xive.rst|  4 ++--
 docs/system/arm/aspeed.rst   |  2 +-
 docs/system/deprecated.rst   |  8 
 docs/system/target-avr.rst   |  4 ++--
 docs/tools/virtiofsd.rst |  2 +-
 fsdev/virtfs-proxy-helper.c  |  2 +-
 hmp-commands.hx  |  2 +-
 libdecnumber/decNumber.c |  2 +-
 linux-user/aarch64/signal.c  |  2 +-
 linux-user/cris/target_syscall.h |  4 ++--
 linux-user/flat.h|  2 +-
 linux-user/flatload.c|  4 ++--
 linux-user/host/ppc64/safe-syscall.inc.S |  2 +-
 linux-user/syscall.c |  4 ++--
 migration/colo-failover.c|  2 +-
 migration/colo.c |  2 +-
 migration/multifd.c  |  4 ++--
 migration/postcopy-ram.c |  4 ++--
 migration/postcopy-ram.h |  2 +-
 migration/ram.c  | 10 +-
 migration/rdma.c |  8 
 migration/savevm.c   |  4 ++--
 qapi/block-core.json |  4 ++--
 qapi/crypto.json |  4 ++--
 qemu-img.c   |  2 +-
 qobject/qdict.c  |  2 +-
 scripts/checkpatch.pl|  2 +-
 scripts/clean-header-guards.pl   |  2 +-
 scripts/decodetree.py|  6 +++---
 scripts/oss-fuzz/build.sh|  2 +-
 scripts/tracetool/__init__.py|  2 +-
 scsi/pr-manager-helper.c |  2 +-
 util/osdep.c |  2 +-
 util/qemu-progress.c |  2 +-
 util/qemu-sockets.c  |  2 +-
 util/qemu-thread-win32.c |  2 +-
 util/qht.c   |  2 +-
 util/trace-events|  2 +-
 67 files changed, 101 insertions(+), 101 deletions(-)

-- 
2.26.2.windows.1




[PATCH V3 03/10] docs/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the docs folder.

Signed-off-by: zhaolichang 
Reviewed-by: Peter Maydell 
---
 docs/COLO-FT.txt | 6 +++---
 docs/devel/blkdebug.txt  | 2 +-
 docs/devel/migration.rst | 2 +-
 docs/devel/testing.rst   | 2 +-
 docs/devel/tracing.txt   | 2 +-
 docs/interop/bitmaps.rst | 2 +-
 docs/interop/dbus.rst| 4 ++--
 docs/interop/nbd.txt | 2 +-
 docs/interop/vhost-user-gpu.rst  | 2 +-
 docs/interop/vhost-user.rst  | 4 ++--
 docs/rdma.txt| 2 +-
 docs/specs/ppc-spapr-hotplug.txt | 4 ++--
 docs/specs/ppc-spapr-xive.rst| 4 ++--
 docs/system/arm/aspeed.rst   | 2 +-
 docs/system/deprecated.rst   | 8 
 docs/system/target-avr.rst   | 4 ++--
 docs/tools/virtiofsd.rst | 2 +-
 17 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
index c8e1740935..bc5fb2a1bb 100644
--- a/docs/COLO-FT.txt
+++ b/docs/COLO-FT.txt
@@ -91,7 +91,7 @@ the heartbeat stops responding, the secondary node will 
trigger a failover
 as soon as it determines the absence.
 
 COLO disk Manager:
-When primary VM writes data into image, the colo disk manger captures this data
+When primary VM writes data into image, the colo disk manager captures this 
data
 and sends it to secondary VM's which makes sure the context of secondary VM's
 image is consistent with the context of primary VM 's image.
 For more details, please refer to docs/block-replication.txt.
@@ -146,12 +146,12 @@ in test procedure.
 
 == Test procedure ==
 Note: Here we are running both instances on the same host for testing,
-change the IP Addresses if you want to run it on two hosts. Initally
+change the IP Addresses if you want to run it on two hosts. Initially
 127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
 
 == Startup qemu ==
 1. Primary:
-Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
+Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
 You don't need to change any IP's here, because 0.0.0.0 listens on any
 interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
 instance.
diff --git a/docs/devel/blkdebug.txt b/docs/devel/blkdebug.txt
index 43d8e8f9c6..0b0c128d35 100644
--- a/docs/devel/blkdebug.txt
+++ b/docs/devel/blkdebug.txt
@@ -62,7 +62,7 @@ Rules support the following attributes:
 
   errno - the numeric errno value to return when a request matches this rule.
   The errno values depend on the host since the numeric values are not
-  standarized in the POSIX specification.
+  standardized in the POSIX specification.
 
   sector - (optional) a sector number that the request must overlap in order to
match this rule
diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
index 2eb08624fc..49112bb27a 100644
--- a/docs/devel/migration.rst
+++ b/docs/devel/migration.rst
@@ -625,7 +625,7 @@ It can be issued immediately after migration is started or 
any
 time later on.  Issuing it after the end of a migration is harmless.
 
 Blocktime is a postcopy live migration metric, intended to show how
-long the vCPU was in state of interruptable sleep due to pagefault.
+long the vCPU was in state of interruptible sleep due to pagefault.
 That metric is calculated both for all vCPUs as overlapped value, and
 separately for each vCPU. These values are calculated on destination
 side.  To enable postcopy blocktime calculation, enter following
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 196e3bc35e..bd64c1bdcd 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -471,7 +471,7 @@ the warning.
 A few important files for suppressing warnings are:
 
 tests/tsan/suppressions.tsan - Has TSan warnings we wish to suppress at 
runtime.
-The comment on each supression will typically indicate why we are
+The comment on each suppression will typically indicate why we are
 suppressing it.  More information on the file format can be found here:
 
 https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions
diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt
index 6144d9921b..d2160655b4 100644
--- a/docs/devel/tracing.txt
+++ b/docs/devel/tracing.txt
@@ -55,7 +55,7 @@ without any sub-directory path prefix. eg io/channel-buffer.c 
would do
   #include "trace.h"
 
 To access the 'io/trace.h' file. While it is possible to include a trace.h
-file from outside a source files' own sub-directory, this is discouraged in
+file from outside a source file's own sub-directory, this is discouraged in
 general. It is strongly preferred that all events be declared directly in
 the sub-directory that uses them. The only exception is where there are some
 shared trace events defined in the top level dire

Re: [RFC PATCH 02/12] target/arm/kvm64: make MPIDR consistent with CPU Topology

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:23AM +0800, Ying Fang wrote:
> MPIDR helps to provide an additional PE identification in a multiprocessor
> system. This patch adds support for setting MPIDR from userspace, so that
> MPIDR is consistent with CPU topology configured.
> 
> Signed-off-by: Ying Fang 
> ---
>  target/arm/kvm64.c | 46 ++
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
> index ef1e960285..fcce261a10 100644
> --- a/target/arm/kvm64.c
> +++ b/target/arm/kvm64.c
> @@ -757,10 +757,46 @@ static int kvm_arm_sve_set_vls(CPUState *cs)
>  
>  #define ARM_CPU_ID_MPIDR   3, 0, 0, 0, 5
>  
> +static int kvm_arm_set_mp_affinity(CPUState *cs)
> +{
> +uint64_t mpidr;
> +ARMCPU *cpu = ARM_CPU(cs);
> +
> +if (kvm_check_extension(kvm_state, KVM_CAP_ARM_MP_AFFINITY)) {
> +/* Make MPIDR consistent with CPU topology */
> +MachineState *ms = MACHINE(qdev_get_machine());
> +
> +mpidr = (kvm_arch_vcpu_id(cs) % ms->smp.threads) << ARM_AFF0_SHIFT;

We should query KVM first to determine if it wants guests to see their PEs
as threads or not. If not, and ms->smp.threads is > 1, then that's an
error. And, in any case, if ms->smp.threads == 1, then we shouldn't waste
aff0 on it, as that could reduce IPI broadcast performance.

> +mpidr |= ((kvm_arch_vcpu_id(cs) / ms->smp.threads % ms->smp.cores)
> +& 0xff) << ARM_AFF1_SHIFT;
> +mpidr |= (kvm_arch_vcpu_id(cs) / (ms->smp.cores * ms->smp.threads)
> +& 0xff) << ARM_AFF2_SHIFT;
> +
> +/* Override mp affinity when KVM is in use */
> +cpu->mp_affinity = mpidr & ARM64_AFFINITY_MASK;
> +
> +/* Bit 31 is RES1 indicates the ARMv7 Multiprocessing Extensions */
> +mpidr |= (1ULL << 31);
> +return kvm_vcpu_ioctl(cs, KVM_ARM_SET_MP_AFFINITY, &mpidr);
> +} else {
> +/*
> + * When KVM_CAP_ARM_MP_AFFINITY is not supported, it means KVM has 
> its
> + * own idea about MPIDR assignment, so we override our defaults with
> + * what we get from KVM.
> + */
> +int ret = kvm_get_one_reg(cs, ARM64_SYS_REG(ARM_CPU_ID_MPIDR), 
> &mpidr);
> +if (ret) {
> +error_report("failed to set MPIDR");

We don't need this error, kvm_get_one_reg() has trace support already.
Anyway, the wording is wrong since it says 'set' instead of 'get'.

> +return ret;
> +}
> +cpu->mp_affinity = mpidr & ARM32_AFFINITY_MASK;
> +return ret;
> +}
> +}
> +
>  int kvm_arch_init_vcpu(CPUState *cs)
>  {
>  int ret;
> -uint64_t mpidr;
>  ARMCPU *cpu = ARM_CPU(cs);
>  CPUARMState *env = &cpu->env;
>  
> @@ -814,16 +850,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  }
>  }
>  
> -/*
> - * When KVM is in use, PSCI is emulated in-kernel and not by qemu.
> - * Currently KVM has its own idea about MPIDR assignment, so we
> - * override our defaults with what we get from KVM.
> - */
> -ret = kvm_get_one_reg(cs, ARM64_SYS_REG(ARM_CPU_ID_MPIDR), &mpidr);
> +ret = kvm_arm_set_mp_affinity(cs);
>  if (ret) {
>  return ret;
>  }
> -cpu->mp_affinity = mpidr & ARM64_AFFINITY_MASK;
>  
>  kvm_arm_init_debug(cs);
>  
> -- 
> 2.23.0
> 
>

Thanks,
drew 




Re: [PATCH v2] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Thomas Huth
On 17/09/2020 09.47, Philippe Mathieu-Daudé wrote:
> On 9/17/20 9:43 AM, Thomas Huth wrote:
>> GCC 9.3.0 on Ubuntu complains:
>>
>> In file included from /usr/include/string.h:495,
>>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>>  from ../migration/global_state.c:13:
>> In function ‘strncpy’,
>> inlined from ‘global_state_store_running’ at 
>> ../migration/global_state.c:47:5:
>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
>>  ‘__builtin_strncpy’ specified bound 100 equals destination size 
>> [-Werror=stringop-truncation]
>>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
>> (__dest));
>>   |  
>> ^~
>>
>> ... but we apparently really want to do a strncpy here - the size is already
>> checked with the assert() statement right in front of it. To silence the
>> warning, simply replace it with our strpadcpy() function.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  v2: Use strpadcpy instead of QEMU_NONSTRING (and yes, this time it seems
>>  to really silence the compiler warning :-))
>>
>>  migration/global_state.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/migration/global_state.c b/migration/global_state.c
>> index 25311479a4..a33947ca32 100644
>> --- a/migration/global_state.c
>> +++ b/migration/global_state.c
>> @@ -44,8 +44,8 @@ void global_state_store_running(void)
>>  {
>>  const char *state = RunState_str(RUN_STATE_RUNNING);
>>  assert(strlen(state) < sizeof(global_state.runstate));
>> -strncpy((char *)global_state.runstate,
>> -   state, sizeof(global_state.runstate));
>> +strpadcpy((char *)global_state.runstate, sizeof(global_state.runstate),
>> +  state, '\0');
> 
> https://www.mail-archive.com/qemu-block@nongnu.org/msg44925.html
> ;)

Oh, well :-) ... but why did you never pushed to get that merged?

 Thomas




Re: [PATCH V9 0/6] mips: Add Loongson-3 machine support

2020-09-17 Thread Philippe Mathieu-Daudé
Hi Huacai,

On 9/16/20 4:12 AM, Huacai Chen wrote:
> Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
> R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, while
> Loongson-3A R4 is the newest and its ISA is almost the superset of all
> others. To reduce complexity, in QEMU we just define two CPU types:
> 
> 1, "Loongson-3A1000" CPU which is corresponding to Loongson-3A R1. It is
>suitable for TCG because Loongson-3A R1 has fewest ASE.
> 2, "Loongson-3A4000" CPU which is corresponding to Loongson-3A R4. It is
>suitable for KVM because Loongson-3A R4 has the VZ ASE.
> 
[...]

> Of course the upstream kernel is also usable (though it is "unstable"
> now):
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> How to use QEMU/Loongson-3?
> 1, Download kernel source from the above URL;
> 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> 3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
> 4, Build QEMU-master with this patchset;
> 5, modprobe kvm (only necessary for KVM mode);
> 6, Use QEMU with TCG:
>qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu Loongson-3A1000 
> -kernel  -append ...
>Use QEMU with KVM:
>qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu Loongson-3A4000 
> -kernel  -append ...

Can you add a KVM-only build CI job?
Simply building, not running test, as there is no MIPS CI.

See for example commit 41e1f0e2256 (".travis.yml: Add a KVM-only
s390x job"), but add it to GitLab instead.

Thanks!

Phil.



[PATCH V3 05/10] util/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the util folder.

Signed-off-by: zhaolichang 
Reviewed-by: Alex Bennee 
---
 util/osdep.c | 2 +-
 util/qemu-progress.c | 2 +-
 util/qemu-sockets.c  | 2 +-
 util/qemu-thread-win32.c | 2 +-
 util/qht.c   | 2 +-
 util/trace-events| 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/util/osdep.c b/util/osdep.c
index 4829c07ff6..e50dc2214e 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -392,7 +392,7 @@ int qemu_unlink(const char *name)
  * Set errno if fewer than `count' bytes are written.
  *
  * This function don't work with non-blocking fd's.
- * Any of the possibilities with non-bloking fd's is bad:
+ * Any of the possibilities with non-blocking fd's is bad:
  *   - return a short write (then name is wrong)
  *   - busy wait adding (errno == EAGAIN) to the loop
  */
diff --git a/util/qemu-progress.c b/util/qemu-progress.c
index 3c2223c1a2..20d51f8c12 100644
--- a/util/qemu-progress.c
+++ b/util/qemu-progress.c
@@ -131,7 +131,7 @@ void qemu_progress_end(void)
 /*
  * Report progress.
  * @delta is how much progress we made.
- * If @max is zero, @delta is an absolut value of the total job done.
+ * If @max is zero, @delta is an absolute value of the total job done.
  * Else, @delta is a progress delta since the last call, as a fraction
  * of @max.  I.e. the delta is @delta * @max / 100. This allows
  * relative accounting of functions which may be a different fraction of
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index b37d288866..99ce2fd5e6 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -416,7 +416,7 @@ static struct addrinfo 
*inet_parse_connect_saddr(InetSocketAddress *saddr,
 
 /* At least FreeBSD and OS-X 10.6 declare AI_V4MAPPED but
  * then don't implement it in their getaddrinfo(). Detect
- * this and retry without the flag since that's preferrable
+ * this and retry without the flag since that's preferable
  * to a fatal error
  */
 if (rc == EAI_BADFLAGS &&
diff --git a/util/qemu-thread-win32.c b/util/qemu-thread-win32.c
index 56a8da..d207b0cb58 100644
--- a/util/qemu-thread-win32.c
+++ b/util/qemu-thread-win32.c
@@ -289,7 +289,7 @@ void qemu_event_wait(QemuEvent *ev)
 ResetEvent(ev->event);
 
 /* Tell qemu_event_set that there are waiters.  No need to retry
- * because there cannot be a concurent busy->free transition.
+ * because there cannot be a concurrent busy->free transition.
  * After the CAS, the event will be either set or busy.
  */
 if (atomic_cmpxchg(&ev->value, EV_FREE, EV_BUSY) == EV_SET) {
diff --git a/util/qht.c b/util/qht.c
index 67e5d5b916..b2e020c398 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -49,7 +49,7 @@
  * it anymore.
  *
  * Writers check for concurrent resizes by comparing ht->map before and after
- * acquiring their bucket lock. If they don't match, a resize has occured
+ * acquiring their bucket lock. If they don't match, a resize has occurred
  * while the bucket spinlock was being acquired.
  *
  * Related Work:
diff --git a/util/trace-events b/util/trace-events
index 4e894aa9c3..24c31803b0 100644
--- a/util/trace-events
+++ b/util/trace-events
@@ -28,7 +28,7 @@ qemu_file_monitor_add_watch(void *mon, const char *dirpath, 
const char *filename
 qemu_file_monitor_remove_watch(void *mon, const char *dirpath, int64_t id) 
"File monitor %p remove watch dir='%s' id=%" PRId64
 qemu_file_monitor_new(void *mon, int fd) "File monitor %p created fd=%d"
 qemu_file_monitor_enable_watch(void *mon, const char *dirpath, int id) "File 
monitor %p enable watch dir='%s' id=%u"
-qemu_file_monitor_disable_watch(void *mon, const char *dirpath, int id) "Fle 
monitor %p disable watch dir='%s' id=%u"
+qemu_file_monitor_disable_watch(void *mon, const char *dirpath, int id) "File 
monitor %p disable watch dir='%s' id=%u"
 qemu_file_monitor_event(void *mon, const char *dirpath, const char *filename, 
int mask, unsigned int id) "File monitor %p event dir='%s' file='%s' mask=0x%x 
id=%u"
 qemu_file_monitor_dispatch(void *mon, const char *dirpath, const char 
*filename, int ev, void *cb, void *opaque, int64_t id) "File monitor %p 
dispatch dir='%s' file='%s' ev=%d cb=%p opaque=%p id=%" PRId64
 
-- 
2.26.2.windows.1




[PATCH V3 04/10] scripts/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the scripts folder.

Signed-off-by: zhaolichang 
Reviewed-by: Peter Maydell 
---
 scripts/checkpatch.pl  | 2 +-
 scripts/clean-header-guards.pl | 2 +-
 scripts/decodetree.py  | 6 +++---
 scripts/oss-fuzz/build.sh  | 2 +-
 scripts/tracetool/__init__.py  | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index bd3faa154c..50910899f2 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1870,7 +1870,7 @@ sub process {
substr($s, 0, length($c), '');
 
# Make sure we remove the line prefixes as we have
-   # none on the first line, and are going to readd them
+   # none on the first line, and are going to re-add them
# where necessary.
$s =~ s/\n./\n/gs;
 
diff --git a/scripts/clean-header-guards.pl b/scripts/clean-header-guards.pl
index f47d673ad5..a6680253b1 100755
--- a/scripts/clean-header-guards.pl
+++ b/scripts/clean-header-guards.pl
@@ -19,7 +19,7 @@
 # Does the following:
 # - Header files without a recognizable header guard are skipped.
 # - Clean up any untidy header guards in-place.  Warn if the cleanup
-#   renames guard symbols, and explain how to find occurences of these
+#   renames guard symbols, and explain how to find occurrences of these
 #   symbols that may have to be updated manually.
 # - Warn about duplicate header guard symbols.  To make full use of
 #   this warning, you should clean up *all* headers in one run.
diff --git a/scripts/decodetree.py b/scripts/decodetree.py
index c02de9865b..60fd3b5e5f 100644
--- a/scripts/decodetree.py
+++ b/scripts/decodetree.py
@@ -94,7 +94,7 @@ def str_indent(c):
 
 
 def str_fields(fields):
-"""Return a string uniquely identifing FIELDS"""
+"""Return a string uniquely identifying FIELDS"""
 r = ''
 for n in sorted(fields.keys()):
 r += '_' + n
@@ -814,7 +814,7 @@ def parse_generic(lineno, parent_pat, name, toks):
 arg = None
 fmt = None
 for t in toks:
-# '&Foo' gives a format an explcit argument set.
+# '&Foo' gives a format an explicit argument set.
 if re.fullmatch(re_arg_ident, t):
 tt = t[1:]
 if arg:
@@ -903,7 +903,7 @@ def parse_generic(lineno, parent_pat, name, toks):
 elif not (is_format and width == 0) and width != insnwidth:
 error(lineno, 'definition has {0} bits'.format(width))
 
-# Do not check for fields overlaping fields; one valid usage
+# Do not check for fields overlapping fields; one valid usage
 # is to be able to duplicate fields via import.
 fieldmask = 0
 for f in flds.values():
diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh
index d16207eb67..0c3ca9e06f 100755
--- a/scripts/oss-fuzz/build.sh
+++ b/scripts/oss-fuzz/build.sh
@@ -69,7 +69,7 @@ mkdir -p "$DEST_DIR/lib/"  # Copy the shared libraries here
 
 if ! make "-j$(nproc)" qemu-fuzz-i386; then
 fatal "Build failed. Please specify a compiler with fuzzing support"\
-  "using the \$CC and \$CXX environemnt variables"\
+  "using the \$CC and \$CXX environment variables"\
   "\nFor example: CC=clang CXX=clang++ $0"
 fi
 
diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 3ccfa1e116..3ee54be223 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -34,7 +34,7 @@ def error(*lines):
 def out(*lines, **kwargs):
 """Write a set of output lines.
 
-You can use kwargs as a shorthand for mapping variables when formating all
+You can use kwargs as a shorthand for mapping variables when formatting all
 the strings in lines.
 """
 lines = [ l % kwargs for l in lines ]
-- 
2.26.2.windows.1




RE: [PATCH 5/5] [automated] Use OBJECT_DECLARE_SIMPLE_TYPE when possible

2020-09-17 Thread Paul Durrant
> -Original Message-
> From: Eduardo Habkost 
> Sent: 16 September 2020 19:25
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange 
> ; Gonglei (Arei)
> ; Igor Mammedov ; Laurent 
> Vivier ;
> Amit Shah ; Stefan Berger ; Michael 
> S. Tsirkin
> ; Greg Kurz ; Christian Schoenebeck 
> ; Marcel
> Apfelbaum ; Aleksandar Markovic 
> ;
> Philippe Mathieu-Daudé ; Aurelien Jarno 
> ; Richard Henderson
> ; Peter Maydell ; Rob Herring 
> ; Joel
> Stanley ; Jan Kiszka ; Andrzej Zaborowski 
> ;
> Radoslaw Biernacki ; Leif Lindholm ; 
> Edgar E. Iglesias
> ; Alistair Francis ; Gerd 
> Hoffmann
> ; Michael Walle ; John Snow 
> ; Kevin Wolf
> ; Max Reitz ; Marc-André Lureau 
> ;
> Igor Mitsyanko ; Fabien Chouteau 
> ; KONRAD Frederic
> ; Alberto Garcia ; Thomas Huth 
> ;
> David Gibson ; Mark Cave-Ayland 
> ; Hervé
> Poussineau ; Aleksandar Rikalo 
> ; BALATON Zoltan
> ; Guan Xuetao ; Helge Deller 
> ; Corey Minyard
> ; Stefano Stabellini ; Anthony 
> Perard
> ; Paul Durrant ; Chris Wulff 
> ; Marek Vasut
> ; Huacai Chen ; Jiaxun Yang 
> ; Artyom
> Tarasenko ; Jason Wang ; Dmitry 
> Fleytman
> ; Max Filippov ; Sven Schnelle 
> ;
> Christian Borntraeger ; Cornelia Huck 
> ; Halil Pasic
> ; David Hildenbrand ; Matthew Rosato 
> ;
> Fam Zheng ; Yoshinori Sato ; 
> Samuel Thibault
> ; Tony Krowiak ; Pierre 
> Morel
> ; Alex Williamson ; Ben 
> Warren
> ; Beniamino Galvani ; Niek 
> Linnenbank
> ; Andrew Baumann ; 
> Antony Pavlov
> ; Jean-Christophe Dubois ; 
> Peter Chubb
> ; Andrey Smirnov ; 
> Subbaraya Sundeep
> ; Michael Rolnik ; Sarah Harris 
> ;
> Peter Xu ; Cédric Le Goater ; Andrew 
> Jeffery ;
> Laszlo Ersek ; Paul Burton ; Palmer 
> Dabbelt
> ; Sagar Karandikar ; Bastian 
> Koppelmann
> ; Anup Patel ; Eric 
> Farman ;
> Raphael Norwitz ; Dr. David Alan Gilbert 
> ; Stefan
> Hajnoczi ; Eric Auger ; Juan 
> Quintela
> ; Pavel Dovgalyuk ; Zhang Chen 
> ;
> Li Zhijian ; qemu-...@nongnu.org; 
> qemu-bl...@nongnu.org; qemu-
> p...@nongnu.org; k...@vger.kernel.org; xen-de...@lists.xenproject.org; 
> qemu-s3...@nongnu.org; qemu-
> ri...@nongnu.org
> Subject: [PATCH 5/5] [automated] Use OBJECT_DECLARE_SIMPLE_TYPE when possible
> 
> This converts existing DECLARE_INSTANCE_CHECKER usage to
> OBJECT_DECLARE_SIMPLE_TYPE when possible.
> 
> $ ./scripts/codeconverter/converter.py -i \
>   --pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]')
> 
> Signed-off-by: Eduardo Habkost 

Acked-by: Paul Durrant 




[PATCH V3 06/10] linux-user/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the linux-user folder.

Signed-off-by: zhaolichang 
Reviewed-by: Alex Bennee 
---
 linux-user/aarch64/signal.c  | 2 +-
 linux-user/cris/target_syscall.h | 4 ++--
 linux-user/flat.h| 2 +-
 linux-user/flatload.c| 4 ++--
 linux-user/host/ppc64/safe-syscall.inc.S | 2 +-
 linux-user/syscall.c | 4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/linux-user/aarch64/signal.c b/linux-user/aarch64/signal.c
index cd521ee42d..d50c1ae583 100644
--- a/linux-user/aarch64/signal.c
+++ b/linux-user/aarch64/signal.c
@@ -78,7 +78,7 @@ struct target_sve_context {
 struct target_aarch64_ctx head;
 uint16_t vl;
 uint16_t reserved[3];
-/* The actual SVE data immediately follows.  It is layed out
+/* The actual SVE data immediately follows.  It is laid out
  * according to TARGET_SVE_SIG_{Z,P}REG_OFFSET, based off of
  * the original struct pointer.
  */
diff --git a/linux-user/cris/target_syscall.h b/linux-user/cris/target_syscall.h
index d109a6b42a..19e1281403 100644
--- a/linux-user/cris/target_syscall.h
+++ b/linux-user/cris/target_syscall.h
@@ -4,7 +4,7 @@
 #define UNAME_MACHINE "cris"
 #define UNAME_MINIMUM_RELEASE "2.6.32"
 
-/* pt_regs not only specifices the format in the user-struct during
+/* pt_regs not only specifies the format in the user-struct during
  * ptrace but is also the frame format used in the kernel prologue/epilogues
  * themselves
  */
@@ -32,7 +32,7 @@ struct target_pt_regs {
 unsigned long spc;
 unsigned long ccs;
 unsigned long srp;
-unsigned long erp; /* This is actually the debugged process' PC */
+unsigned long erp; /* This is actually the debugged process's PC */
 /* For debugging purposes; saved only when needed. */
 unsigned long exs;
 unsigned long eda;
diff --git a/linux-user/flat.h b/linux-user/flat.h
index 1e44b33443..ed518e2013 100644
--- a/linux-user/flat.h
+++ b/linux-user/flat.h
@@ -43,7 +43,7 @@ struct flat_hdr {
abi_ulong reloc_count;  /* Number of relocation records */
abi_ulong flags;
abi_ulong build_date;   /* When the program/library was built */
-   abi_ulong filler[5];/* Reservered, set to zero */
+   abi_ulong filler[5];/* Reserved, set to zero */
 };
 
 #define FLAT_FLAG_RAM0x0001 /* load program entirely into RAM */
diff --git a/linux-user/flatload.c b/linux-user/flatload.c
index 8fb448f0bf..14d2999d15 100644
--- a/linux-user/flatload.c
+++ b/linux-user/flatload.c
@@ -442,7 +442,7 @@ static int load_flat_file(struct linux_binprm * bprm,
 indx_len = (indx_len + 15) & ~(abi_ulong)15;
 
 /*
- * Alloate the address space.
+ * Allocate the address space.
  */
 probe_guest_base(bprm->filename, 0,
  text_len + data_len + extra + indx_len);
@@ -794,7 +794,7 @@ int load_flt_binary(struct linux_binprm *bprm, struct 
image_info *info)
 #error here
 for (i = MAX_SHARED_LIBS-1; i>0; i--) {
 if (libinfo[i].loaded) {
-/* Push previos first to call address */
+/* Push previous first to call address */
 --sp;
 if (put_user_ual(start_addr, sp))
 return -EFAULT;
diff --git a/linux-user/host/ppc64/safe-syscall.inc.S 
b/linux-user/host/ppc64/safe-syscall.inc.S
index 8ed73a5b86..875133173b 100644
--- a/linux-user/host/ppc64/safe-syscall.inc.S
+++ b/linux-user/host/ppc64/safe-syscall.inc.S
@@ -84,7 +84,7 @@ safe_syscall_end:
 
/* code path when we didn't execute the syscall */
 0: addi3, 0, -TARGET_ERESTARTSYS
-   ld 14, 16(1) /* restore r14 to its orginal value */
+   ld 14, 16(1) /* restore r14 to its original value */
blr
.cfi_endproc
 
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 55ac5c3208..897d20c076 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -481,7 +481,7 @@ _syscall4(int, sys_prlimit64, pid_t, pid, int, resource,
 
 
 #if defined(TARGET_NR_timer_create)
-/* Maxiumum of 32 active POSIX timers allowed at any one time. */
+/* Maximum of 32 active POSIX timers allowed at any one time. */
 static timer_t g_posix_timers[32] = { 0, } ;
 
 static inline int next_free_host_timer(void)
@@ -8180,7 +8180,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
 switch(num) {
 case TARGET_NR_exit:
 /* In old applications this may be used to implement _exit(2).
-   However in threaded applictions it is used for thread termination,
+   However in threaded applications it is used for thread termination,
and _exit_group is used for application termination.
Do thread termination if we have mor

Re: [PATCH 07/37] qapi: add pylintrc

2020-09-17 Thread Markus Armbruster
John Snow  writes:

> On 9/16/20 8:30 AM, Markus Armbruster wrote:
>> John Snow  writes:
>> 
>>> Add a skeleton pylintrc file. Right now, it ignores quite a few things.
>>> Files will be removed from the known-bad list throughout this and
>>> following series as they are repaired.
>>>
>>> Note: Normally, pylintrc would go in the folder above the module, but as
>>> that folder is shared by many things, it is going inside the module
>>> folder now.
>>>
>>> Due to some bugs in different versions of pylint (2.5.x), pylint does
>>> not correctly recognize when it is being run from "inside" a module, and
>>> must be run *outside* of the module.
>>>
>>> Therefore, to run it, you must:
>>>
>>>   > cd :/qemu/scripts
>> -bash: cd: :/qemu/scripts: No such file or directory
>> ;-P
>> 
>>>   > pylint qapi/ --rcfile=qapi/pylintrc
>> Why not
>> $ pylint scripts/qapi --rcfile=scripts/qapi/pylintrc
>> 
>
> No reason I'm aware of, I have just been testing with CWD at the
> scripts dir myself because of how python imports work.
>
> If it works this way, enjoy!

It works, and it simplifies the commmit message.

>>> Signed-off-by: John Snow 
>>> ---
>>>   scripts/qapi/pylintrc | 74 +++
>>>   1 file changed, 74 insertions(+)
>>>   create mode 100644 scripts/qapi/pylintrc
>>>
>>> diff --git a/scripts/qapi/pylintrc b/scripts/qapi/pylintrc
>>> new file mode 100644
>>> index 00..c2bbb8e8e1
>>> --- /dev/null
>>> +++ b/scripts/qapi/pylintrc
>>> @@ -0,0 +1,74 @@
>>> +[MASTER]
>>> +
>>> +# Add files or directories matching the regex patterns to the blacklist. 
>>> The
>>> +# regex matches against base names, not paths.
>>> +ignore-patterns=common.py,
>>> +doc.py,
>>> +error.py,
>>> +expr.py,
>>> +gen.py,
>>> +parser.py,
>>> +schema.py,
>>> +source.py,
>>> +types.py,
>>> +visit.py,
>> Already not ignored:
>>  __init__.py
>>  commands.py
>>  common.py
>>  debug.py
>>  events.py
>>  introspect.py
>>  script.py
>> Okay.
>> 
>>> +
>>> +
>>> +[MESSAGES CONTROL]
>>> +
>>> +# Disable the message, report, category or checker with the given id(s). 
>>> You
>>> +# can either give multiple identifiers separated by comma (,) or put this
>>> +# option multiple times (only on the command line, not in the configuration
>>> +# file where it should appear only once). You can also use "--disable=all" 
>>> to
>>> +# disable everything first and then reenable specific checks. For example, 
>>> if
>>> +# you want to run only the similarities checker, you can use "--disable=all
>>> +# --enable=similarities". If you want to run only the classes checker, but 
>>> have
>>> +# no Warning level messages displayed, use "--disable=all --enable=classes
>>> +# --disable=W".
>>> +disable=fixme,
>>> +missing-docstring,
>>> +too-many-arguments,
>>> +too-many-branches,
>>> +too-many-statements,
>>> +too-many-instance-attributes,
>> I'm fine with disabling these.
>> 
>
> I'd like to enable missing-docstring eventually, but that's not for today.

Understood.

>>> +
>>> +[REPORTS]
>>> +
>>> +[REFACTORING]
>>> +
>>> +[MISCELLANEOUS]
>>> +
>>> +[LOGGING]
>>> +
>>> +[BASIC]
>>> +
>>> +# Good variable names which should always be accepted, separated by a 
>>> comma.
>>> +good-names=i,
>>> +   j,
>>> +   k,
>>> +   ex,
>>> +   Run,
>>> +   _
>> Isn't this the default?
>> 
>
> Yes. I could omit it until I need to use good-names later on in the
> series, but I thought it would look odd to add the defaults at that
> point.
>
> So it's a minor bit of prescience here.

Matter of taste.  No objection.

>>> +
>>> +[VARIABLES]
>>> +
>>> +[STRING]
>>> +
>>> +[SPELLING]
>>> +
>>> +[FORMAT]
>>> +
>>> +[SIMILARITIES]
>>> +
>>> +# Ignore imports when computing similarities.
>>> +ignore-imports=yes
>> Why?
>> 
>
> We don't care if import statements are similar to those in other
> files. It's uninteresting entirely.
>
> (It matches on from typing import ... that exceed four lines, which I
> do regularly by the end of the series.)

What about something like

 # Ignore imports when computing similarities, because import
 # statements being similar is uninteresting entirely

>>> +
>>> +[TYPECHECK]
>>> +
>>> +[CLASSES]
>>> +
>>> +[IMPORTS]
>>> +
>>> +[DESIGN]
>>> +
>>> +[EXCEPTIONS]
>> Looks like you started with output of --generate-rcfile,
>> 
>
> I did,

Let's mention that in the commit message.  Education opportunity :)




[PATCH V3 08/10] disas/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the disas folder.

Signed-off-by: zhaolichang 
---
 disas/hppa.c | 2 +-
 disas/m68k.c | 8 
 disas/ppc.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/disas/hppa.c b/disas/hppa.c
index 2dbd1fc445..dcf9a47f34 100644
--- a/disas/hppa.c
+++ b/disas/hppa.c
@@ -2021,7 +2021,7 @@ print_insn_hppa (bfd_vma memaddr, disassemble_info *info)
fput_fp_reg (GET_FIELD (insn, 6, 10), info);
  break;
 
- /* 'fA' will not generate a space before the regsiter
+ /* 'fA' will not generate a space before the register
 name.  Normally that is fine.  Except that it
 causes problems with xmpyu which has no FP format
 completer.  */
diff --git a/disas/m68k.c b/disas/m68k.c
index 863409c67c..aefaecfbd6 100644
--- a/disas/m68k.c
+++ b/disas/m68k.c
@@ -70,7 +70,7 @@ struct floatformat
   unsigned int exp_start;
   unsigned int exp_len;
   /* Bias added to a "true" exponent to form the biased exponent.  It
- is intentionally signed as, otherwize, -exp_bias can turn into a
+ is intentionally signed as, otherwise, -exp_bias can turn into a
  very large number (e.g., given the exp_bias of 0x3fff and a 64
  bit long, the equation (long)(1 - exp_bias) evaluates to
  4294950914) instead of -16382).  */
@@ -479,7 +479,7 @@ struct m68k_opcode_alias
   and remaining 3 bits of register shifted 9 bits in first word.
   Indicate upper/lower in 1 bit shifted 7 bits in second word.
   Use with `R' or `u' format.
-   n  `m' withouth upper/lower indication. (For M[S]ACx; 4 bits split
+   n  `m' without upper/lower indication. (For M[S]ACx; 4 bits split
   with MSB shifted 6 bits in first word and remaining 3 bits of
   register shifted 9 bits in first word.  No upper/lower
   indication is done.)  Use with `R' or `u' format.
@@ -854,7 +854,7 @@ fetch_arg (unsigned char *buffer,
 
 /* Check if an EA is valid for a particular code.  This is required
for the EMAC instructions since the type of source address determines
-   if it is a EMAC-load instruciton if the EA is mode 2-5, otherwise it
+   if it is a EMAC-load instruction if the EA is mode 2-5, otherwise it
is a non-load EMAC instruction and the bits mean register Ry.
A similar case exists for the movem instructions where the register
mask is interpreted differently for different EAs.  */
@@ -1080,7 +1080,7 @@ print_indexed (int basereg,
 
 /* Returns number of bytes "eaten" by the operand, or
return -1 if an invalid operand was found, or -2 if
-   an opcode tabe error was found.
+   an opcode table error was found.
ADDR is the pc for this arg to be relative to.  */
 
 static int
diff --git a/disas/ppc.c b/disas/ppc.c
index 63e97cfe1d..02be878198 100644
--- a/disas/ppc.c
+++ b/disas/ppc.c
@@ -5226,7 +5226,7 @@ operand_value_powerpc (const struct powerpc_operand 
*operand,
   if ((operand->flags & PPC_OPERAND_SIGNED) != 0)
{
  /* BITM is always some number of zeros followed by some
-number of ones, followed by some numer of zeros.  */
+number of ones, followed by some number of zeros.  */
  unsigned long top = operand->bitm;
  /* top & -top gives the rightmost 1 bit, so this
 fills in any trailing zeros.  */
-- 
2.26.2.windows.1




Re: [PATCH v2] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread Thomas Huth
On 17/09/2020 10.02, Thomas Huth wrote:
> On 17/09/2020 09.47, Philippe Mathieu-Daudé wrote:
>> On 9/17/20 9:43 AM, Thomas Huth wrote:
>>> GCC 9.3.0 on Ubuntu complains:
>>>
>>> In file included from /usr/include/string.h:495,
>>>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>>>  from ../migration/global_state.c:13:
>>> In function ‘strncpy’,
>>> inlined from ‘global_state_store_running’ at 
>>> ../migration/global_state.c:47:5:
>>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
>>>  ‘__builtin_strncpy’ specified bound 100 equals destination size 
>>> [-Werror=stringop-truncation]
>>>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
>>> (__dest));
>>>   |  
>>> ^~
>>>
>>> ... but we apparently really want to do a strncpy here - the size is already
>>> checked with the assert() statement right in front of it. To silence the
>>> warning, simply replace it with our strpadcpy() function.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>  v2: Use strpadcpy instead of QEMU_NONSTRING (and yes, this time it seems
>>>  to really silence the compiler warning :-))
>>>
>>>  migration/global_state.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/migration/global_state.c b/migration/global_state.c
>>> index 25311479a4..a33947ca32 100644
>>> --- a/migration/global_state.c
>>> +++ b/migration/global_state.c
>>> @@ -44,8 +44,8 @@ void global_state_store_running(void)
>>>  {
>>>  const char *state = RunState_str(RUN_STATE_RUNNING);
>>>  assert(strlen(state) < sizeof(global_state.runstate));
>>> -strncpy((char *)global_state.runstate,
>>> -   state, sizeof(global_state.runstate));
>>> +strpadcpy((char *)global_state.runstate, sizeof(global_state.runstate),
>>> +  state, '\0');
>>
>> https://www.mail-archive.com/qemu-block@nongnu.org/msg44925.html
>> ;)
> 
> Oh, well :-) ... but why did you never pushed to get that merged?

Hmm, commit 0a5526a18b0245dfa20a9fe453b2a9af3125d175 was supposed to fix
it already ... but apparently, that does not work with GCC 9.3 ?

 Thomas




[PATCH V3 09/10] qapi/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the qapi folder.

Signed-off-by: zhaolichang 
Reviewed-by: Markus Armbruster 
---
 qapi/block-core.json | 4 ++--
 qapi/crypto.json | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 2d94873ca0..3c16f1e11d 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1795,7 +1795,7 @@
 #
 # @block-backend: corresponds to BlockBackend
 #
-# @block-job: corresonds to BlockJob
+# @block-job: corresponds to BlockJob
 #
 # @block-driver: corresponds to BlockDriverState
 #
@@ -2067,7 +2067,7 @@
 # @target: name of the destination dirty bitmap
 #
 # @bitmaps: name(s) of the source dirty bitmap(s) at @node and/or fully
-#   specifed BlockDirtyBitmap elements. The latter are supported
+#   specified BlockDirtyBitmap elements. The latter are supported
 #   since 4.1.
 #
 # Since: 4.0
diff --git a/qapi/crypto.json b/qapi/crypto.json
index bb7930d332..2aebe6fa20 100644
--- a/qapi/crypto.json
+++ b/qapi/crypto.json
@@ -336,7 +336,7 @@
 # written into added active keyslots
 #
 # @old-secret:Optional (for deactivation only)
-# If given will deactive all keyslots that
+# If given will deactivate all keyslots that
 # match password located in QCryptoSecret with this ID
 #
 # @iter-time: Optional (for activation only)
@@ -354,7 +354,7 @@
 # keyslot to deactivate
 #
 # @secret:Optional. The ID of a QCryptoSecret object providing the
-# password to use to retrive current master key.
+# password to use to retrieve current master key.
 # Defaults to the same secret that was used to open the image
 #
 #
-- 
2.26.2.windows.1




[PATCH V3 10/10] contrib/: fix some comment spelling errors

2020-09-17 Thread zhaolichang
I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the contrib folder.

Signed-off-by: zhaolichang 
Reviewed-by: Alex Bennee 
---
 contrib/gitdm/filetypes.txt | 6 +++---
 contrib/ivshmem-client/ivshmem-client.h | 2 +-
 contrib/libvhost-user/libvhost-user.c   | 4 ++--
 contrib/libvhost-user/libvhost-user.h   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/contrib/gitdm/filetypes.txt b/contrib/gitdm/filetypes.txt
index 9e9c505205..d2d6f6db8d 100644
--- a/contrib/gitdm/filetypes.txt
+++ b/contrib/gitdm/filetypes.txt
@@ -22,7 +22,7 @@
 # in the gitdm sample-config directory.
 #
 # This file contains associations parameters regarding filetypes
-# (documentation, develompent, multimedia, images...)
+# (documentation, development, multimedia, images...)
 #
 # format:
 # filetype   []
@@ -59,8 +59,8 @@ filetype code \.s$# Assembly
 filetype code \.S$ # Assembly
 filetype code \.asm$   # Assembly
 filetype code \.awk$   # awk
-filetype code ^common$  # script fragements
-filetype code ^common.*$  # script fragements
+filetype code ^common$  # script fragments
+filetype code ^common.*$  # script fragments
 filetype code (qom|qmp)-\w+$  # python script fragments
 
 #
diff --git a/contrib/ivshmem-client/ivshmem-client.h 
b/contrib/ivshmem-client/ivshmem-client.h
index fe3cc4a03d..fc45a38060 100644
--- a/contrib/ivshmem-client/ivshmem-client.h
+++ b/contrib/ivshmem-client/ivshmem-client.h
@@ -174,7 +174,7 @@ int ivshmem_client_notify_all_vects(const IvshmemClient 
*client,
 const IvshmemClientPeer *peer);
 
 /**
- * Broadcat a notification to all vectors of all peers
+ * Broadcast a notification to all vectors of all peers
  *
  * @client: The ivshmem client
  *
diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index 53f16bdf08..9d30ff2283 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -684,7 +684,7 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
 
 /*
  * If we are in postcopy mode and we receive a u64 payload with a 0 value
- * we know all the postcopy client bases have been recieved, and we
+ * we know all the postcopy client bases have been received, and we
  * should start generating faults.
  */
 if (track_ramblocks &&
@@ -973,7 +973,7 @@ vu_set_mem_table_exec(VuDev *dev, VhostUserMsg *vmsg)
 for (i = 0; i < dev->max_queues; i++) {
 if (dev->vq[i].vring.desc) {
 if (map_ring(dev, &dev->vq[i])) {
-vu_panic(dev, "remaping queue %d during setmemtable", i);
+vu_panic(dev, "remapping queue %d during setmemtable", i);
 }
 }
 }
diff --git a/contrib/libvhost-user/libvhost-user.h 
b/contrib/libvhost-user/libvhost-user.h
index 844c37c648..287ac5fec7 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -424,7 +424,7 @@ typedef struct VuVirtqElement {
  * @remove_watch: a remove_watch callback
  * @iface: a VuDevIface structure with vhost-user device callbacks
  *
- * Intializes a VuDev vhost-user context.
+ * Initializes a VuDev vhost-user context.
  *
  * Returns: true on success, false on failure.
  **/
-- 
2.26.2.windows.1




Re: [PATCH v6 00/12] i440fx/acpi: addition of feature and bug fixes.

2020-09-17 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20200917074733.13612-1-...@anisinha.ca/



Hi,

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

N/A. Internal error while reading log file



The full log is available at
http://patchew.org/logs/20200917074733.13612-1-...@anisinha.ca/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH V9 6/6] hw/mips: Add Loongson-3 machine support

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/16/20 12:47 PM, Philippe Mathieu-Daudé wrote:
> On 9/16/20 11:49 AM, Huacai Chen wrote:
>> On Wed, Sep 16, 2020 at 3:56 PM Philippe Mathieu-Daudé  
>> wrote:
>>> On 9/16/20 4:12 AM, Huacai Chen wrote:
> [...]
 +static void mips_loongson3_virt_init(MachineState *machine)
 +{
 +int i;
 +long bios_size;
 +MIPSCPU *cpu;
 +CPUMIPSState *env;
 +DeviceState *liointc;
 +char *filename;
 +const char *kernel_cmdline = machine->kernel_cmdline;
 +const char *kernel_filename = machine->kernel_filename;
 +const char *initrd_filename = machine->initrd_filename;
 +ram_addr_t ram_size = machine->ram_size;
 +MemoryRegion *address_space_mem = get_system_memory();
 +MemoryRegion *ram = g_new(MemoryRegion, 1);
 +MemoryRegion *bios = g_new(MemoryRegion, 1);
 +MemoryRegion *iomem = g_new(MemoryRegion, 1);
 +
 +/* TODO: TCG will support all CPU types */
 +if (!kvm_enabled()) {
 +if (!machine->cpu_type) {
 +machine->cpu_type = MIPS_CPU_TYPE_NAME("Loongson-3A1000");
 +}
 +if (!strstr(machine->cpu_type, "Loongson-3A1000")) {
 +error_report("Loongson-3/TCG need cpu type Loongson-3A1000");
 +exit(1);
 +}
 +} else {
 +if (!machine->cpu_type) {
 +machine->cpu_type = MIPS_CPU_TYPE_NAME("Loongson-3A4000");
 +}
 +if (!strstr(machine->cpu_type, "Loongson-3A4000")) {
 +error_report("Loongson-3/KVM need cpu type Loongson-3A4000");
 +exit(1);
 +}
 +}
 +
 +if (ram_size < 512 * MiB) {
 +error_report("Loongson-3 need at least 512MB memory");
>>>
>>> Typo "needs", but why?
>> Though you told me "QEMU shouldn't assume anything about the guest",
>> but Loongson-3 machine really need at least 512M memory. And as you
>> said, this can simplify the memsize/highmemsize process (always larger
>> than 256).
> 
> OK, that's fine.
> 
>>
>>>
 +exit(1);
 +}
 +
 +/*
 + * The whole MMIO range among configure registers doesn't generate
 + * exception when accessing invalid memory. Create an empty slot to
 + * emulate this feature.
 + */
 +empty_slot_init("fallback", 0, 0x8000);
>>>
>>> Again, this doesn't look correct (no comment in my previous review).
>> This is written by Jiaxun because this is only needed by TCG, and he
>> said that malta also uses empty_slot_init() here.
> 
> IIRC for Malta this is a GT64120 specific hole.
> 
> In this case I'd like to know the justification first.
> Maybe you want to add this hole in the LOONGSON_LIOINTC device...

Which makes me also wonder why are you splitting out 256MB of the RAM?

This was a physical restriction of the GT64120 on 32-bit targets.
Your hardware is virtual and 64-bit...



Re: [PATCH V9 6/6] hw/mips: Add Loongson-3 machine support

2020-09-17 Thread Philippe Mathieu-Daudé
On 9/16/20 11:49 AM, Huacai Chen wrote:
>>> We now already have a full functional Linux kernel (based on Linux-5.4.x
>>> LTS, the kvm host side and guest side have both been upstream for Linux-
>>> 5.9, but Linux-5.9 has not been released yet) here:
>>>
>>> https://github.com/chenhuacai/linux
>>>
>>> Of course the upstream kernel is also usable (though it is "unstable"
>>> now):
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>
>>> How to use QEMU/Loongson-3?
>>> 1, Download kernel source from the above URL;
>>> 2, Build a kernel with arch/mips/configs/loongson3_defconfig;
>>> 3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
>>> 4, Build QEMU-master with this patchset;
>>
>> Which produces all the following errors:
>>
>> hw/mips/loongson3_virt.c: In function 'get_cpu_freq':
>> hw/mips/loongson3_virt.c:372:12: error: variable 'freq_reg' has
>> initializer but incomplete type
>>  struct kvm_one_reg freq_reg = {
>> ^
>> hw/mips/loongson3_virt.c:373:9: error: unknown field 'id' specified in
>> initializer
>>  .id = KVM_REG_MIPS_COUNT_HZ,
>>  ^
>> hw/mips/loongson3_virt.c:373:15: error: 'KVM_REG_MIPS_COUNT_HZ'
>> undeclared (first use in this function)
>>  .id = KVM_REG_MIPS_COUNT_HZ,
>>^
> I don't know how to reproduce these errors, struct kvm_one_reg and
> KVM_REG_MIPS_COUNT_HZ are both defined..., could you please tell me?
> My build steps are like this:
> mkdir build
> cd build
> ../configure
> make

Building on Ubuntu 20.04.

C compiler for the host machine: cc (gcc 9.3.0 "cc (Ubuntu
9.3.0-10ubuntu2) 9.3.0")
C linker for the host machine: cc ld.bfd 2.34



Re: [PATCH 06/37] qapi: delint using flake8

2020-09-17 Thread Markus Armbruster
John Snow  writes:

> On 9/16/20 8:12 AM, Markus Armbruster wrote:
>> John Snow  writes:
>> 
>>> Petty style guide fixes and line length enforcement.  Not a big win, not
>>> a big loss, but flake8 passes 100% on the qapi module, which gives us an
>>> easy baseline to enforce hereafter.
>>>
>>> Signed-off-by: John Snow 
>>> ---
>>>   scripts/qapi/.flake8 |  2 ++
>>>   scripts/qapi/commands.py |  3 ++-
>>>   scripts/qapi/schema.py   |  8 +---
>>>   scripts/qapi/visit.py| 15 ++-
>>>   4 files changed, 19 insertions(+), 9 deletions(-)
>>>   create mode 100644 scripts/qapi/.flake8
>>>
>>> diff --git a/scripts/qapi/.flake8 b/scripts/qapi/.flake8
>>> new file mode 100644
>>> index 00..45d8146f3f
>>> --- /dev/null
>>> +++ b/scripts/qapi/.flake8
>>> @@ -0,0 +1,2 @@
>>> +[flake8]
>>> +extend-ignore = E722  # Pylint handles this, but smarter.
>> I guess you mean pylint's W0702 a.k.a. bare-except.  What's wrong
>> with
>> flake8's E722 compared to pylint's W0702?
>> 
>
> Flake8 will warn on *any* bare except, but Pylint's is context-aware
> and will suppress the warning if you re-raise the exception.

Should this information be worked into the comment?

> I don't actually think this comes up in the qapi code base, but it
> does come up in the ./python/qemu code base.
>
> (One of my goals is unifying the lint checking regime for both packages.)
>
>>> \ No newline at end of file
>> So put one there :)
>> 
>
> Whupps, okay.
>
>>> diff --git a/scripts/qapi/commands.py b/scripts/qapi/commands.py
>>> index e1df0e341f..2e4b4de0fa 100644
>>> --- a/scripts/qapi/commands.py
>>> +++ b/scripts/qapi/commands.py
>>> @@ -69,7 +69,8 @@ def gen_call(name, arg_type, boxed, ret_type):
>>>   def gen_marshal_output(ret_type):
>>>   return mcgen('''
>>>   -static void qmp_marshal_output_%(c_name)s(%(c_type)s ret_in,
>>> QObject **ret_out, Error **errp)
>>> +static void qmp_marshal_output_%(c_name)s(%(c_type)s ret_in, QObject 
>>> **ret_out,
>>> +  Error **errp)
>> The continued parameter list may become misalignd in generated C.
>> E.g.
>>  static void qmp_marshal_output_BlockInfoList(BlockInfoList
>> *ret_in, QObject **ret_out,
>>Error **errp)
>>  {
>>  ...
>>  }
>> Do we care?
>> 
>
> Yeah, I don't know. Do we?

I care, but I also care for automated style checks.

> It actually seemed more annoying to try and get flake8 to make an
> exception for these handful of examples.
>
> Path of least resistance led me here, but I can try and appease both
> systems if you'd prefer.

Up to now, I ran the style checkers manually, and this was just one of
several complaints to ignore, so I left the code alone.

If it gets in the way of running them automatically, and messing up the
generated code slightly is the easiest way to get it out of the way,
then I can accept the slight mess.

>> More of the same below.
>> 
>>>   {
>>>   Visitor *v;
>>>   
>> [...]
>> 




Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions

2020-09-17 Thread Zhenyu Ye
Hi Daniel,

On 2020/9/14 22:42, Daniel P. Berrangé wrote:
> On Tue, Aug 11, 2020 at 09:54:08PM +0800, Zhenyu Ye wrote:
>> Hi Kevin,
>>
>> On 2020/8/10 23:38, Kevin Wolf wrote:
>>> Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
 Before doing qmp actions, we need to lock the qemu_global_mutex,
 so the qmp actions should not take too long time.

 Unfortunately, some qmp actions need to acquire aio context and
 this may take a long time.  The vm will soft lockup if this time
 is too long.
>>>
>>> Do you have a specific situation in mind where getting the lock of an
>>> AioContext can take a long time? I know that the main thread can
>>> block for considerable time, but QMP commands run in the main thread, so
>>> this patch doesn't change anything for this case. It would be effective
>>> if an iothread blocks, but shouldn't everything running in an iothread
>>> be asynchronous and therefore keep the AioContext lock only for a short
>>> time?
>>>
>>
>> Theoretically, everything running in an iothread is asynchronous. However,
>> some 'asynchronous' actions are not non-blocking entirely, such as
>> io_submit().  This will block while the iodepth is too big and I/O pressure
>> is too high.  If we do some qmp actions, such as 'info block', at this time,
>> may cause vm soft lockup.  This series can make these qmp actions safer.
>>
>> I constructed the scene as follow:
>> 1. create a vm with 4 disks, using iothread.
>> 2. add press to the CPU on the host.  In my scene, the CPU usage exceeds 95%.
>> 3. add press to the 4 disks in the vm at the same time.  I used the fio and
>> some parameters are:
>>
>>   fio -rw=randrw -bs=1M -size=1G -iodepth=512 -ioengine=libaio -numjobs=4
>>
>> 4. do block query actions, for example, by virsh:
>>
>>  virsh qemu-monitor-command [vm name] --hmp info block
>>
>> Then the vm will soft lockup, the calltrace is:
> 
> [snip]
> 
>> This problem can be avoided after this series applied.
> 
> At what cost though ?   With this timeout, QEMU is going to start
> reporting bogus failures for various QMP commands when running
> under high load, even if those commands would actually run
> successfully.  This will turn into an error report from libvirt
> which will in turn probably cause an error in the mgmt application
> using libvirt, and in turn could break the user's automation.
> 

I think it's worth reporting an error to avoid the VM softlockup.
The VM may even crash if kernel.softlockup_panic is configured!

We can increase the timeout value (close to the VM cpu soft lock time)
to avoid unnecessary errors.

Thanks,
Zhenyu



RE: [PATCH 3/5] qom: Remove module_obj_name parameter from OBJECT_DECLARE* macros

2020-09-17 Thread Paul Durrant
> -Original Message-
> From: Eduardo Habkost 
> Sent: 16 September 2020 19:25
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange 
> ; Marc-André Lureau
> ; Gerd Hoffmann ; Michael S. 
> Tsirkin ;
> Peter Maydell ; Corey Minyard 
> ; Cédric Le Goater
> ; David Gibson ; Cornelia Huck 
> ; Thomas
> Huth ; Halil Pasic ; Christian 
> Borntraeger
> ; Philippe Mathieu-Daudé ; Alistair 
> Francis
> ; David Hildenbrand ; Laurent 
> Vivier ;
> Amit Shah ; Stefano Stabellini ; 
> Anthony Perard
> ; Paul Durrant ; Fam Zheng 
> ; Gonglei (Arei)
> ; Igor Mammedov ; Stefan Berger 
> ;
> Richard Henderson ; Michael Rolnik ; 
> Sarah Harris
> ; Edgar E. Iglesias ; 
> Michael Walle
> ; Aleksandar Markovic ; 
> Aurelien Jarno
> ; Jiaxun Yang ; Aleksandar 
> Rikalo
> ; Anthony Green ; Chris 
> Wulff ;
> Marek Vasut ; Stafford Horne ; Palmer 
> Dabbelt ;
> Sagar Karandikar ; Bastian Koppelmann 
> ;
> Yoshinori Sato ; Mark Cave-Ayland 
> ; Artyom
> Tarasenko ; Guan Xuetao ; Max 
> Filippov ;
> qemu-...@nongnu.org; qemu-...@nongnu.org; qemu-s3...@nongnu.org; 
> qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; qemu-ri...@nongnu.org
> Subject: [PATCH 3/5] qom: Remove module_obj_name parameter from 
> OBJECT_DECLARE* macros
> 
> One of the goals of having less boilerplate on QOM declarations
> is to avoid human error.  Requiring an extra argument that is
> never used is an opportunity for mistakes.
> 
> Remove the unused argument from OBJECT_DECLARE_TYPE and
> OBJECT_DECLARE_SIMPLE_TYPE.
> 
> Coccinelle patch used to convert all users of the macros:
> 
>   @@
>   declarer name OBJECT_DECLARE_TYPE;
>   identifier InstanceType, ClassType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_TYPE(InstanceType, ClassType,
>   -lowercase,
>UPPERCASE);
> 
>   @@
>   declarer name OBJECT_DECLARE_SIMPLE_TYPE;
>   identifier InstanceType, lowercase, UPPERCASE;
>   @@
>OBJECT_DECLARE_SIMPLE_TYPE(InstanceType,
>   -lowercase,
>UPPERCASE);
> 
> Signed-off-by: Eduardo Habkost 

Acked-by: Paul Durrant 




Re: [RFC PATCH 05/12] hw/arm/virt: DT: add cpu-map

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:26AM +0800, Ying Fang wrote:
> From: Andrew Jones 
> 
> Support devicetree CPU topology descriptions.
> 
> Signed-off-by: Andrew Jones 

There's a new version of this patch on the refresh branch.
https://github.com/rhdrjones/qemu/commits/virt-cpu-topology-refresh

drew




RE: [PATCH 4/5] [automated] Use OBJECT_DECLARE_TYPE when possible

2020-09-17 Thread Paul Durrant
> -Original Message-
> From: Eduardo Habkost 
> Sent: 16 September 2020 19:25
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange 
> ; Peter Maydell
> ; Andrzej Zaborowski ; Alistair 
> Francis
> ; Kevin Wolf ; Max Reitz 
> ; Mark Cave-
> Ayland ; David Gibson 
> ; Richard Henderson
> ; David Hildenbrand ; Cornelia Huck 
> ; Thomas
> Huth ; Halil Pasic ; Christian 
> Borntraeger
> ; Michael S. Tsirkin ; Fam Zheng 
> ; Dmitry
> Fleytman ; Gerd Hoffmann ; 
> Marc-André Lureau
> ; Cédric Le Goater ; Andrew 
> Jeffery ; Joel
> Stanley ; Andrew Baumann ; 
> Philippe Mathieu-Daudé
> ; Eric Auger ; Marcel Apfelbaum 
> ;
> Laurent Vivier ; Sergio Lopez ; John Snow 
> ; Xiao
> Guangrong ; Peter Chubb 
> ; Beniamino Galvani
> ; Edgar E. Iglesias ; Stefano 
> Stabellini
> ; Anthony Perard ; Paul 
> Durrant ;
> Jason Wang ; qemu-...@nongnu.org; qemu-bl...@nongnu.org; 
> qemu-...@nongnu.org;
> qemu-s3...@nongnu.org; xen-de...@lists.xenproject.org
> Subject: [PATCH 4/5] [automated] Use OBJECT_DECLARE_TYPE when possible
> 
> This converts existing DECLARE_OBJ_CHECKERS usage to
> OBJECT_DECLARE_TYPE when possible.
> 
>  $ ./scripts/codeconverter/converter.py -i \
>--pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')
> 
> Signed-off-by: Eduardo Habkost 

Acked-by: Paul Durrant 




Re: [REPORT] Nightly Performance Tests - Wednesday, September 16, 2020

2020-09-17 Thread Ahmed Karaman
On Thu, Sep 17, 2020 at 12:07 AM Ahmed Karaman
 wrote:
>
> Host CPU : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
> Host Memory  : 15.49 GB
>
> Start Time (UTC) : 2020-09-16 21:35:02
> End Time (UTC)   : 2020-09-16 22:07:32
> Execution Time   : 0:32:29.941492
>
> Status   : SUCCESS
>
> Note:
> Changes denoted by '-' are less than 0.01%.
>
> 
> SUMMARY REPORT - COMMIT 8ee61272
> 
> AVERAGE RESULTS
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch642 158 513 150   - +1.703%
> alpha  1 914 947 541   - +3.522%
> arm8 076 527 003   - +2.308%
> hppa   4 261 673 329   - +3.163%
> m68k   2 690 293 359   - +7.134%
> mips   1 861 902 263   - +2.484%
> mipsel 2 008 240 685   - +2.676%
> mips64 1 918 624 648   - +2.817%
> mips64el   2 051 554 799   - +3.025%
> ppc2 480 174 328   - +3.109%
> ppc64  2 576 701 038   - +3.142%
> ppc64le2 558 820 807   - +3.171%
> riscv641 406 685 833   - +2.648%
> s390x  3 158 140 071   - +3.119%
> sh42 364 606 066   - +3.341%
> sparc643 318 698 928   - +3.855%
> x86_64 1 775 941 661   - +2.167%
> 
>
>DETAILED RESULTS
> 
> Test Program: dijkstra_double
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch643 062 745 624   - +1.429%
> alpha  3 191 842 908   - +3.695%
> arm   16 357 299 506   - +2.348%
> hppa   7 228 387 843   - +3.086%
> m68k   4 294 056 834   - +9.693%
> mips   3 051 314 790   - +2.423%
> mipsel 3 231 546 887   -  +2.87%
> mips64 3 245 814 633   - +2.596%
> mips64el   3 414 215 768   - +3.021%
> ppc4 914 556 467   -  +4.74%
> ppc64  5 098 137 458   - +4.565%
> ppc64le5 082 383 704   - +4.579%
> riscv642 192 269 006   - +1.954%
> s390x  4 584 587 692   - +2.898%
> sh43 949 197 667   - +3.468%
> sparc644 586 104 947   - +4.235%
> x86_64 2 484 245 797   - +1.757%
> 
> 
> Test Program: dijkstra_int32
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch642 210 360 293   - +1.501%
> alpha  1 494 111 691   - +2.149%
> arm8 263 044 506   - +2.667%
> hppa   5 207 306 045   - +3.047%
> m68k   1 725 880 564   - +2.528%
> mips   1 495 110 368   - +1.484%
> mipsel 1 497 169 328   - +1.481%
> mips64 1 715 421 334   - +1.894%
> mips64el   1 695 209 677   - +1.909%
> ppc2 014 602 126   - +1.822%
> ppc64  2 206 256 217   - +2.138%
> ppc64le2 197 967 863   - +2.145%
> riscv641 354 884 068   - +2.394%
> s390x  2 916 098 604   - +1.236%
> sh41 990 693 666   - +2.678%
> sparc642 874 142 164   - +3.827%
> x86_64 1 554 138 606   -  +2.13%
> 
> 
> Test Program: matmult_double
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch641 412 417 224   - +0.312%
> alpha  3 233 972 467   - +7.473%
> arm8 545 300 144   -  +1.09%
> hppa   3 483 516 785   - +

Use patchew to push successfully applied series to GitLab

2020-09-17 Thread Philippe Mathieu-Daudé
Hi,

patchew is currently pushing successfully applied series
(using the cover Message-ID as tag) to GitHub.
This is very handy (no need to apply patches manually):
https://github.com/patchew-project/qemu/tags

Can we push the same that to an equivalent GitLab account?
We could then have a script replying to the series if the
series fails CI. Doing so would save reviewer/tester time
(I'd rather have a series not failing on our CI tests before
starting to review/test it).

Thoughts?

Thanks,

Phil.




Re: [RFC PATCH 03/12] target/arm/kvm32: make MPIDR consistent with CPU Topology

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:24AM +0800, Ying Fang wrote:
> MPIDR helps to provide an additional PE identification in a multiprocessor
> system. This patch adds support for setting MPIDR from userspace, so that
> MPIDR is consistent with CPU topology configured.
> 
> Signed-off-by: Ying Fang 
> ---
>  target/arm/kvm32.c | 46 ++
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
> index 0af46b41c8..85694dc8bf 100644
> --- a/target/arm/kvm32.c
> +++ b/target/arm/kvm32.c

This file no longer exists in mainline. Please rebase the whole series.

Thanks,
drew




Re: [PATCH V3 00/10] fix some comment spelling errors

2020-09-17 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20200917075029.313-1-zhaolich...@huawei.com/



Hi,

This series failed build test on FreeBSD host. Please find the details below.






The full log is available at
http://patchew.org/logs/20200917075029.313-1-zhaolich...@huawei.com/testing.FreeBSD/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [RFC PATCH 06/12] hw/arm/virt-acpi-build: distinguish possible and present cpus

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:27AM +0800, Ying Fang wrote:
> When building ACPI tables regarding CPUs we should always build
> them for the number of possible CPUs, not the number of present
> CPUs. We then ensure only the present CPUs are enabled.
> 
> Signed-off-by: Andrew Jones 
> Signed-off-by: Ying Fang 
> ---
>  hw/arm/virt-acpi-build.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)

I approached this in a different way in the refresh, so the this patch
was dropped, but the refresh is completely untested, so something similar
may still be necessary.

Thanks,
drew




Re: [PATCH V9 0/6] mips: Add Loongson-3 machine support

2020-09-17 Thread Aleksandar Markovic
On Wednesday, September 16, 2020, Huacai Chen  wrote:

> Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
> R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, while
> Loongson-3A R4 is the newest and its ISA is almost the superset of all
> others. To reduce complexity, in QEMU we just define two CPU types:
>
> 1, "Loongson-3A1000" CPU which is corresponding to Loongson-3A R1. It is
>suitable for TCG because Loongson-3A R1 has fewest ASE.
> 2, "Loongson-3A4000" CPU which is corresponding to Loongson-3A R4. It is
>suitable for KVM because Loongson-3A R4 has the VZ ASE.
>
> Loongson-3 lacks English documents. I've tried to translated them with
> translate.google.com, and the machine translated documents (together
> with their original Chinese versions) are available here.
>
> Loongson-3A R1 (Loongson-3A1000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A1000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P1.pdf
> (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A1000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P2.pdf
> (Chinese Version)
>
> Loongson-3A R2 (Loongson-3A2000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A2000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A2000_user1.pdf (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A2000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A2000_user2.pdf (Chinese Version)
>
> Loongson-3A R3 (Loongson-3A3000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A3000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual1.pdf
> (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A3000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual2.pdf
> (Chinese Version)
>
> Loongson-3A R4 (Loongson-3A4000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A4000_p1.pdf
> http://ftp.godson.ac.cn/lemote/3A4000user.pdf (Chinese Version)
> User Manual Part 2:
> I'm sorry that it is unavailable now.
>
> And human-translated documents (W.I.P) are available here now:
> https://github.com/loongson-community/docs/tree/master/
> English-translation-of-Loongson-manual
>
> Both KVM and TCG are available now!
>
> We now already have a full functional Linux kernel (based on Linux-5.4.x
> LTS, the kvm host side and guest side have both been upstream for Linux-
> 5.9, but Linux-5.9 has not been released yet) here:
>
> https://github.com/chenhuacai/linux
>
> Of course the upstream kernel is also usable (though it is "unstable"
> now):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> How to use QEMU/Loongson-3?
> 1, Download kernel source from the above URL;
> 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> 3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
> 4, Build QEMU-master with this patchset;
> 5, modprobe kvm (only necessary for KVM mode);
> 6, Use QEMU with TCG:
>qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu
> Loongson-3A1000 -kernel  -append ...
>Use QEMU with KVM:
>qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu
> Loongson-3A4000 -kernel  -append ...
>
>The "-cpu" parameter is optional here and QEMU will use the correct
> type for TCG/KVM automatically.
>
> V1 -> V2:
> 1, Add a cover letter;
> 2, Improve CPU definitions;
> 3, Remove LS7A-related things (Use GPEX instead);
> 4, Add a description of how to run QEMU/Loongson-3.
>
> V2 -> V3:
> 1, Fix all possible checkpatch.pl errors and warnings.
>
> V3 -> V4:
> 1, Sync code with upstream;
> 2, Remove merged patches;
> 3, Fix build failure without CONFIG_KVM;
> 4, Add Reviewed-by: Aleksandar Markovic .
>
> V4 -> V5:
> 1, Improve coding style;
> 2, Remove merged patches;
> 3, Rename machine name from "loongson3" to "loongson3-virt";
> 4, Rework the "loongson3-virt" machine to drop any ISA things;
> 5, Rework "hw/mips: Implement the kvm_type() hook in MachineClass";
> 6, Add Jiaxun Yang as a reviewer of Loongson-3.
>
> V5 -> V6:
> 1, Fix license preamble;
> 2, Improve commit messages;
> 3, Add hw/intc/loongson_liointc.c to MAINTAINERS;
> 4, Fix all possible checkpatch.pl errors and warnings.
>
> V7 and V8 have only one patch (machine definition) with some minor
> improvements.
>
> V8 -> V9:
> 1, Update KVM type definition from kernel;
> 2, Fix PageMask with variable page size for TCG;
> 3, Add TCG support (add Loongson-EXT instructions).
>
> Huacai Chen and Jiaxun Yang (6):
>  linux-headers: Update MIPS KVM type defintition
>  target/mips: Fix PageMask with variable page size
>  target/mips: Add loongson-ext lswc2 group of instructions (Part 1)
>  target/mips: Add loongson-ext lswc2 group of instructions (Part 2)
>  target/mips: Add loongson-ext lsdc2 group of instructions
>  hw/mips: Add Loongson-3 machine support
>
> Signed-off-by: Huacai Chen 
> ---
>  default-configs/mips64el-softmmu.mak |

Re: [PATCH 09/37] qapi/common.py: Add indent manager

2020-09-17 Thread Markus Armbruster
John Snow  writes:

> On 9/16/20 11:13 AM, Markus Armbruster wrote:
>> John Snow  writes:
>> 
>>> Code style tools really dislike the use of global keywords, because it
>>> generally involves re-binding the name at runtime which can have strange
>>> effects depending on when and how that global name is referenced in
>>> other modules.
>>>
>>> Make a little indent level manager instead.
>>>
>>> Signed-off-by: John Snow 
>>> ---
>>>   scripts/qapi/common.py | 50 +-
>>>   scripts/qapi/visit.py  |  7 +++---
>>>   2 files changed, 38 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
>>> index 4fb265a8bf..87d87b95e5 100644
>>> --- a/scripts/qapi/common.py
>>> +++ b/scripts/qapi/common.py
>>> @@ -93,33 +93,53 @@ def c_name(name, protect=True):
>>>   pointer_suffix = ' *' + eatspace
>>> 
>>> -def genindent(count):
>>> -ret = ''
>>> -for _ in range(count):
>>> -ret += ' '
>>> -return ret
>>> +class Indent:
>> Since this class name will be used just once...  Indentation or
>> IndentationManager?
>> 
>
> Indentation is fine, if you'd like. IndentationManager makes me feel
> ashamed for writing this patch, like I am punishing myself with Java.

Hah!  Point taken.

>>> +"""
>>> +Indent-level management.
>>>   +:param initial: Initial value, default 0.
>> The only caller passes 0.
>> Let's drop the parameter, and hardcode the default initial value
>> until
>> we have an actual use for another initial value.
>> 
>
> The parameter is nice because it gives meaning to the output of
> repr(), see below.
>
>>> +"""
>>> +def __init__(self, initial: int = 0) -> None:
>>> +self._level = initial
>>>   -indent_level = 0
>>> +def __int__(self) -> int:
>>> +"""Return the indent as an integer."""
>> Isn't "as an integer" obvious?
>
> Just a compulsion to write complete sentences that got lost in the sea
> of many patches. I'll nix this one, because dunder methods do not need 
> to be documented.
>
>> Let's replace "the indent" by "the indentation" globally.
>> 
>
> They're both cromulent as nouns and one is shorter.
>
> I'll switch in good faith; do you prefer "Indentation" as a noun?

Use of "indent" as a noun was new to me, but what do I know; you're the
native speaker.  Use your judgement.  Applies to the class name, too.

>>> +return self._level
>>>   +def __repr__(self) -> str:
>>> +return "{}({:d})".format(type(self).__name__, self._level)
>> Is __repr__ needed?
>> 
>
> Yes; it's used in the underflow exception , and it is nice when using
> the python shell interactively.
>
> repr(Indent(4)) == "Indent(4)"

Meh.  There's another three dozen classes for you to put lipstick on :)

>>>   -def push_indent(indent_amount=4):
>>> -global indent_level
>>> -indent_level += indent_amount
>>> +def __str__(self) -> str:
>>> +"""Return the indent as a string."""
>>> +return ' ' * self._level
>>>   +def __bool__(self) -> bool:
>>> +"""True when there is a non-zero indent."""
>>> +return bool(self._level)
>> This one lets us shorten
>>  if int(INDENT):
>> to
>>  if INDENT:
>> There's just one instance.  Marginal.  I'm not rejecting it.
>> 
>
> Yep, it's trivial in either direction. Still, because it's a custom
> type, I thought I'd be courteous and have it support bool().
>
>>> -def pop_indent(indent_amount=4):
>>> -global indent_level
>>> -indent_level -= indent_amount
>>> +def push(self, amount: int = 4) -> int:
>>> +"""Push `amount` spaces onto the indent, default four."""
>>> +self._level += amount
>>> +return self._level
>>> +
>>> +def pop(self, amount: int = 4) -> int:
>>> +"""Pop `amount` spaces off of the indent, default four."""
>>> +if self._level < amount:
>>> +raise ArithmeticError(
>>> +"Can't pop {:d} spaces from {:s}".format(amount, 
>>> repr(self)))

I think assert(amount <= self._level) would do just fine.

>>> +self._level -= amount
>>> +return self._level
>> The push / pop names never made sense.  The functions don't push
>> onto /
>> pop from a stack, they increment / decrement a counter, and so do the
>> methods.  Good opportunity to fix the naming.
>> 
>
> OK.
>
> I briefly thought about using __isub__ and __iadd__ to support
> e.g. indent += 4, but actually it'd be annoying to have to specify 4
> everywhere.
>
> Since you didn't suggest anything, I am going to change it to
> 'increase' and 'decrease'.

Works for me.  So would inc and dec.

>> The @amount parameter has never been used.  I don't mind keeping it.
>> 
> I'll keep it, because I like having the default amount show up in the
> signature instead of as a magic constant in the function body.
>
>>> +
>>> +
>>> +INDENT = Indent(0)
>> Uh, does this really qualify as a constant?  It looks quite variable
>> to
>> me...
>> 
>
> Ever make a mista

Re: [RFC PATCH 04/12] device_tree: add qemu_fdt_add_path

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:25AM +0800, Ying Fang wrote:
> From: Andrew Jones 
> 
> qemu_fdt_add_path works like qemu_fdt_add_subnode, except it
> also recursively adds any missing parent nodes.
> 
> Cc: Peter Crosthwaite 
> Cc: Alexander Graf 
> Signed-off-by: Andrew Jones 
> ---
>  device_tree.c| 24 
>  include/sysemu/device_tree.h |  1 +
>  2 files changed, 25 insertions(+)
> 
> diff --git a/device_tree.c b/device_tree.c
> index b335dae707..1854be3a02 100644
> --- a/device_tree.c
> +++ b/device_tree.c
> @@ -524,6 +524,30 @@ int qemu_fdt_add_subnode(void *fdt, const char *name)
>  return retval;
>  }
>  
> +int qemu_fdt_add_path(void *fdt, const char *path)
> +{
> +char *parent;
> +int offset;
> +
> +offset = fdt_path_offset(fdt, path);
> +if (offset < 0 && offset != -FDT_ERR_NOTFOUND) {
> +error_report("%s Couldn't find node %s: %s", __func__, path,
> + fdt_strerror(offset));
> +exit(1);
> +}
> +
> +if (offset != -FDT_ERR_NOTFOUND) {
> +return offset;
> +}
> +
> +parent = g_strdup(path);
> +strrchr(parent, '/')[0] = '\0';
> +qemu_fdt_add_path(fdt, parent);
> +g_free(parent);
> +
> +return qemu_fdt_add_subnode(fdt, path);
> +}

Igor didn't like the recursion when I posted this before so I changed
it when doing the refresh[*] that I gave to Salil Mehta. Salil also
works for Huawei, are you guys not working together?

[*] https://github.com/rhdrjones/qemu/commits/virt-cpu-topology-refresh

Thanks,
drew

> +
>  void qemu_fdt_dumpdtb(void *fdt, int size)
>  {
>  const char *dumpdtb = qemu_opt_get(qemu_get_machine_opts(), "dumpdtb");
> diff --git a/include/sysemu/device_tree.h b/include/sysemu/device_tree.h
> index 982c89345f..15fb98af98 100644
> --- a/include/sysemu/device_tree.h
> +++ b/include/sysemu/device_tree.h
> @@ -104,6 +104,7 @@ uint32_t qemu_fdt_get_phandle(void *fdt, const char 
> *path);
>  uint32_t qemu_fdt_alloc_phandle(void *fdt);
>  int qemu_fdt_nop_node(void *fdt, const char *node_path);
>  int qemu_fdt_add_subnode(void *fdt, const char *name);
> +int qemu_fdt_add_path(void *fdt, const char *path);
>  
>  #define qemu_fdt_setprop_cells(fdt, node_path, property, ...)
>  \
>  do { 
>  \
> -- 
> 2.23.0
> 
> 




Re: [RFC PATCH 07/12] hw/acpi/aml-build: add processor hierarchy node structure

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:28AM +0800, Ying Fang wrote:
> Add the processor hierarchy node structures to build ACPI information
> for CPU topology. Three helpers are introduced:
> 
> (1) build_socket_hierarchy for socket description structure
> (2) build_processor_hierarchy for processor description structure
> (3) build_smt_hierarchy for thread (logic processor) description structure
> 
> Signed-off-by: Ying Fang 
> Signed-off-by: Henglong Fan 
> ---
>  hw/acpi/aml-build.c | 37 +
>  include/hw/acpi/aml-build.h |  7 +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index f6fbc9b95d..13eb6e1345 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1754,6 +1754,43 @@ void build_slit(GArray *table_data, BIOSLinker 
> *linker, MachineState *ms)
>   table_data->len - slit_start, 1, NULL, NULL);
>  }
>  
> +/*
> + * ACPI 6.3: 5.2.29.1 Processor hierarchy node structure (Type 0)
> + */
> +void build_socket_hierarchy(GArray *tbl, uint32_t parent, uint32_t id)
> +{
> +build_append_byte(tbl, 0);  /* Type 0 - processor */
> +build_append_byte(tbl, 20); /* Length, no private resources */
> +build_append_int_noprefix(tbl, 0, 2);  /* Reserved */
> +build_append_int_noprefix(tbl, 1, 4);  /* Flags: Physical package */
> +build_append_int_noprefix(tbl, parent, 4);  /* Parent */
> +build_append_int_noprefix(tbl, id, 4); /* ACPI processor ID */
> +build_append_int_noprefix(tbl, 0, 4);  /* Number of private resources */
> +}
> +
> +void build_processor_hierarchy(GArray *tbl, uint32_t flags,
> +   uint32_t parent, uint32_t id)
> +{
> +build_append_byte(tbl, 0);  /* Type 0 - processor */
> +build_append_byte(tbl, 20); /* Length, no private resources */
> +build_append_int_noprefix(tbl, 0, 2);  /* Reserved */
> +build_append_int_noprefix(tbl, flags, 4);  /* Flags */
> +build_append_int_noprefix(tbl, parent, 4); /* Parent */
> +build_append_int_noprefix(tbl, id, 4); /* ACPI processor ID */
> +build_append_int_noprefix(tbl, 0, 4);  /* Number of private resources */
> +}

I see you took this from
https://patchwork.ozlabs.org/project/qemu-devel/patch/20180704124923.32483-6-drjo...@redhat.com/
(even though you neglected to mention that)

I've tweaked my implementation of it slightly per Igor's comments for the
refresh. See build_processor_hierarchy_node() in
https://github.com/rhdrjones/qemu/commit/439b38d67ca1f2cbfa5b9892a822b651ebd05c11

> +
> +void build_smt_hierarchy(GArray *tbl, uint32_t parent, uint32_t id)
> +{
> +build_append_byte(tbl, 0);/* Type 0 - processor */
> +build_append_byte(tbl, 20);   /* Length, add private resources */
> +build_append_int_noprefix(tbl, 0, 2); /* Reserved */
> +build_append_int_noprefix(tbl, 0x0e, 4);/* Processor is a thread */
> +build_append_int_noprefix(tbl, parent , 4); /* parent */
> +build_append_int_noprefix(tbl, id, 4);  /* ACPI processor ID */
> +build_append_int_noprefix(tbl, 0, 4);   /* Num of private resources 
> */
> +}
> +
>  /* build rev1/rev3/rev5.1 FADT */
>  void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
>  const char *oem_id, const char *oem_table_id)
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index d27da03d64..ff4c6a38f3 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -435,6 +435,13 @@ void build_srat_memory(AcpiSratMemoryAffinity *numamem, 
> uint64_t base,
>  
>  void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms);
>  
> +void build_socket_hierarchy(GArray *tbl, uint32_t parent, uint32_t id);
> +
> +void build_processor_hierarchy(GArray *tbl, uint32_t flags,
> +   uint32_t parent, uint32_t id);
> +
> +void build_smt_hierarchy(GArray *tbl, uint32_t parent, uint32_t id);

Why add build_socket_hierarchy() and build_smt_hierarchy() ?

> +
>  void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
>  const char *oem_id, const char *oem_table_id);
>  
> -- 
> 2.23.0
> 

Thanks,
drew




Re: [RFC PATCH 08/12] hw/arm/virt-acpi-build: add PPTT table

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:29AM +0800, Ying Fang wrote:
> Add the Processor Properties Topology Table (PPTT) to present CPU topology
> information to the guest.
> 
> Signed-off-by: Andrew Jones 
> Signed-off-by: Ying Fang 
> ---
>  hw/arm/virt-acpi-build.c | 42 
>  1 file changed, 42 insertions(+)
>

There's a new version of this patch on the refresh branch.
https://github.com/rhdrjones/qemu/commits/virt-cpu-topology-refresh

drew 




Re: [PATCH V3 00/10] fix some comment spelling errors

2020-09-17 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20200917075029.313-1-zhaolich...@huawei.com/



Hi,

This series failed build test on FreeBSD host. Please find the details below.






The full log is available at
http://patchew.org/logs/20200917075029.313-1-zhaolich...@huawei.com/testing.FreeBSD/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: Should we apply for GitLab's open source program?

2020-09-17 Thread Alex Bennée


Paolo Bonzini  writes:

> On 17/09/20 01:39, Bradley M. Kuhn wrote:
>> One thing to note is that my understanding is that most of what you're
>> getting access to through this program is proprietary software features that
>> GitLab offers as add-ons.
>
> Basically all we need is the increased access to the CI environment (not
> just 400 minutes), and none of the add-on features.  Self-hosting would
> of course help but we'd have to pay for the hardware resources to run
> the CI, and have someone that can keep the hardware running.

It seems for the time being that public CI is still unlimited. The idea
of making our position as an FLOSS project "official" was to preempt any
changes to that might come down the track.

The question of using proprietary features hadn't come up beyond a
hand-waving of "ohh there is a long list". We are however thinking about
consolidating some of our more disparate infrastructure onto gitlab so
it's mostly in one place - for example the bug tracker currently hosted
on launchpad. Personally I'd think it's unlikely we want to move things
like the mailing lists which are currently on nongnu (via Savannah).

Ultimately as developers having to manage infrastructure is a bit of a
time-sink and currently it's hard for volunteer admins to be as
responsive as cloud-scale hosting companies who's income from non-free
software hosting pays for all our server time. If there was a free
software only instance of GitLab which offered the same level of service
I would personally be interested but I don't know how much of the
projects income could be diverted to supporting that versus the travel
bursaries and other such things we usually spend our money on.

In this regard FLOSS projects are both leaches on paid for services as
well as being useful public facing PR for a SaaS platforms abilities.

-- 
Alex Bennée



Re: [RFC PATCH 09/12] target/arm/cpu: Add CPU cache description for arm

2020-09-17 Thread Andrew Jones
On Thu, Sep 17, 2020 at 11:20:30AM +0800, Ying Fang wrote:
> Add the CPUCacheInfo structure to hold CPU cache information for ARM cpus.
> A classic three level cache topology is used here. The default cache
> capacity is given and userspace can overwrite these values.

Doesn't TCG already have some sort of fake cache hierarchy? If so, then
we shouldn't be adding another one, we should be simply describing the
one we already have. For KVM, we shouldn't describe anything other than
what is actually on the host.

drew




Re: Why QEMU translates one instruction to a TB?

2020-09-17 Thread Alex Bennée


casmac  writes:

> Hi all, 
>      We try to add DSP architecure to QEMU 4.2. To load the  
> COFF format object file, we have added loader code to load content from 
>    the object file. The rom_add_blob() function is used. We firstly  
> analyze the COFF file to figure out which sections are chained
>   together(so each chain forms a "memory blob"), and then allocate the 
> memory blobs. 
>   
>   The psuedo code looks like:
>   
>           for(i=0; i             if(ary_sect_chain[i].exist)   
> //there is a chain of sections to allocate 
>             {
>                 
> ary_sect_chain[i].mem_region = g_new(MemoryRegion, 1);
>                 
> memory_region_init_ram(...);
>                 
> memory_region_add_subregion(sysmem, );
>                 rom_add_blob();
>             }
>          }
>   


>     if (unlikely(entry->addr_code & TLB_MMIO)) {
>     /* The region is not backed by
> RAM.  */

This is the crux of it. If the address looked up isn't in a RAM region
then the TLB code can't assume a contiguous page of instructions or that
the instruction executed on one read will be the same on the next so it
will only execute a single instruction at a time and not cache the
resulting TB either forcing a fresh re-translation each time.

All TLB_MMIO access basically force the slow path.

I suspect there is something wrong in your memory region mappings.

-- 
Alex Bennée



Re: [PATCH V3 08/10] disas/: fix some comment spelling errors

2020-09-17 Thread Alex Bennée


zhaolichang  writes:

> I found that there are many spelling errors in the comments of qemu,
> so I used the spellcheck tool to check the spelling errors
> and finally found some spelling errors in the disas folder.
>
> Signed-off-by: zhaolichang 

Reviewed-by: Alex Bennée 

I suggest on your next posting you CC qemu-triv...@nongnu.org so the
patches can get pulled in via the trivial tree.

> ---
>  disas/hppa.c | 2 +-
>  disas/m68k.c | 8 
>  disas/ppc.c  | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/disas/hppa.c b/disas/hppa.c
> index 2dbd1fc445..dcf9a47f34 100644
> --- a/disas/hppa.c
> +++ b/disas/hppa.c
> @@ -2021,7 +2021,7 @@ print_insn_hppa (bfd_vma memaddr, disassemble_info 
> *info)
>   fput_fp_reg (GET_FIELD (insn, 6, 10), info);
> break;
>  
> -   /* 'fA' will not generate a space before the regsiter
> +   /* 'fA' will not generate a space before the register
>name.  Normally that is fine.  Except that it
>causes problems with xmpyu which has no FP format
>completer.  */
> diff --git a/disas/m68k.c b/disas/m68k.c
> index 863409c67c..aefaecfbd6 100644
> --- a/disas/m68k.c
> +++ b/disas/m68k.c
> @@ -70,7 +70,7 @@ struct floatformat
>unsigned int exp_start;
>unsigned int exp_len;
>/* Bias added to a "true" exponent to form the biased exponent.  It
> - is intentionally signed as, otherwize, -exp_bias can turn into a
> + is intentionally signed as, otherwise, -exp_bias can turn into a
>   very large number (e.g., given the exp_bias of 0x3fff and a 64
>   bit long, the equation (long)(1 - exp_bias) evaluates to
>   4294950914) instead of -16382).  */
> @@ -479,7 +479,7 @@ struct m68k_opcode_alias
>and remaining 3 bits of register shifted 9 bits in first word.
>Indicate upper/lower in 1 bit shifted 7 bits in second word.
>Use with `R' or `u' format.
> -   n  `m' withouth upper/lower indication. (For M[S]ACx; 4 bits split
> +   n  `m' without upper/lower indication. (For M[S]ACx; 4 bits split
>with MSB shifted 6 bits in first word and remaining 3 bits of
>register shifted 9 bits in first word.  No upper/lower
>indication is done.)  Use with `R' or `u' format.
> @@ -854,7 +854,7 @@ fetch_arg (unsigned char *buffer,
>  
>  /* Check if an EA is valid for a particular code.  This is required
> for the EMAC instructions since the type of source address determines
> -   if it is a EMAC-load instruciton if the EA is mode 2-5, otherwise it
> +   if it is a EMAC-load instruction if the EA is mode 2-5, otherwise it
> is a non-load EMAC instruction and the bits mean register Ry.
> A similar case exists for the movem instructions where the register
> mask is interpreted differently for different EAs.  */
> @@ -1080,7 +1080,7 @@ print_indexed (int basereg,
>  
>  /* Returns number of bytes "eaten" by the operand, or
> return -1 if an invalid operand was found, or -2 if
> -   an opcode tabe error was found.
> +   an opcode table error was found.
> ADDR is the pc for this arg to be relative to.  */
>  
>  static int
> diff --git a/disas/ppc.c b/disas/ppc.c
> index 63e97cfe1d..02be878198 100644
> --- a/disas/ppc.c
> +++ b/disas/ppc.c
> @@ -5226,7 +5226,7 @@ operand_value_powerpc (const struct powerpc_operand 
> *operand,
>if ((operand->flags & PPC_OPERAND_SIGNED) != 0)
>   {
> /* BITM is always some number of zeros followed by some
> -  number of ones, followed by some numer of zeros.  */
> +  number of ones, followed by some number of zeros.  */
> unsigned long top = operand->bitm;
> /* top & -top gives the rightmost 1 bit, so this
>fills in any trailing zeros.  */


-- 
Alex Bennée



Re: [PATCH v2] virtio: skip legacy support check on machine types less than 5.1

2020-09-17 Thread Stefano Garzarella
On Wed, Sep 16, 2020 at 11:08:48AM +0200, Cornelia Huck wrote:
> On Tue, 15 Sep 2020 15:05:14 +0200
> Stefano Garzarella  wrote:
> 
> > Commit 9b3a35ec82 ("virtio: verify that legacy support is not accidentally
> > on") added a check that returns an error if legacy support is on, but the
> > device is not legacy.
> > 
> > Unfortunately some devices were wrongly declared legacy even if they
> > were not (e.g vhost-vsock).
> > 
> > To avoid migration issues, we disable this error for machine types < 5.1,
> > but we print a warning.
> > 
> > Cc: qemu-sta...@nongnu.org
> > Fixes: 9b3a35ec82 ("virtio: verify that legacy support is not accidentally 
> > on")
> > Suggested-by: Dr. David Alan Gilbert 
> > Suggested-by: Cornelia Huck 
> > Signed-off-by: Stefano Garzarella 
> > ---
> > v2:
> >  - fixed Cornelia's e-mail address
> > ---
> >  include/hw/virtio/virtio.h |  1 +
> >  hw/core/machine.c  |  1 +
> >  hw/virtio/virtio.c | 18 --
> >  3 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 807280451b..ed7cee348b 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -103,6 +103,7 @@ struct VirtIODevice
> >  bool use_started;
> >  bool started;
> >  bool start_on_kick; /* when virtio 1.0 feature has not been negotiated 
> > */
> > +bool disable_legacy_check;
> >  VMChangeStateEntry *vmstate;
> >  char *bus_name;
> >  uint8_t device_endian;
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index ea26d61237..b686eab798 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -44,6 +44,7 @@ GlobalProperty hw_compat_5_0[] = {
> >  { "vmport", "x-signal-unsupported-cmd", "off" },
> >  { "vmport", "x-report-vmx-type", "off" },
> >  { "vmport", "x-cmds-v2", "off" },
> > +{ "virtio-device", "x-disable-legacy-check", "true" },
> 
> Hm... not sure if we actually should add a new device property for
> that. Maybe we can use a flag in the base machine type instead?

I am not very experienced with machine types.
I used the device property to easily access it from virtio devices.

Please, can you give me some suggestions where to look for the flags?

> 
> >  };
> >  const size_t hw_compat_5_0_len = G_N_ELEMENTS(hw_compat_5_0);
> >  
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index e983025217..30ccc43b8c 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -3287,6 +3287,8 @@ void virtio_init(VirtIODevice *vdev, const char *name,
> >   */
> >  bool virtio_legacy_allowed(VirtIODevice *vdev)
> >  {
> > +bool ret = false;
> > +
> >  switch (vdev->device_id) {
> >  case VIRTIO_ID_NET:
> >  case VIRTIO_ID_BLOCK:
> > @@ -3298,10 +3300,20 @@ bool virtio_legacy_allowed(VirtIODevice *vdev)
> >  case VIRTIO_ID_9P:
> >  case VIRTIO_ID_RPROC_SERIAL:
> >  case VIRTIO_ID_CAIF:
> > +ret = true;
> > +}
> > +
> > +/*
> > + * For backward compatibility, we allow legacy mode with old machine 
> > types
> > + * to get the migration working.
> > + */
> > +if (!ret && vdev->disable_legacy_check) {
> > +warn_report("device is modern-only, but for backward compatibility 
> > "
> > +"legacy is allowed");
> 
> I don't think we should warn in the function that returns whether
> legacy is allowed or not. Future code might want to call this function
> for other purposes, and returning true with a warning is not that
> useful for code that wants to find out whether legacy is supported for
> a type in principle.
> 
> So even though it is more work, I think we should move this warning to
> the code that is actively trying to fence off misconfigured devices.

Yes, I got it. At first I did so, but then I wanted to reduce the
duplicate code.

But you're right, it's ugly.
I'll send a v3.

Thanks,
Stefano




Re: [PATCH V3 00/10] fix some comment spelling errors

2020-09-17 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20200917075029.313-1-zhaolich...@huawei.com/



Hi,

This series failed build test on FreeBSD host. Please find the details below.






The full log is available at
http://patchew.org/logs/20200917075029.313-1-zhaolich...@huawei.com/testing.FreeBSD/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

QEMU policy for real file tests

2020-09-17 Thread Christian Schoenebeck
Hi,

is there a QEMU policy for test cases that create/write/read/delete real files 
and directories? E.g. should they be situated at a certain location and is any 
measure of sandboxing required?

Best regards,
Christian Schoenebeck






Re: Use patchew to push successfully applied series to GitLab

2020-09-17 Thread Paolo Bonzini
On 17/09/20 10:16, Philippe Mathieu-Daudé wrote:
> patchew is currently pushing successfully applied series
> (using the cover Message-ID as tag) to GitHub.
> This is very handy (no need to apply patches manually):
> https://github.com/patchew-project/qemu/tags
> 
> Can we push the same that to an equivalent GitLab account?
> We could then have a script replying to the series if the
> series fails CI. Doing so would save reviewer/tester time
> (I'd rather have a series not failing on our CI tests before
> starting to review/test it).

Yes, we could.  Indeed we could also look at the pipeline result instead
of needing Patchew's custom testers (using a webhook).  It would be a
bit on the heavy side for GitLab's resources; while right now they're
still providing unlimited CI time, in principle the "gold" tier provides
"only" 833 hours and a full CI run takes more or less 1.

So it would work great but we would have to set up our own runners,
and/or have a cheaper pipeline for this gating CI.  Is that possible to
configure in Gitlab?

Paolo




Re: [PATCH v2] migration: Silence compiler warning in global_state_store_running()

2020-09-17 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20200917074344.168785-1-th...@redhat.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.






The full log is available at
http://patchew.org/logs/20200917074344.168785-1-th...@redhat.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 v5 00/10] preallocate filter

2020-09-17 Thread Vladimir Sementsov-Ogievskiy

01.09.2020 18:07, Max Reitz wrote:

On 27.08.20 23:08, Vladimir Sementsov-Ogievskiy wrote:

21.08.2020 17:11, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

Here is a filter, which does preallocation on write.

In Virtuozzo we have to deal with some custom distributed storage
solution, where allocation is relatively expensive operation. We have to
workaround it in Qemu, so here is a new filter.


I have a problem now with this thing.

We need preallocation. But we don't want to explicitly specify it in all
the management tools.


Why?


So it should be inserted by default.


Why?  You mean without any option?  That seems...  Interesting?

(Also like a recipe for reports of performance regression in some cases.)


It's OK for
us to keep this default different from upstream... But there are
problems with the implicitly inserted filter (actually iotests fail and
I failed to fix them)


I would suspect even if the iotests passed we would end up with a heap
of problems that we would only notice at some later point.  I thought
you too weren’t too fond of the idea of implicit filters.


1. I have to set bs->inherits_from for filter and it's child by hand
after bdrv_replace_node(), otherwise bdrv_check_perm doesn't work.

2. I have to set filter_bs->implicit and teach bdrv_refresh_filename()
to ignore implicit filters when it checks for drv->bdrv_file_open, to
avoid appearing of json in backing file names

3. And the real design problem, which seems impossible to fix: reopen is
broken, just because user is not prepared to the fact that file child is
a filter, not a file node and has another options, and don't support
options of file-posix.


Well, what should I say.  I feel like we have made efforts in the past
years to make the block graph fully visible to users and yield the
responsibility of managing it to the users, too, so I’m not surprised if
a step backwards breaks that.


And seems all it (and mostly [3]) shows that implicitly inserting the
filter is near to be impossible..

So, what are possible solutions?

In virtuozzo7 we have preallocation feature done inside qcow2 driver.
This is very uncomfortable: we should to handle each possible over-EOF
write to underlying node (to keep data_end in sync to be able to shrink
preallocation on close()).. I don't like this way and don't want to port
it..

Another option is implementing preallocation inside file-posix driver.
Then, instead of BDRV_REQ_NO_WAIT flag I'll need to extend serialising
requests API (bdrv_make_request_serialising() is already used in
file-posix.c) to dupport no-wait behavior + expanding the serialising
request bounds. This option seems feasible, so I'll try this way if no
other ideas.


Possible, but you haven’t yet explained what the problem with the
management layer inserting the preallocation filter is.


Filter is obviously the true way: we use generic block layer for native
request serialising, don't need to catch every write in qcow2 driver,
don't need to modify any other driver and get a universal thing. But how
to insert it implicitly (or at least automatically in some cases) and
avoid all the problems?


I don’t understand why inserting it implicitly is important.



You are right. Thanks for strong point of view, this makes me to revise my own. 
Now I'm working on v6.

--
Best regards,
Vladimir



Re: [PATCH v10 11/12] migration/dirtyrate: Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function

2020-09-17 Thread Dr. David Alan Gilbert
* Chuan Zheng (zhengch...@huawei.com) wrote:
> Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function which could be 
> called
> 
> Signed-off-by: Chuan Zheng 

Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/dirtyrate.c | 62 
> +++
>  qapi/migration.json   | 50 +
>  2 files changed, 112 insertions(+)
> 
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 2a1a7fa..06f455d 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -61,6 +61,24 @@ static int dirtyrate_set_state(int *state, int old_state, 
> int new_state)
>  }
>  }
>  
> +static struct DirtyRateInfo *query_dirty_rate_info(void)
> +{
> +int64_t dirty_rate = DirtyStat.dirty_rate;
> +struct DirtyRateInfo *info = g_malloc0(sizeof(DirtyRateInfo));
> +
> +if (atomic_read(&CalculatingState) == DIRTY_RATE_STATUS_MEASURED) {
> +info->dirty_rate = dirty_rate;
> +} else {
> +info->dirty_rate = -1;
> +}
> +
> +info->status = CalculatingState;
> +info->start_time = DirtyStat.start_time;
> +info->calc_time = DirtyStat.calc_time;
> +
> +return info;
> +}
> +
>  static void reset_dirtyrate_stat(void)
>  {
>  DirtyStat.total_dirty_samples = 0;
> @@ -318,6 +336,8 @@ static void calculate_dirtyrate(struct DirtyRateConfig 
> config)
>  
>  msec = config.sample_period_seconds * 1000;
>  msec = set_sample_page_period(msec, initial_time);
> +DirtyStat.start_time = initial_time / 1000;
> +DirtyStat.calc_time = msec / 1000;
>  
>  rcu_read_lock();
>  if (!compare_page_hash_info(block_dinfo, block_count)) {
> @@ -353,3 +373,45 @@ void *get_dirtyrate_thread(void *arg)
>  }
>  return NULL;
>  }
> +
> +void qmp_calc_dirty_rate(int64_t calc_time, Error **errp)
> +{
> +static struct DirtyRateConfig config;
> +QemuThread thread;
> +int ret;
> +
> +/*
> + * If the dirty rate is already being measured, don't attempt to start.
> + */
> +if (atomic_read(&CalculatingState) == DIRTY_RATE_STATUS_MEASURING) {
> +error_setg(errp, "the dirty rate is already being measured.");
> +return;
> +}
> +
> +if (!is_sample_period_valid(calc_time)) {
> +error_setg(errp, "calc-time is out of range[%d, %d].",
> + MIN_FETCH_DIRTYRATE_TIME_SEC,
> + MAX_FETCH_DIRTYRATE_TIME_SEC);
> +return;
> +}
> +
> +/*
> + * Init calculation state as unstarted.
> + */
> +ret = dirtyrate_set_state(&CalculatingState, CalculatingState,
> +  DIRTY_RATE_STATUS_UNSTARTED);
> +if (ret == -1) {
> +error_setg(errp, "init dirty rate calculation state failed.");
> +return;
> +}
> +
> +config.sample_period_seconds = calc_time;
> +config.sample_pages_per_gigabytes = DIRTYRATE_DEFAULT_SAMPLE_PAGES;
> +qemu_thread_create(&thread, "get_dirtyrate", get_dirtyrate_thread,
> +   (void *)&config, QEMU_THREAD_DETACHED);
> +}
> +
> +struct DirtyRateInfo *qmp_query_dirty_rate(Error **errp)
> +{
> +return query_dirty_rate_info();
> +}
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 061ff25..4b980a0 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -1737,3 +1737,53 @@
>  ##
>  { 'enum': 'DirtyRateStatus',
>'data': [ 'unstarted', 'measuring', 'measured'] }
> +
> +##
> +# @DirtyRateInfo:
> +#
> +# Information about current dirty page rate of vm.
> +#
> +# @dirty-rate: @dirtyrate describing the dirty page rate of vm
> +#  in units of MB/s.
> +#  If this field return '-1', it means querying is not
> +#  start or not complete.
> +#
> +# @status: status containing dirtyrate query status includes
> +#  'unstarted' or 'measuring' or 'measured'
> +#
> +# @start-time: start time in units of second for calculation
> +#
> +# @calc-time: time in units of second for sample dirty pages
> +#
> +# Since: 5.2
> +#
> +##
> +{ 'struct': 'DirtyRateInfo',
> +  'data': {'dirty-rate': 'int64',
> +   'status': 'DirtyRateStatus',
> +   'start-time': 'int64',
> +   'calc-time': 'int64'} }
> +
> +##
> +# @calc-dirty-rate:
> +#
> +# start calculating dirty page rate for vm
> +#
> +# @calc-time: time in units of second for sample dirty pages
> +#
> +# Since: 5.2
> +#
> +# Example:
> +#   {"command": "calc-dirty-rate", "data": {"calc-time": 1} }
> +#
> +##
> +{ 'command': 'calc-dirty-rate', 'data': {'calc-time': 'int64'} }
> +
> +##
> +# @query-dirty-rate:
> +#
> +# query dirty page rate in units of MB/s for vm
> +#
> +# Since: 5.2
> +##
> +{ 'command': 'query-dirty-rate', 'returns': 'DirtyRateInfo' }
> -- 
> 1.8.3.1
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH v10 00/12] *** A Method for evaluating dirty page rate ***

2020-09-17 Thread Dr. David Alan Gilbert
* Chuan Zheng (zhengch...@huawei.com) wrote:
> v9 -> v10:
> rename find_page_matched as find_block_matched
> fix wrong termination condition in find_block_matched
> add review-by for patches
> 
> v8 -> v9:
> fix wrong index return of record_ramblock_hash_info
> optimize variable name according to review
> reset dirty_rate as -1
> change returns of compare_page_hash_info to bool
> 
> v7 -> v8:
> add atomic_read for dirtyrate status
> add error_report if set dirtyrate state failed
> change returns of save_ramblock_hash and record_ramblock_hash_info to bool
> alloc ramblock dirtyinfo array at one time
> add review-by for patches
> 
> v6 -> v7:
> fix minior comments and coding style by review
> add review-by for patches
> 
> v5 -> v6:
> fix coding style according to review
> use TARGET_PAGE_SIZE and TARGET_PAGE_BITS instead of self-defined macros
> return start-time and calc-time by qmp command
> 
> v4 -> v5:
> fix git apply failed due to meson-build
> add review-by for patches in v3
> 
> v3 -> v4:
> use crc32 to get hash result instead of md5
> add DirtyRateStatus to denote calculation status
> add some trace_calls to make it easier to debug
> fix some comments accroding to review
> 
> v2 -> v3:
> fix size_t compile warning
> fix codestyle checked by checkpatch.pl
> 
> v1 -> v2:
> use g_rand_new() to generate rand_buf
> move RAMBLOCK_FOREACH_MIGRATABLE into migration/ram.h
> add skip_sample_ramblock to filter sampled ramblock
> fix multi-numa vm coredump when query dirtyrate
> rename qapi interface and rename some structures and functions
> succeed to compile by appling each patch
> add test for migrating vm
> 
> Sometimes it is neccessary to evaluate dirty page rate before migration.
> Users could decide whether to proceed migration based on the evaluation
> in case of vm performance loss due to heavy workload.
> Unlikey simulating dirtylog sync which could do harm on runnning vm,
> we provide a sample-hash method to compare hash results for samping page.
> In this way, it would have hardly no impact on vm performance.
> 
> Evaluate the dirtypage rate both on running and migration vm.
> The VM specifications for migration are as follows:
> - VM use 4-K page;
> - the number of VCPU is 32;
> - the total memory is 32Gigabit;
> - use 'mempress' tool to pressurize VM(mempress 4096 1024);
> - migration bandwidth is 1GB/s
> 
> +++
> |  |  running  |  migrating   
> |
> +++
> | no mempress  |   4MB/s   |  8MB/s  (migrated success)   
> |
> ---
> | mempress 4096 1024   |  1060MB/s | 456MB/s ~ 1142MB/s (cpu throttle 
> triggered)  |
> +++
> | mempress 4096 4096   |  4114MB/s | 688MB/s ~ 4132MB/s (cpu throttle 
> triggered)  |
> +++
> 
> Test dirtyrate by qmp command like this:
> 1.  virsh qemu-monitor-command [vmname] '{"execute":"calc-dirty-rate", 
> "arguments": {"calc-time": [sleep-time]}}'; 
> 2.  sleep specific time which is a bit larger than sleep-time
> 3.  virsh qemu-monitor-command [vmname] '{"execute":"query-dirty-rate"}'

Thanks; it looks like we have a full set of reviews; I'll try and add
this for the next migration pull.

> The qmp command returns like this:
> {"return":{"status":"measured","dirty-rate":374,"start-time":3718293,"calc-time":1},"id":"libvirt-15"}
> 
> Further test dirtyrate by libvirt api like this:
> virsh getdirtyrate [vmname] [sleep-time]

So do you have some libvirt patches you're going to post?

Dave

> Chuan Zheng (12):
>   migration/dirtyrate: setup up query-dirtyrate framwork
>   migration/dirtyrate: add DirtyRateStatus to denote calculation status
>   migration/dirtyrate: Add RamblockDirtyInfo to store sampled page info
>   migration/dirtyrate: Add dirtyrate statistics series functions
>   migration/dirtyrate: move RAMBLOCK_FOREACH_MIGRATABLE into ram.h
>   migration/dirtyrate: Record hash results for each sampled page
>   migration/dirtyrate: Compare page hash results for recorded sampled
> page
>   migration/dirtyrate: skip sampling ramblock with size below
> MIN_RAMBLOCK_SIZE
>   migration/dirtyrate: Implement set_sample_page_period() and
> is_sample_period_valid()
>   migration/dirtyrate: Implement calculate_dirtyrate() function
>   migration/dirtyrate: Implement
> qmp_cal_dirty_rate()/qmp_get_dirty_rate() function
>   migration/dirtyrate: Add trace_calls to make it easier to debug
> 
>  migration/

[Bug 1892604] Re: qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion `addr <= GINTSTS2' failed.

2020-09-17 Thread Paul Zimmerman
Something very strange is going on with the dwc_otg driver in 
2016-05-27-raspbian-jessie.img. Something is reading and writing incrementally 
throughout the register space of the hcd-dwc2 host.
And adding the "dwc_otg.fiq_fsm_enable=0" kernel option does not fix it.

Brendan, Petunia, is there a reason why you are testing with such an old
version of Raspbian? I used 2019-09-26-raspbian-buster.img when
developing the hcd-dwc2 emulation, and it works fine, other than needing
the "dwc_otg.fiq_fsm_enable=0" kernel option.

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

Title:
  qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion
  `addr <= GINTSTS2' failed.

Status in QEMU:
  New

Bug description:
  When trying to run the 2016-05-27 Raspbian image on the emulated
  raspi2 platform, the system boots but shortly after the login prompt
  QEMU (master; commit ID ca489cd037e4d50dc6c40570a167504ad7e5a521) dies
  with:

  qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion
  `addr <= GINTSTS2' failed.

  Steps to reproduce:

  1. Get the image: wget
  
http://downloads.raspberrypi.org/raspbian/images/raspbian-2016-05-31/2016-05-27
  -raspbian-jessie.zip

  2. Extract the kernel image and DTB:

  sudo losetup -f --show -P 2016-05-27-raspbian-jessie.img
  sudo mkdir /mnt/rpi
  sudo mount /dev/loop11p1 /mnt/rpi/
  cp /mnt/rpi/kernel7.img . 



  cp /mnt/rpi/bcm2709-rpi-2-b.dtb . 



  sudo umount /mnt/rpi 
  sudo losetup -d /dev/loop11 

  3. Run QEMU:
  qemu-system-arm -M raspi2 -m 1G -dtb bcm2709-rpi-2-b.dtb -kernel kernel7.img 
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 
root=/dev/mmcblk0p2" -sd 2016-05-27-raspbian-jessie.img -smp 4 -serial stdio 
-display none

  A few seconds after the login prompt is displayed, QEMU will exit with
  the assertion failure.

  I also tried changing all of the asserts to if statements that (for
  MMIO reads) returned 0 and (for writes) just returned, but this
  resulted in a non-responsive system.

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



Re: Should we apply for GitLab's open source program?

2020-09-17 Thread Daniel P . Berrangé
On Thu, Sep 17, 2020 at 09:32:57AM +0100, Alex Bennée wrote:
> 
> Paolo Bonzini  writes:
> 
> > On 17/09/20 01:39, Bradley M. Kuhn wrote:
> >> One thing to note is that my understanding is that most of what you're
> >> getting access to through this program is proprietary software features 
> >> that
> >> GitLab offers as add-ons.
> >
> > Basically all we need is the increased access to the CI environment (not
> > just 400 minutes), and none of the add-on features.  Self-hosting would
> > of course help but we'd have to pay for the hardware resources to run
> > the CI, and have someone that can keep the hardware running.
> 
> It seems for the time being that public CI is still unlimited. The idea
> of making our position as an FLOSS project "official" was to preempt any
> changes to that might come down the track.
> 
> The question of using proprietary features hadn't come up beyond a
> hand-waving of "ohh there is a long list". We are however thinking about
> consolidating some of our more disparate infrastructure onto gitlab so
> it's mostly in one place - for example the bug tracker currently hosted
> on launchpad. Personally I'd think it's unlikely we want to move things
> like the mailing lists which are currently on nongnu (via Savannah).
> 
> Ultimately as developers having to manage infrastructure is a bit of a
> time-sink and currently it's hard for volunteer admins to be as
> responsive as cloud-scale hosting companies who's income from non-free
> software hosting pays for all our server time.

All the evidence we have is that developers generally do not do a good
job at maintaining infrastructure in their spare time. This is largely
unavoidable since a developer is always going to treat sysadmin tasks as
a part time thing to spend as little time as possible on, prioritizing
their coding work. So we end up either with unreliable services that
continuously break (look how many times has Patchew died from ENOSPC
this year), or the service happens to work reliably but is unmaintained
becoming increasingly out of date and thus vulnerable, or the service
simply ends up lagging behind state of the art offered by alternatives.

> If there was a free
> software only instance of GitLab which offered the same level of service
> I would personally be interested but I don't know how much of the
> projects income could be diverted to supporting that versus the travel
> bursaries and other such things we usually spend our money on.

Clearly the ideal situation would be 100% free software infrastructure
we can use at zero cost, while still being state of the art in terms
of services available to support our workflow. This doesn't exist, so
we have to figure out the most effective tradeoff to make that supports
QEMU's needs in an effective manner.

GitLab's open core model means we're at least partially using open
source infra, even if some features are closed. The basic GitLab CI
features are actually open source AFAIK, so we're not relying on the
closed source infra part of GitLab in that area. IOW, joining the
open source program there is simply about getting an increased grant
of free hardware resources to use.

This is certainly preferrable to us making more use of Travis or
Cirrus CI, or GitHub Actions, all of which are 100% closed CI
systems AFAIK.

Some projects have deployed their own GitLab instances (GNOME,
FreeDesktop), but that is not without significant challenges in
terms of deploying and maintaining the software as well as
providing sufficient hardware to go along. eg See the surprising
effect this self-hosting had on FreeDesktop costs:

  https://lists.freedesktop.org/archives/wayland-devel/2020-February/041232.html

It has been a long tedious road merely to bring up a small number
of CI runners on hardware sponsored by Red Hat, let alone get
enough hardware to replace everything that we and our contributors
currentl get for free via various public services. 

There's ultimately a big gap that exists in terms of a publically
host Git Forge that offers state of the art features, based on
100% open source infra. I'm not seeing anyone being able to solve
that in the forseeable future, and it doesn't seem like a sane use
of QEMU's limited contributor time to divert resources away from
development into infrastructure. We need to make a pragmatic
tradeoff, certainly favouring open source where possible, but if
we need to use other services too that's acceptable.

Our switch to increasingly use GitLab for CI is certainly an
improvement over our historical use of Travis, Shippable and
Cirrus, and better for our contributors than our reliance on
a handful of machines that only the QEMU Git maintainer can
access, or the patchew system that breaks multiple times a
year.

> In this regard FLOSS projects are both leaches on paid for services as
> well as being useful public facing PR for a SaaS platforms abilities.

Regards,
Daniel
-- 
|: https://berrange.com  

Re: [PATCH v10 00/12] *** A Method for evaluating dirty page rate ***

2020-09-17 Thread Zheng Chuan



On 2020/9/17 17:15, Dr. David Alan Gilbert wrote:
> * Chuan Zheng (zhengch...@huawei.com) wrote:
>> v9 -> v10:
>> rename find_page_matched as find_block_matched
>> fix wrong termination condition in find_block_matched
>> add review-by for patches
>>
>> v8 -> v9:
>> fix wrong index return of record_ramblock_hash_info
>> optimize variable name according to review
>> reset dirty_rate as -1
>> change returns of compare_page_hash_info to bool
>>
>> v7 -> v8:
>> add atomic_read for dirtyrate status
>> add error_report if set dirtyrate state failed
>> change returns of save_ramblock_hash and record_ramblock_hash_info to 
>> bool
>> alloc ramblock dirtyinfo array at one time
>> add review-by for patches
>>
>> v6 -> v7:
>> fix minior comments and coding style by review
>> add review-by for patches
>>
>> v5 -> v6:
>> fix coding style according to review
>> use TARGET_PAGE_SIZE and TARGET_PAGE_BITS instead of self-defined macros
>> return start-time and calc-time by qmp command
>>
>> v4 -> v5:
>> fix git apply failed due to meson-build
>> add review-by for patches in v3
>>
>> v3 -> v4:
>> use crc32 to get hash result instead of md5
>> add DirtyRateStatus to denote calculation status
>> add some trace_calls to make it easier to debug
>> fix some comments accroding to review
>>
>> v2 -> v3:
>> fix size_t compile warning
>> fix codestyle checked by checkpatch.pl
>>
>> v1 -> v2:
>> use g_rand_new() to generate rand_buf
>> move RAMBLOCK_FOREACH_MIGRATABLE into migration/ram.h
>> add skip_sample_ramblock to filter sampled ramblock
>> fix multi-numa vm coredump when query dirtyrate
>> rename qapi interface and rename some structures and functions
>> succeed to compile by appling each patch
>> add test for migrating vm
>>
>> Sometimes it is neccessary to evaluate dirty page rate before migration.
>> Users could decide whether to proceed migration based on the evaluation
>> in case of vm performance loss due to heavy workload.
>> Unlikey simulating dirtylog sync which could do harm on runnning vm,
>> we provide a sample-hash method to compare hash results for samping page.
>> In this way, it would have hardly no impact on vm performance.
>>
>> Evaluate the dirtypage rate both on running and migration vm.
>> The VM specifications for migration are as follows:
>> - VM use 4-K page;
>> - the number of VCPU is 32;
>> - the total memory is 32Gigabit;
>> - use 'mempress' tool to pressurize VM(mempress 4096 1024);
>> - migration bandwidth is 1GB/s
>>
>> +++
>> |  |  running  |  migrating  
>>  |
>> +++
>> | no mempress  |   4MB/s   |  8MB/s  (migrated success)  
>>  |
>> ---
>> | mempress 4096 1024   |  1060MB/s | 456MB/s ~ 1142MB/s (cpu throttle 
>> triggered)  |
>> +++
>> | mempress 4096 4096   |  4114MB/s | 688MB/s ~ 4132MB/s (cpu throttle 
>> triggered)  |
>> +++
>>
>> Test dirtyrate by qmp command like this:
>> 1.  virsh qemu-monitor-command [vmname] '{"execute":"calc-dirty-rate", 
>> "arguments": {"calc-time": [sleep-time]}}'; 
>> 2.  sleep specific time which is a bit larger than sleep-time
>> 3.  virsh qemu-monitor-command [vmname] '{"execute":"query-dirty-rate"}'
> 
> Thanks; it looks like we have a full set of reviews; I'll try and add
> this for the next migration pull.
> 
>> The qmp command returns like this:
>> {"return":{"status":"measured","dirty-rate":374,"start-time":3718293,"calc-time":1},"id":"libvirt-15"}
>>
>> Further test dirtyrate by libvirt api like this:
>> virsh getdirtyrate [vmname] [sleep-time]
> 
> So do you have some libvirt patches you're going to post?
> 
> Dave
> 

Hi, Dave.

Yes, libvirt(including libvirt-python) interface will come after this qemu 
series patch:)

>> Chuan Zheng (12):
>>   migration/dirtyrate: setup up query-dirtyrate framwork
>>   migration/dirtyrate: add DirtyRateStatus to denote calculation status
>>   migration/dirtyrate: Add RamblockDirtyInfo to store sampled page info
>>   migration/dirtyrate: Add dirtyrate statistics series functions
>>   migration/dirtyrate: move RAMBLOCK_FOREACH_MIGRATABLE into ram.h
>>   migration/dirtyrate: Record hash results for each sampled page
>>   migration/dirtyrate: Compare page hash results for recorded sampled
>> page
>>   migration/dirtyrate: skip sampling ramblock with size below
>> MIN_RAMBLOCK_SIZE
>>   migration/dirtyrate: Implement set_sample_page_period() and
>>  

Re: [PATCH v2] virtio: skip legacy support check on machine types less than 5.1

2020-09-17 Thread Cornelia Huck
On Thu, 17 Sep 2020 10:48:28 +0200
Stefano Garzarella  wrote:

> On Wed, Sep 16, 2020 at 11:08:48AM +0200, Cornelia Huck wrote:
> > On Tue, 15 Sep 2020 15:05:14 +0200
> > Stefano Garzarella  wrote:
> >   
> > > Commit 9b3a35ec82 ("virtio: verify that legacy support is not accidentally
> > > on") added a check that returns an error if legacy support is on, but the
> > > device is not legacy.
> > > 
> > > Unfortunately some devices were wrongly declared legacy even if they
> > > were not (e.g vhost-vsock).
> > > 
> > > To avoid migration issues, we disable this error for machine types < 5.1,
> > > but we print a warning.
> > > 
> > > Cc: qemu-sta...@nongnu.org
> > > Fixes: 9b3a35ec82 ("virtio: verify that legacy support is not 
> > > accidentally on")
> > > Suggested-by: Dr. David Alan Gilbert 
> > > Suggested-by: Cornelia Huck 
> > > Signed-off-by: Stefano Garzarella 
> > > ---
> > > v2:
> > >  - fixed Cornelia's e-mail address
> > > ---
> > >  include/hw/virtio/virtio.h |  1 +
> > >  hw/core/machine.c  |  1 +
> > >  hw/virtio/virtio.c | 18 --
> > >  3 files changed, 18 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > index 807280451b..ed7cee348b 100644
> > > --- a/include/hw/virtio/virtio.h
> > > +++ b/include/hw/virtio/virtio.h
> > > @@ -103,6 +103,7 @@ struct VirtIODevice
> > >  bool use_started;
> > >  bool started;
> > >  bool start_on_kick; /* when virtio 1.0 feature has not been 
> > > negotiated */
> > > +bool disable_legacy_check;
> > >  VMChangeStateEntry *vmstate;
> > >  char *bus_name;
> > >  uint8_t device_endian;
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > index ea26d61237..b686eab798 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -44,6 +44,7 @@ GlobalProperty hw_compat_5_0[] = {
> > >  { "vmport", "x-signal-unsupported-cmd", "off" },
> > >  { "vmport", "x-report-vmx-type", "off" },
> > >  { "vmport", "x-cmds-v2", "off" },
> > > +{ "virtio-device", "x-disable-legacy-check", "true" },  
> > 
> > Hm... not sure if we actually should add a new device property for
> > that. Maybe we can use a flag in the base machine type instead?  
> 
> I am not very experienced with machine types.
> I used the device property to easily access it from virtio devices.
> 
> Please, can you give me some suggestions where to look for the flags?

I was thinking about adding a new virtio_legacy_check flag into
MachineClass to get a machine-wide config and avoid introducing a new
config knob. The drawback is that every machine type supporting compat
machines would need to take care about disabling the check in their
5.1-or-older machines themselves.

Not sure what the preferable solution is; I'm not really opposed to
your approach, though.




Re: [PATCH v5 15/20] docs/devel/qapi-code-gen.txt: Update to new rST backend conventions

2020-09-17 Thread Markus Armbruster
Peter Maydell  writes:

> Update the documentation of QAPI document comment syntax to match
> the new rST backend requirements. The principal changes are:
>  * whitespace is now significant,

Well, differently significant :)

>   and multiline definitions
>must have their second and subsequent lines indented to
>match the first line
>  * general rST format markup is permitted, not just the small
>set of markup the old texinfo generator handled. For most
>things (notably bulleted and itemized lists) the old format
>is the same as rST was.
>  * Specific things that might trip people up:
>- instead of *bold* and _italic_ rST has **bold** and *italic*
>- lists need a preceding and following blank line
>- a lone literal '*' will need to be backslash-escaped to
>  avoid a rST syntax error
>  * the old leading '|' for example (literal text) blocks is
>replaced by the standard rST '::' literal block.
>  * headings and subheadings must now be in a freeform
>documentation comment of their own
>  * we support arbitrary levels of sub- and sub-sub-heading, not
>just a main and sub-heading like the old texinfo generator

Possibly noteworthy: lists can now be nested.

>
> Reviewed-by: Richard Henderson 
> Signed-off-by: Peter Maydell 
> ---
>  docs/devel/qapi-code-gen.txt | 90 
>  1 file changed, 61 insertions(+), 29 deletions(-)
>
> diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
> index 69eede6c283..263f1c0b44c 100644
> --- a/docs/devel/qapi-code-gen.txt
> +++ b/docs/devel/qapi-code-gen.txt
> @@ -824,21 +824,39 @@ See below for more on definition documentation.
>  Free-form documentation may be used to provide additional text and
>  structuring content.
>  
> + Headings and subheadings 
> +
> +A free-form documentation comment containing a single line
> +which starts with some '=' symbols and then a space defines
> +a section heading:
> +
> +##
> +# = This is a top level heading
> +##
> +
> +##
> +# This is a free-form comment which will go under the
> +# top level heading.
> +##
> +
> +##
> +# == This is a second level heading
> +##
> +
> +Section headings must always be correctly nested, so you can only
> +define a third-level heading inside a second-level heading, and so
> +on. The documentation generator will catch nesting mistakes and report
> +a syntax error.

Is the last sentence is useful?  We don't explicitly document other
parse errors.

>  
>   Documentation markup 
>  
> -Comment text starting with '=' is a section title:
> +Documentation comments can use most rST markup. In particular,

Please put two spaces after sentence-ending punctuation, for local
consistency, and to keep Emacs sentence commands working.

> +a '::' literal block can be used for examples:
>  
> -# = Section title
> -
> -Double the '=' for a subsection title:
> -
> -# == Subsection title
> -
> -'|' denotes examples:
> -
> -# | Text of the example, may span
> -# | multiple lines
> +# ::
> +#
> +#   Text of the example, may span
> +#   multiple lines
>  
>  '*' starts an itemized list:
>  
> @@ -854,37 +872,35 @@ A decimal number followed by '.' starts a numbered list:
>  #multiple lines
>  # 2. Second item
>  
> -The actual number doesn't matter.  You could even use '*' instead of
> -'2.' for the second item.
> +The actual number doesn't matter.
>  
> -Lists can't be nested.  Blank lines are currently not supported within
> -lists.
> +Lists of either kind must be preceded and followed by a blank line.
> +If a list item's text spans multiple lines, then the second and
> +subsequent lines must be correctly indented to line up with the
> +first character of the first line.
>  
> -Additional whitespace between the initial '#' and the comment text is
> -permitted.
> -
> -*foo* and _foo_ are for strong and emphasis styles respectively (they
> -do not work over multiple lines).  @foo is used to reference a name in
> -the schema.
> +The usual '**strong**', '*emphasised*' and '``literal``' markup should
> +be used. If you need a single literal '*' you will need to backslash-escape 
> it.

Long line.

> +As an extension beyond the usual rST syntax, you can also
> +use '@foo' to reference a name in the schema; this is rendered
> +the same way as '``foo``'.
>  
>  Example:
>  
>  ##
> -# = Section
> -# == Subsection
> -#
> -# Some text foo with *strong* and _emphasis_
> +# Some text foo with **bol** and *emphasis*

Do you mean **bold**?

>  # 1. with a list
>  # 2. like that
>  #
>  # And some code:
> -# | $ echo foo
> -# | -> do this
> -# | <- get that
>  #
> +# ::
> +#
> +#   $ echo foo
> +#   -> do this
> +#   <- get that
>  ##
>  
> -

Did you mean to drop the blank line?

>   Definition documentation 
>  
>  Definition documentation, if present, must immediately precede the
> @@ -899,6 +915,12 @@ com

Re: QEMU policy for real file tests

2020-09-17 Thread Alex Bennée


Christian Schoenebeck  writes:

> Hi,
>
> is there a QEMU policy for test cases that create/write/read/delete real 
> files 
> and directories? E.g. should they be situated at a certain location and is 
> any 
> measure of sandboxing required?

I don't think we have a hard and fast policy. It also depends on what
you are doing the test in - but ideally you should use a secure mktempd
(that can't clash) and clean-up after you are finished. This is a bit
easier in python than shell I think.

For example iotests end up in $BUILD_DIR/scratch (driven by TEST_DIR
being set somewhere) whereas the gdb stub tests use socket_dir =
TemporaryDirectory("qemu-gdbstub") which get auto-cleaned when it
finishes.


-- 
Alex Bennée



[Bug 1892604] Re: qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion `addr <= GINTSTS2' failed.

2020-09-17 Thread Paul Zimmerman
The URL to the image I used is
http://downloads.raspberrypi.org/raspbian/images/raspbian-2019-09-30/2019-09-26
-raspbian-buster.zip

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

Title:
  qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion
  `addr <= GINTSTS2' failed.

Status in QEMU:
  New

Bug description:
  When trying to run the 2016-05-27 Raspbian image on the emulated
  raspi2 platform, the system boots but shortly after the login prompt
  QEMU (master; commit ID ca489cd037e4d50dc6c40570a167504ad7e5a521) dies
  with:

  qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion
  `addr <= GINTSTS2' failed.

  Steps to reproduce:

  1. Get the image: wget
  
http://downloads.raspberrypi.org/raspbian/images/raspbian-2016-05-31/2016-05-27
  -raspbian-jessie.zip

  2. Extract the kernel image and DTB:

  sudo losetup -f --show -P 2016-05-27-raspbian-jessie.img
  sudo mkdir /mnt/rpi
  sudo mount /dev/loop11p1 /mnt/rpi/
  cp /mnt/rpi/kernel7.img . 



  cp /mnt/rpi/bcm2709-rpi-2-b.dtb . 



  sudo umount /mnt/rpi 
  sudo losetup -d /dev/loop11 

  3. Run QEMU:
  qemu-system-arm -M raspi2 -m 1G -dtb bcm2709-rpi-2-b.dtb -kernel kernel7.img 
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 
root=/dev/mmcblk0p2" -sd 2016-05-27-raspbian-jessie.img -smp 4 -serial stdio 
-display none

  A few seconds after the login prompt is displayed, QEMU will exit with
  the assertion failure.

  I also tried changing all of the asserts to if statements that (for
  MMIO reads) returned 0 and (for writes) just returned, but this
  resulted in a non-responsive system.

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



Re: [PATCH 2/3] virtio-blk: undo destructive iov_discard_*() operations

2020-09-17 Thread Stefan Hajnoczi
On Wed, Sep 16, 2020 at 11:38:36PM +0800, Li Qiang wrote:
> Stefan Hajnoczi  于2020年8月12日周三 下午6:51写道:
> > @@ -644,7 +648,8 @@ static int virtio_blk_handle_request(VirtIOBlockReq 
> > *req, MultiReqBuffer *mrb)
> >  req->in = (void *)in_iov[in_num - 1].iov_base
> >+ in_iov[in_num - 1].iov_len
> >- sizeof(struct virtio_blk_inhdr);
> > -iov_discard_back(in_iov, &in_num, sizeof(struct virtio_blk_inhdr));
> > +iov_discard_back_undoable(in_iov, &in_num, sizeof(struct 
> > virtio_blk_inhdr),
> > +  &req->inhdr_undo);
> >
> >  type = virtio_ldl_p(vdev, &req->out.type);
> >
> 
> It seems there is another error path need to do the undo operations.
> case VIRTIO_BLK_T_WRITE_ZEROS & ~VIRTIO_BLK_T_OUT
> handler has an error path.

Yes, thank you! I'll fix it in the next revision.

Stefan


signature.asc
Description: PGP signature


Re: Use patchew to push successfully applied series to GitLab

2020-09-17 Thread Daniel P . Berrangé
On Thu, Sep 17, 2020 at 10:53:14AM +0200, Paolo Bonzini wrote:
> On 17/09/20 10:16, Philippe Mathieu-Daudé wrote:
> > patchew is currently pushing successfully applied series
> > (using the cover Message-ID as tag) to GitHub.
> > This is very handy (no need to apply patches manually):
> > https://github.com/patchew-project/qemu/tags
> > 
> > Can we push the same that to an equivalent GitLab account?
> > We could then have a script replying to the series if the
> > series fails CI. Doing so would save reviewer/tester time
> > (I'd rather have a series not failing on our CI tests before
> > starting to review/test it).
> 
> Yes, we could.  Indeed we could also look at the pipeline result instead
> of needing Patchew's custom testers (using a webhook).  It would be a
> bit on the heavy side for GitLab's resources; while right now they're
> still providing unlimited CI time, in principle the "gold" tier provides
> "only" 833 hours and a full CI run takes more or less 1.

Yep, this is a limitation of the patchew model where we have a central
service testing each contributors patches, instead of having the CI jobs
running in context of a user's fork and thus havin the CI usage cost
ammoritized across all user's accounts.

In a merge request workflow, this pretty much "just works" because the
CI jobs alwas run in the user's fork before the merge request is opened,
or when force-pushed.

Assuming we're not adopting a merge request workflow in the near term,
I wonder if we could do something clever to improve our mailing list
workflow CI to get jobs running mostly in user's forks.

A large number of contributors use "git-publish" to send patches. That
is already capable of optionally pushing to a public git server for
pull requests.

What if we used git-publish to always push to gitlab when submitting
patches, and have it include the gitlab ref in the cover letter.

That would trigger CI jobs in the user's fork, and patchew would not
have to run anything itself. It would merely monitor the user's fork
and report back to the list if the job failed. Patchew would ony then
have to run stuff in its own shared fork if the user didn't include
a gitlab ref in their cover letter.  At least this works for x86
Linux stuff. Doesn't work for any scenario needing custom runners.

Still if our regular contributors went this way, the shared fork
could have much lower build job load than we see today.

> So it would work great but we would have to set up our own runners,
> and/or have a cheaper pipeline for this gating CI.  Is that possible to
> configure in Gitlab?

The ideal situation is that we have one set of defined jobs that are
used universally by the person merging to git master, by patchew, by
any contributors before posting.

In terms of traditional build jobs, we have a huge number defined in
GitLab CI but it is only a partially overlapping set vs patchew,
principally because the GitLab jobs are x86 only. For the non-x86 stuff we 
would have to define
jobs that target custom runners and then have custom runners registered
against Patchew's account. If quota becomes a problem, we'd nede x86 custom
runners too.

The other useful part of patchew is the "checkpatch.pl" validation.
We should really create a job in GitLab CI that covers this, as it
is something that's useful for developers to get right before posting.

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




Re: QEMU policy for real file tests

2020-09-17 Thread Daniel P . Berrangé
On Thu, Sep 17, 2020 at 10:26:36AM +0100, Alex Bennée wrote:
> 
> Christian Schoenebeck  writes:
> 
> > Hi,
> >
> > is there a QEMU policy for test cases that create/write/read/delete real 
> > files 
> > and directories? E.g. should they be situated at a certain location and is 
> > any 
> > measure of sandboxing required?
> 
> I don't think we have a hard and fast policy. It also depends on what
> you are doing the test in - but ideally you should use a secure mktempd
> (that can't clash) and clean-up after you are finished. This is a bit
> easier in python than shell I think.

mktempd will end up on /tmp usually which can be tmpfs and size limited,
so be mindful of the size of files you create. Don't assume you can
create multi-GB sized files !  Creating a temp dir underneath the build
dir (effectively CWD of the test) is a reasonable alternative.

> For example iotests end up in $BUILD_DIR/scratch (driven by TEST_DIR
> being set somewhere) whereas the gdb stub tests use socket_dir =
> TemporaryDirectory("qemu-gdbstub") which get auto-cleaned when it
> finishes.

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




Re: [PATCH v10 00/12] *** A Method for evaluating dirty page rate ***

2020-09-17 Thread Dr. David Alan Gilbert
* Zheng Chuan (zhengch...@huawei.com) wrote:
> 
> 
> On 2020/9/17 17:15, Dr. David Alan Gilbert wrote:
> > * Chuan Zheng (zhengch...@huawei.com) wrote:
> >> v9 -> v10:
> >> rename find_page_matched as find_block_matched
> >> fix wrong termination condition in find_block_matched
> >> add review-by for patches
> >>
> >> v8 -> v9:
> >> fix wrong index return of record_ramblock_hash_info
> >> optimize variable name according to review
> >> reset dirty_rate as -1
> >> change returns of compare_page_hash_info to bool
> >>
> >> v7 -> v8:
> >> add atomic_read for dirtyrate status
> >> add error_report if set dirtyrate state failed
> >> change returns of save_ramblock_hash and record_ramblock_hash_info to 
> >> bool
> >> alloc ramblock dirtyinfo array at one time
> >> add review-by for patches
> >>
> >> v6 -> v7:
> >> fix minior comments and coding style by review
> >> add review-by for patches
> >>
> >> v5 -> v6:
> >> fix coding style according to review
> >> use TARGET_PAGE_SIZE and TARGET_PAGE_BITS instead of self-defined 
> >> macros
> >> return start-time and calc-time by qmp command
> >>
> >> v4 -> v5:
> >> fix git apply failed due to meson-build
> >> add review-by for patches in v3
> >>
> >> v3 -> v4:
> >> use crc32 to get hash result instead of md5
> >> add DirtyRateStatus to denote calculation status
> >> add some trace_calls to make it easier to debug
> >> fix some comments accroding to review
> >>
> >> v2 -> v3:
> >> fix size_t compile warning
> >> fix codestyle checked by checkpatch.pl
> >>
> >> v1 -> v2:
> >> use g_rand_new() to generate rand_buf
> >> move RAMBLOCK_FOREACH_MIGRATABLE into migration/ram.h
> >> add skip_sample_ramblock to filter sampled ramblock
> >> fix multi-numa vm coredump when query dirtyrate
> >> rename qapi interface and rename some structures and functions
> >> succeed to compile by appling each patch
> >> add test for migrating vm
> >>
> >> Sometimes it is neccessary to evaluate dirty page rate before migration.
> >> Users could decide whether to proceed migration based on the evaluation
> >> in case of vm performance loss due to heavy workload.
> >> Unlikey simulating dirtylog sync which could do harm on runnning vm,
> >> we provide a sample-hash method to compare hash results for samping page.
> >> In this way, it would have hardly no impact on vm performance.
> >>
> >> Evaluate the dirtypage rate both on running and migration vm.
> >> The VM specifications for migration are as follows:
> >> - VM use 4-K page;
> >> - the number of VCPU is 32;
> >> - the total memory is 32Gigabit;
> >> - use 'mempress' tool to pressurize VM(mempress 4096 1024);
> >> - migration bandwidth is 1GB/s
> >>
> >> +++
> >> |  |  running  |  migrating
> >>|
> >> +++
> >> | no mempress  |   4MB/s   |  8MB/s  (migrated 
> >> success)   |
> >> ---
> >> | mempress 4096 1024   |  1060MB/s | 456MB/s ~ 1142MB/s (cpu throttle 
> >> triggered)  |
> >> +++
> >> | mempress 4096 4096   |  4114MB/s | 688MB/s ~ 4132MB/s (cpu throttle 
> >> triggered)  |
> >> +++
> >>
> >> Test dirtyrate by qmp command like this:
> >> 1.  virsh qemu-monitor-command [vmname] '{"execute":"calc-dirty-rate", 
> >> "arguments": {"calc-time": [sleep-time]}}'; 
> >> 2.  sleep specific time which is a bit larger than sleep-time
> >> 3.  virsh qemu-monitor-command [vmname] '{"execute":"query-dirty-rate"}'
> > 
> > Thanks; it looks like we have a full set of reviews; I'll try and add
> > this for the next migration pull.
> > 
> >> The qmp command returns like this:
> >> {"return":{"status":"measured","dirty-rate":374,"start-time":3718293,"calc-time":1},"id":"libvirt-15"}
> >>
> >> Further test dirtyrate by libvirt api like this:
> >> virsh getdirtyrate [vmname] [sleep-time]
> > 
> > So do you have some libvirt patches you're going to post?
> > 
> > Dave
> > 
> 
> Hi, Dave.
> 
> Yes, libvirt(including libvirt-python) interface will come after this qemu 
> series patch:)

OK, great; please cc in jdene...@redhat.com when you do.

Dave

> >> Chuan Zheng (12):
> >>   migration/dirtyrate: setup up query-dirtyrate framwork
> >>   migration/dirtyrate: add DirtyRateStatus to denote calculation status
> >>   migration/dirtyrate: Add RamblockDirtyInfo to store sampled page info
> >>   migration/dirtyrate: Add dirtyrate statistics series functions
> >>   migration/dirtyrate: move RAMBLOCK_

[PATCH v2 2/3] virtio-blk: undo destructive iov_discard_*() operations

2020-09-17 Thread Stefan Hajnoczi
Fuzzing discovered that virtqueue_unmap_sg() is being called on modified
req->in/out_sg iovecs. This means dma_memory_map() and
dma_memory_unmap() calls do not have matching memory addresses.

Fuzzing discovered that non-RAM addresses trigger a bug:

  void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len,
   bool is_write, hwaddr access_len)
  {
  if (buffer != bounce.buffer) {
  ^^^

A modified iov->iov_base is no longer recognized as a bounce buffer and
the wrong branch is taken.

There are more potential bugs: dirty memory is not tracked correctly and
MemoryRegion refcounts can be leaked.

Use the new iov_discard_undo() API to restore elem->in/out_sg before
virtqueue_push() is called.

Reported-by: Alexander Bulekov 
Buglink: https://bugs.launchpad.net/qemu/+bug/1890360
Fixes: 827805a2492c1bbf1c0712ed18ee069b4ebf3dd6 ("virtio-blk: Convert 
VirtIOBlockReq.out to structrue")
Signed-off-by: Stefan Hajnoczi 
---
 include/hw/virtio/virtio-blk.h |  2 ++
 hw/block/virtio-blk.c  | 11 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h
index 29c9f32353..df3876d49c 100644
--- a/include/hw/virtio/virtio-blk.h
+++ b/include/hw/virtio/virtio-blk.h
@@ -72,6 +72,8 @@ typedef struct VirtIOBlockReq {
 int64_t sector_num;
 VirtIOBlock *dev;
 VirtQueue *vq;
+IOVDiscardUndo inhdr_undo;
+IOVDiscardUndo outhdr_undo;
 struct virtio_blk_inhdr *in;
 struct virtio_blk_outhdr out;
 QEMUIOVector qiov;
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 2204ba149e..bac2d6fa2b 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -80,6 +80,8 @@ static void virtio_blk_req_complete(VirtIOBlockReq *req, 
unsigned char status)
 trace_virtio_blk_req_complete(vdev, req, status);
 
 stb_p(&req->in->status, status);
+iov_discard_undo(&req->inhdr_undo);
+iov_discard_undo(&req->outhdr_undo);
 virtqueue_push(req->vq, &req->elem, req->in_len);
 if (s->dataplane_started && !s->dataplane_disabled) {
 virtio_blk_data_plane_notify(s->dataplane, req->vq);
@@ -632,10 +634,12 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 return -1;
 }
 
-iov_discard_front(&out_iov, &out_num, sizeof(req->out));
+iov_discard_front_undoable(&out_iov, &out_num, sizeof(req->out),
+   &req->outhdr_undo);
 
 if (in_iov[in_num - 1].iov_len < sizeof(struct virtio_blk_inhdr)) {
 virtio_error(vdev, "virtio-blk request inhdr too short");
+iov_discard_undo(&req->outhdr_undo);
 return -1;
 }
 
@@ -644,7 +648,8 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 req->in = (void *)in_iov[in_num - 1].iov_base
   + in_iov[in_num - 1].iov_len
   - sizeof(struct virtio_blk_inhdr);
-iov_discard_back(in_iov, &in_num, sizeof(struct virtio_blk_inhdr));
+iov_discard_back_undoable(in_iov, &in_num, sizeof(struct virtio_blk_inhdr),
+  &req->inhdr_undo);
 
 type = virtio_ldl_p(vdev, &req->out.type);
 
@@ -739,6 +744,8 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 
 if (unlikely(iov_to_buf(out_iov, out_num, 0, &dwz_hdr,
 sizeof(dwz_hdr)) != sizeof(dwz_hdr))) {
+iov_discard_undo(&req->inhdr_undo);
+iov_discard_undo(&req->outhdr_undo);
 virtio_error(vdev, "virtio-blk discard/write_zeroes header"
  " too short");
 return -1;
-- 
2.26.2



[PATCH v2 0/3] virtio: restore elem->in/out_sg after iov_discard_front/back()

2020-09-17 Thread Stefan Hajnoczi
v2:
 * Add missing undo in virtio-blk write zeroes error path [Li Qiang]

Both virtio-blk and virtio-crypto use destructive iov_discard_front/back()
operations on elem->in/out_sg. virtqueue_push() calls dma_memory_unmap() on the
modified iovec arrays. The memory addresses may not match those originally
mapped with dma_memory_map().

This raises several issues:
1. MemoryRegion references can be leaked.
2. Dirty memory may not be tracked.
3. The non-RAM bounce buffer can be leaked.

This patch series solves the issue in two ways:
1. virtio-blk uses a new iov_discard_undo() API to restore iovec arrays.
2. virtio-crypto uses g_memdup() to avoid modifying the original iovec arrays.

The g_memdup() approach is slower than iov_discard_undo() but less
complex/fragile. I am less familiar with the virtio-crypto code and it uses
more complex sequences of iov_discard_front/back() calls than virtio-blk. If
anyone feels like optimizing virtio-crypto, please go ahead.

The virtio-blk bug was found by Alexander Bulekov's fuzzing effort. I found the
virtio-crypto bug through code inspection.

Stefan Hajnoczi (3):
  util/iov: add iov_discard_undo()
  virtio-blk: undo destructive iov_discard_*() operations
  virtio-crypto: don't modify elem->in/out_sg

 include/hw/virtio/virtio-blk.h |   2 +
 include/qemu/iov.h |  23 +
 hw/block/virtio-blk.c  |  11 ++-
 hw/virtio/virtio-crypto.c  |  17 +++-
 tests/test-iov.c   | 165 +
 util/iov.c |  50 +-
 6 files changed, 259 insertions(+), 9 deletions(-)

-- 
2.26.2



[PATCH v2 1/3] util/iov: add iov_discard_undo()

2020-09-17 Thread Stefan Hajnoczi
The iov_discard_front/back() operations are useful for parsing iovecs
but they modify the array elements. If the original array is needed
after parsing finishes there is currently no way to restore it.

Although g_memdup() can be used before performing destructive
iov_discard_front/back() operations, this is inefficient.

Introduce iov_discard_undo() to restore the array to the state prior to
an iov_discard_front/back() operation.

Reviewed-by: Li Qiang 
Signed-off-by: Stefan Hajnoczi 
---
 include/qemu/iov.h |  23 +++
 tests/test-iov.c   | 165 +
 util/iov.c |  50 --
 3 files changed, 234 insertions(+), 4 deletions(-)

diff --git a/include/qemu/iov.h b/include/qemu/iov.h
index bffc151282..b6b283a5e5 100644
--- a/include/qemu/iov.h
+++ b/include/qemu/iov.h
@@ -130,6 +130,29 @@ size_t iov_discard_front(struct iovec **iov, unsigned int 
*iov_cnt,
 size_t iov_discard_back(struct iovec *iov, unsigned int *iov_cnt,
 size_t bytes);
 
+/* Information needed to undo an iov_discard_*() operation */
+typedef struct {
+struct iovec *modified_iov;
+struct iovec orig;
+} IOVDiscardUndo;
+
+/*
+ * Undo an iov_discard_front_undoable() or iov_discard_back_undoable()
+ * operation. If multiple operations are made then each one needs a separate
+ * IOVDiscardUndo and iov_discard_undo() must be called in the reverse order
+ * that the operations were made.
+ */
+void iov_discard_undo(IOVDiscardUndo *undo);
+
+/*
+ * Undoable versions of iov_discard_front() and iov_discard_back(). Use
+ * iov_discard_undo() to reset to the state before the discard operations.
+ */
+size_t iov_discard_front_undoable(struct iovec **iov, unsigned int *iov_cnt,
+  size_t bytes, IOVDiscardUndo *undo);
+size_t iov_discard_back_undoable(struct iovec *iov, unsigned int *iov_cnt,
+ size_t bytes, IOVDiscardUndo *undo);
+
 typedef struct QEMUIOVector {
 struct iovec *iov;
 int niov;
diff --git a/tests/test-iov.c b/tests/test-iov.c
index 458ca25099..9c415e2f1f 100644
--- a/tests/test-iov.c
+++ b/tests/test-iov.c
@@ -26,6 +26,12 @@ static void iov_free(struct iovec *iov, unsigned niov)
 g_free(iov);
 }
 
+static bool iov_equals(const struct iovec *a, const struct iovec *b,
+   unsigned niov)
+{
+return memcmp(a, b, sizeof(a[0]) * niov) == 0;
+}
+
 static void test_iov_bytes(struct iovec *iov, unsigned niov,
size_t offset, size_t bytes)
 {
@@ -335,6 +341,87 @@ static void test_discard_front(void)
 iov_free(iov, iov_cnt);
 }
 
+static void test_discard_front_undo(void)
+{
+IOVDiscardUndo undo;
+struct iovec *iov;
+struct iovec *iov_tmp;
+struct iovec *iov_orig;
+unsigned int iov_cnt;
+unsigned int iov_cnt_tmp;
+size_t size;
+
+/* Discard zero bytes */
+iov_random(&iov, &iov_cnt);
+iov_orig = g_memdup(iov, sizeof(iov[0]) * iov_cnt);
+iov_tmp = iov;
+iov_cnt_tmp = iov_cnt;
+iov_discard_front_undoable(&iov_tmp, &iov_cnt_tmp, 0, &undo);
+iov_discard_undo(&undo);
+assert(iov_equals(iov, iov_orig, iov_cnt));
+g_free(iov_orig);
+iov_free(iov, iov_cnt);
+
+/* Discard more bytes than vector size */
+iov_random(&iov, &iov_cnt);
+iov_orig = g_memdup(iov, sizeof(iov[0]) * iov_cnt);
+iov_tmp = iov;
+iov_cnt_tmp = iov_cnt;
+size = iov_size(iov, iov_cnt);
+iov_discard_front_undoable(&iov_tmp, &iov_cnt_tmp, size + 1, &undo);
+iov_discard_undo(&undo);
+assert(iov_equals(iov, iov_orig, iov_cnt));
+g_free(iov_orig);
+iov_free(iov, iov_cnt);
+
+/* Discard entire vector */
+iov_random(&iov, &iov_cnt);
+iov_orig = g_memdup(iov, sizeof(iov[0]) * iov_cnt);
+iov_tmp = iov;
+iov_cnt_tmp = iov_cnt;
+size = iov_size(iov, iov_cnt);
+iov_discard_front_undoable(&iov_tmp, &iov_cnt_tmp, size, &undo);
+iov_discard_undo(&undo);
+assert(iov_equals(iov, iov_orig, iov_cnt));
+g_free(iov_orig);
+iov_free(iov, iov_cnt);
+
+/* Discard within first element */
+iov_random(&iov, &iov_cnt);
+iov_orig = g_memdup(iov, sizeof(iov[0]) * iov_cnt);
+iov_tmp = iov;
+iov_cnt_tmp = iov_cnt;
+size = g_test_rand_int_range(1, iov->iov_len);
+iov_discard_front_undoable(&iov_tmp, &iov_cnt_tmp, size, &undo);
+iov_discard_undo(&undo);
+assert(iov_equals(iov, iov_orig, iov_cnt));
+g_free(iov_orig);
+iov_free(iov, iov_cnt);
+
+/* Discard entire first element */
+iov_random(&iov, &iov_cnt);
+iov_orig = g_memdup(iov, sizeof(iov[0]) * iov_cnt);
+iov_tmp = iov;
+iov_cnt_tmp = iov_cnt;
+iov_discard_front_undoable(&iov_tmp, &iov_cnt_tmp, iov->iov_len, &undo);
+iov_discard_undo(&undo);
+assert(iov_equals(iov, iov_orig, iov_cnt));
+g_free(iov_orig);
+iov_free(iov, iov_cnt);
+
+/* Discard within second element */
+iov_random(&iov, &iov_cnt);
+iov_orig = 

  1   2   3   4   5   >