Re: [RFC v5 06/68] target/riscv: rvv-1.0: add translation-time vector context status

[Frank Chang]

On Sat, Oct 3, 2020 at 12:19 AM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 9/29/20 2:03 PM, frank.ch...@sifive.com wrote:
> > +++ b/target/riscv/insn_trans/trans_rvv.c.inc
> > @@ -41,6 +41,7 @@ static bool trans_vsetvl(DisasContext *ctx, arg_vsetvl
> *a)
> >  gen_get_gpr(s2, a->rs2);
> >  gen_helper_vsetvl(dst, cpu_env, s1, s2);
> >  gen_set_gpr(a->rd, dst);
> > +mark_vs_dirty(ctx);
> >  tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn);
> >  lookup_and_goto_ptr(ctx);
> >  ctx->base.is_jmp = DISAS_NORETURN;
> > @@ -72,7 +73,7 @@ static bool trans_vsetvli(DisasContext *ctx,
> arg_vsetvli *a)
> >  }
> >  gen_helper_vsetvl(dst, cpu_env, s1, s2);
> >  gen_set_gpr(a->rd, dst);
> > -gen_goto_tb(ctx, 0, ctx->pc_succ_insn);
> > +mark_vs_dirty(ctx);
>
> Removing the gen_goto_tb can't be right all by itself.
>

Oops, I think I somehow mess up the commits.
This commit should only contain: + mark_vs_dirty(ctx); change.
The - gen_goto_tb(ctx, 0, ctx->pc_succ_insn); should be included and
replaced by:
+ tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn);
+ lookup_and_goto_ptr(ctx);
in later commit: target/riscv: rvv-1.0: update check functions.


> I think you want to be sharing the code between vsetvl and vsetvli now.
> Just
> pass in a TCGv value to a common helper.
>

The only difference now between vsetvl and vsetvli is the format of zimm
and s2 fields.
But they have different formats and are queried by different functions,
i.e. s2 = tcg_const_tl(a->zimm); and gen_get_gpr(s2, a->rs2);

Is there any elegant way to retrieve the values of zimm and s2 by shared
common codes?


>
> r~
>

Thanks,
Frank Chang

Re: [PATCH v5 10/10] migration: introduce snapshot-{save, load, delete} QMP commands

[Markus Armbruster]

Eric Blake  writes:

> On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
>> savevm, loadvm and delvm are some of the few HMP commands that have never
>> been converted to use QMP. The reasons for the lack of conversion are
>> that they blocked execution of the event thread, and the semantics
>> around choice of disks were ill-defined.
>> 
>> Despite this downside, however, libvirt and applications using libvirt
>> have used these commands for as long as QMP has existed, via the
>> "human-monitor-command" passthrough command. IOW, while it is clearly
>> desirable to be able to fix the problems, they are not a blocker to
>> all real world usage.
>> 
>> Meanwhile there is a need for other features which involve adding new
>> parameters to the commands. This is possible with HMP passthrough, but
>> it provides no reliable way for apps to introspect features, so using
>> QAPI modelling is highly desirable.
>> 
>> This patch thus introduces new snapshot-{load,save,delete} commands to
>> QMP that are intended to replace the old HMP counterparts. The new
>> commands are given different names, because they will be using the new
>> QEMU job framework and thus will have diverging behaviour from the HMP
>> originals. It would thus be misleading to keep the same name.
>> 
>> While this design uses the generic job framework, the current impl is
>> still blocking. The intention that the blocking problem is fixed later.
>> None the less applications using these new commands should assume that
>> they are asynchronous and thus wait for the job status change event to
>> indicate completion.
>> 
>> In addition to using the job framework, the new commands require the
>> caller to be explicit about all the block device nodes used in the
>> snapshot operations, with no built-in default heuristics in use.
>> 
>> Signed-off-by: Daniel P. Berrangé 
>> ---
>
>> +++ b/qapi/job.json
>> @@ -22,10 +22,17 @@
>>  #
>>  # @amend: image options amend job type, see "x-blockdev-amend" (since 5.1)
>>  #
>> +# @snapshot-load: snapshot load job type, see "snapshot-load" (since 5.2)
>> +#
>> +# @snapshot-save: snapshot save job type, see "snapshot-save" (since 5.2)
>> +#
>> +# @snapshot-delete: snapshot delete job type, see "snapshot-delete" (since 
>> 5.2)
>> +#
>>  # Since: 1.7
>>  ##
>>  { 'enum': 'JobType',
>> -  'data': ['commit', 'stream', 'mirror', 'backup', 'create', 'amend'] }
>> +  'data': ['commit', 'stream', 'mirror', 'backup', 'create', 'amend',
>> +   'snapshot-load', 'snapshot-save', 'snapshot-delete'] }
>>  
>>  ##
>>  # @JobStatus:
>> diff --git a/qapi/migration.json b/qapi/migration.json
>> index 7f5e6fd681..d2bd551ad9 100644
>> --- a/qapi/migration.json
>> +++ b/qapi/migration.json
>> @@ -1787,3 +1787,123 @@
>>  # Since: 5.2
>>  ##
>>  { 'command': 'query-dirty-rate', 'returns': 'DirtyRateInfo' }
>> +
>> +##
>> +# @snapshot-save:
>> +#
>> +# Save a VM snapshot
>> +#
>> +# @job-id: identifier for the newly created job
>> +# @tag: name of the snapshot to create
>> +# @devices: list of block device node names to save a snapshot to
>> +# @vmstate: block device node name to save vmstate to
>
> Here, you document vmstate last,...
>
>> +#
>> +# Applications should not assume that the snapshot save is complete
>> +# when this command returns. The job commands / events must be used
>> +# to determine completion and to fetch details of any errors that arise.
>> +#
>> +# Note that the VM CPUs will be paused during the time it takes to
>> +# save the snapshot

End the sentence with a period, please.

> "will be", or "may be"?  As you stated above, we may be able to lift the
> synchronous limitations down the road, while still maintaining the
> present interface of using this command to start the job and waiting on
> the job id until it is finished, at which point the CPUs might not need
> to be paused as much.

Could also add a sentence like "This may change in the future".

>> +#
>> +# It is strongly recommended that @devices contain all writable
>> +# block device nodes if a consistent snapshot is required.
>> +#
>> +# If @tag already exists, an error will be reported
>> +#
>> +# Returns: nothing
>> +#
>> +# Example:
>> +#
>> +# -> { "execute": "snapshot-save",
>> +#  "data": {
>> +# "job-id": "snapsave0",
>> +# "tag": "my-snap",
>> +# "vmstate": "disk0",
>> +# "devices": ["disk0", "disk1"]
>
> ...here vmstate occurs before devices.  I don't know if our doc
> generator cares about inconsistent ordering.

It does not.  It's questionable style, though.  Easy enough to tidy up.

>> +#  }
>> +#}
>> +# <- { "return": { } }
>> +#
>> +# Since: 5.2
>> +##
>> +{ 'command': 'snapshot-save',
>> +  'data': { 'job-id': 'str',
>> +'tag': 'str',
>> +'vmstate': 'str',
>> +'devices': ['str'] } }
>> +
>> +##
>> +# @snapshot-load:
>> +#
>> +# Load a VM snapshot
>> +#
>> +# @job-id: identifier for the newly created job
>> +# @tag: name of the snapshot to load.
>> +# @devic

Re: [PATCH 15/16] target/mips/cpu: Do not allow system-mode use without input clock

[Philippe Mathieu-Daudé]

+Thomas for qtest

On 9/29/20 4:40 PM, Philippe Mathieu-Daudé wrote:
> On 9/29/20 3:01 PM, Igor Mammedov wrote:
>> On Mon, 28 Sep 2020 19:15:38 +0200
>> Philippe Mathieu-Daudé  wrote:
>>
>>> Now than all QOM users provides the input clock, do not allow
>>> using a CPU core without its input clock connected on system-mode
>>> emulation. For user-mode, keep providing a fixed 200 MHz clock,
>>> as it used by the RDHWR instruction (see commit cdfcad788394).
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>> Cc: Igor Mammedov 
>>>
>>> We need the qtest check for tests/qtest/machine-none-test.c
>>> which instanciate a CPU with the none machine. Igor, is it
>>> better to remove the MIPS targets from the test cpus_map[]?
>>
>> I don't get idea, could you rephrase/elaborate?
> 
> cpu_class_init sets:
> 
> /*
>  * Reason: CPUs still need special care by board code: wiring up
>  * IRQs, adding reset handlers, halting non-first CPUs, ...
>  */
> dc->user_creatable = false;
> 
> but the CPUs are created via another path in vl.c:
> 
> current_machine->cpu_type = parse_cpu_option(cpu_option);
> 
> The machine-none-test assumes CPU objects are user-creatable.
> 
> With this patch I enforce MIPS CPU to have an input clock
> connected, so they are not user-creatable anymore.
> 
> I tried this code ...:
> 
> --- a/target/mips/cpu.c
> +++ b/target/mips/cpu.c
> @@ -229,7 +229,11 @@ static const TypeInfo mips_cpu_type_info = {
>  static void mips_cpu_cpudef_class_init(ObjectClass *oc, void *data)
>  {
>  MIPSCPUClass *mcc = MIPS_CPU_CLASS(oc);
> +DeviceClass *dc = DEVICE_CLASS(oc);
> +
>  mcc->cpu_def = data;
> +/* Reason: clock need to be wired up */
> +dc->user_creatable = false;
>  }
> 
> ... but it is ignored, the CPU can still be created.
> 
> Not sure how to handle this.
> 
>>
>>> ---
>>>  target/mips/cpu.c | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/target/mips/cpu.c b/target/mips/cpu.c
>>> index 2f75216c324..cc4ee75af30 100644
>>> --- a/target/mips/cpu.c
>>> +++ b/target/mips/cpu.c
>>> @@ -25,6 +25,7 @@
>>>  #include "kvm_mips.h"
>>>  #include "qemu/module.h"
>>>  #include "sysemu/kvm.h"
>>> +#include "sysemu/qtest.h"
>>>  #include "exec/exec-all.h"
>>>  #include "hw/qdev-clock.h"
>>>  #include "hw/qdev-properties.h"
>>> @@ -159,11 +160,18 @@ static void mips_cpu_realizefn(DeviceState *dev, 
>>> Error **errp)
>>>  Error *local_err = NULL;
>>>  
>>>  if (!clock_get(cs->clock)) {
>>> +#ifdef CONFIG_USER_ONLY
>>>  /*
>>>   * Initialize the frequency to 200MHz in case
>>>   * the clock remains unconnected.
>>>   */
>>>  clock_set_hz(cs->clock, 2);
>>> +#else
>>> +if (!qtest_enabled()) {
>>> +error_setg(errp, "CPU clock must be connected to a clock 
>>> source");
>>> +return;
>>> +}
>>> +#endif
>>>  }
>>>  mips_cpu_clk_update(cs);
>>>  
>>
> 

Re: [Phishing Risk] [External] [RFC PATCH 04/21] contrib/gitdm: Add ByteDance to the domain map

[Jiachen Zhang]

On Mon, Oct 5, 2020 at 2:04 AM Philippe Mathieu-Daudé 
wrote:

> There is a number of contributors from this domain,
> add its own entry to the gitdm domain map.
>
> Cc: Guoqing Zhang 
> Cc: Jiachen Zhang 
> Cc: Xie Yongji 
> Cc: Zhenwei Pi 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> One Reviewed-by/Ack-by from someone from this domain
> should be sufficient to get this patch merged.
> ---
>  contrib/gitdm/domain-map | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index 0eaa4ec051..7fd20b1bb0 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -9,6 +9,7 @@ amazon.com  Amazon
>  amazon.de   Amazon
>  amd.com AMD
>  baidu.com   Baidu
> +bytedance.com   ByteDance
>  cmss.chinamobile.com China Mobile
>  citrix.com  Citrix
>  greensocs.com   GreenSocs
> --
> 2.26.2
>
>
Acked-by: Jiachen Zhang 

Thanks!
Jiachen

Re: [PATCH 0/2] hw/mips: Code simplifications

[Philippe Mathieu-Daudé]

ping?

On 9/27/20 6:39 PM, Philippe Mathieu-Daudé wrote:
> Doing housekeeping on old branches older than 1 year.
> Some patches are still valuable, so post them.
> 
> These patches should not introduce logical change,
> they simply rewrite old style code using more recent
> API/macros.
> 
> Philippe Mathieu-Daudé (2):
>   hw/mips: Simplify loading 64-bit ELF kernels
>   hw/mips: Simplify code using ROUND_UP(INITRD_PAGE_SIZE)
> 
>  include/hw/mips/mips.h | 4 +++-
>  hw/mips/fuloong2e.c| 3 +--
>  hw/mips/malta.c| 6 +++---
>  hw/mips/mipssim.c  | 9 ++---
>  hw/mips/r4k.c  | 9 ++---
>  5 files changed, 11 insertions(+), 20 deletions(-)
> 

Re: [PATCH] qom: Improve error message displayed with missing object properties

[Philippe Mathieu-Daudé]

Eduardo, can you take this patch, or can it goes via qemu-trivial?

On 9/20/20 5:53 PM, Philippe Mathieu-Daudé wrote:
> Instead of only displaying the property missing, also display
> the object name. This help developer to quickly figure out the
> mistake without opening a debugger.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  qom/object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/qom/object.c b/qom/object.c
> index 387efb25ebe..257914b1fe3 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -1259,7 +1259,8 @@ ObjectProperty *object_property_find(Object *obj, const 
> char *name,
>  return prop;
>  }
>  
> -error_setg(errp, "Property '.%s' not found", name);
> +error_setg(errp, "Property '%s.%s' not found",
> +   object_get_typename(obj), name);
>  return NULL;
>  }
>  
> 

Re: [PATCH] hw/ssi/npcm7xx_fiu: Fix handling of unsigned integer

[Philippe Mathieu-Daudé]

Hi Peter,

Can you take this patch via your qemu-arm tree?

On 9/19/20 3:24 PM, Philippe Mathieu-Daudé wrote:
> Fix integer handling issues handling issue reported by Coverity:
> 
>   hw/ssi/npcm7xx_fiu.c: 162 in npcm7xx_fiu_flash_read()
>   >>> CID 1432730:  Integer handling issues  (NEGATIVE_RETURNS)
>   >>> "npcm7xx_fiu_cs_index(fiu, f)" is passed to a parameter that cannot 
> be negative.
>   162 npcm7xx_fiu_select(fiu, npcm7xx_fiu_cs_index(fiu, f));
> 
>   hw/ssi/npcm7xx_fiu.c: 221 in npcm7xx_fiu_flash_write()
>   218 cs_id = npcm7xx_fiu_cs_index(fiu, f);
>   219 trace_npcm7xx_fiu_flash_write(DEVICE(fiu)->canonical_path, 
> cs_id, addr,
>   220   size, v);
>   >>> CID 1432729:  Integer handling issues  (NEGATIVE_RETURNS)
>   >>> "cs_id" is passed to a parameter that cannot be negative.
>   221 npcm7xx_fiu_select(fiu, cs_id);
> 
> Since the index of the flash can not be negative, return an
> unsigned type.
> 
> Reported-by: Coverity (CID 1432729 & 1432730: NEGATIVE_RETURNS)
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/ssi/npcm7xx_fiu.c | 12 ++--
>  hw/ssi/trace-events  |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/ssi/npcm7xx_fiu.c b/hw/ssi/npcm7xx_fiu.c
> index 104e8f2b963..5040132b074 100644
> --- a/hw/ssi/npcm7xx_fiu.c
> +++ b/hw/ssi/npcm7xx_fiu.c
> @@ -103,7 +103,8 @@ enum NPCM7xxFIURegister {
>   * Returns the index of flash in the fiu->flash array. This corresponds to 
> the
>   * chip select ID of the flash.
>   */
> -static int npcm7xx_fiu_cs_index(NPCM7xxFIUState *fiu, NPCM7xxFIUFlash *flash)
> +static unsigned npcm7xx_fiu_cs_index(NPCM7xxFIUState *fiu,
> + NPCM7xxFIUFlash *flash)
>  {
>  int index = flash - fiu->flash;
>  
> @@ -113,20 +114,19 @@ static int npcm7xx_fiu_cs_index(NPCM7xxFIUState *fiu, 
> NPCM7xxFIUFlash *flash)
>  }
>  
>  /* Assert the chip select specified in the UMA Control/Status Register. */
> -static void npcm7xx_fiu_select(NPCM7xxFIUState *s, int cs_id)
> +static void npcm7xx_fiu_select(NPCM7xxFIUState *s, unsigned cs_id)
>  {
>  trace_npcm7xx_fiu_select(DEVICE(s)->canonical_path, cs_id);
>  
>  if (cs_id < s->cs_count) {
>  qemu_irq_lower(s->cs_lines[cs_id]);
> +s->active_cs = cs_id;
>  } else {
>  qemu_log_mask(LOG_GUEST_ERROR,
>"%s: UMA to CS%d; this module has only %d chip 
> selects",
>DEVICE(s)->canonical_path, cs_id, s->cs_count);
> -cs_id = -1;
> +s->active_cs = -1;
>  }
> -
> -s->active_cs = cs_id;
>  }
>  
>  /* Deassert the currently active chip select. */
> @@ -206,7 +206,7 @@ static void npcm7xx_fiu_flash_write(void *opaque, hwaddr 
> addr, uint64_t v,
>  NPCM7xxFIUFlash *f = opaque;
>  NPCM7xxFIUState *fiu = f->fiu;
>  uint32_t dwr_cfg;
> -int cs_id;
> +unsigned cs_id;
>  int i;
>  
>  if (fiu->active_cs != -1) {
> diff --git a/hw/ssi/trace-events b/hw/ssi/trace-events
> index 2f83ef833fb..612d3d6087a 100644
> --- a/hw/ssi/trace-events
> +++ b/hw/ssi/trace-events
> @@ -19,4 +19,4 @@ npcm7xx_fiu_deselect(const char *id, int cs) "%s deselect 
> CS%d"
>  npcm7xx_fiu_ctrl_read(const char *id, uint64_t addr, uint32_t data) "%s 
> offset: 0x%04" PRIx64 " value: 0x%08" PRIx32
>  npcm7xx_fiu_ctrl_write(const char *id, uint64_t addr, uint32_t data) "%s 
> offset: 0x%04" PRIx64 " value: 0x%08" PRIx32
>  npcm7xx_fiu_flash_read(const char *id, int cs, uint64_t addr, unsigned int 
> size, uint64_t value) "%s[%d] offset: 0x%08" PRIx64 " size: %u value: 0x%" 
> PRIx64
> -npcm7xx_fiu_flash_write(const char *id, int cs, uint64_t addr, unsigned int 
> size, uint64_t value) "%s[%d] offset: 0x%08" PRIx64 " size: %u value: 0x%" 
> PRIx64
> +npcm7xx_fiu_flash_write(const char *id, unsigned cs, uint64_t addr, unsigned 
> int size, uint64_t value) "%s[%d] offset: 0x%08" PRIx64 " size: %u value: 
> 0x%" PRIx64
> 

Re: [PATCH] ssi: Display chip select polarity in monitor 'info qtree'

[Philippe Mathieu-Daudé]

Hi Peter,

Can you take this patch via your qemu-arm tree please?
(most of SPI boards are ARM based)

On 9/27/20 11:19 AM, Philippe Mathieu-Daudé wrote:
> It is sometime useful to verify a device chip select polarity
> on a SPI bus. Since we have this information available, display
> it in the 'info qtree' monitor output:
> 
>   $ qemu-system-arm -M lm3s6965evb -monitor stdio -S
>   (qemu) info qtree
>   [...]
>   dev: pl022, id ""
> gpio-out "sysbus-irq" 1
> mmio 40008000/1000
> bus: ssi
>   type SSI
>   dev: ssd0323, id ""
> gpio-in "" 1
> gpio-in "ssi-gpio-cs" 1
> chip select polarity: high   <---
>   dev: ssi-sd, id ""
> gpio-in "ssi-gpio-cs" 1
> chip select polarity: low<---
> bus: sd-bus
>   type sd-bus
>   dev: sd-card, id ""
> spec_version = 2 (0x2)
> drive = "sd0"
> spi = true
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/ssi/ssi.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
> index 4278d0e4440..4c9f8d66d23 100644
> --- a/hw/ssi/ssi.c
> +++ b/hw/ssi/ssi.c
> @@ -17,6 +17,7 @@
>  #include "migration/vmstate.h"
>  #include "qemu/module.h"
>  #include "qapi/error.h"
> +#include "monitor/monitor.h"
>  #include "qom/object.h"
>  
>  struct SSIBus {
> @@ -26,10 +27,31 @@ struct SSIBus {
>  #define TYPE_SSI_BUS "SSI"
>  OBJECT_DECLARE_SIMPLE_TYPE(SSIBus, SSI_BUS)
>  
> +static void ssi_print_dev(Monitor *mon, DeviceState *dev, int indent)
> +{
> +static const char *const polarity_s[] = {
> +[SSI_CS_NONE] = "unknown",
> +[SSI_CS_LOW]  = "low",
> +[SSI_CS_HIGH] = "high"
> +};
> +SSISlaveClass *ssc = SSI_SLAVE_GET_CLASS(dev);
> +
> +monitor_printf(mon, "%*schip select polarity: %s\n",
> +   indent, "", polarity_s[ssc->cs_polarity]);
> +}
> +
> +static void ssi_bus_class_init(ObjectClass *klass, void *data)
> +{
> +BusClass *k = BUS_CLASS(klass);
> +
> +k->print_dev = ssi_print_dev;
> +}
> +
>  static const TypeInfo ssi_bus_info = {
>  .name = TYPE_SSI_BUS,
>  .parent = TYPE_BUS,
>  .instance_size = sizeof(SSIBus),
> +.class_init = ssi_bus_class_init,
>  };
>  
>  static void ssi_cs_default(void *opaque, int n, int level)
> 

Re: [PULL v2 00/92] Misc patches for 2020-09-24

[Philippe Mathieu-Daudé]

Hi Paolo,

On 9/25/20 1:44 PM, Peter Maydell wrote:
> On Fri, 25 Sep 2020 at 11:45, Peter Maydell  wrote:
>>
>> On Fri, 25 Sep 2020 at 11:33, Paolo Bonzini  wrote:
>>
>>  Date: Fri Sep 25 11:41:22 2020 +0100
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ERROR: pull request includes tag with UTF-8 error in person name
>>
>> (that's "configure: Do not intent to build WHPX on 32-bit host")
>>
>> (I will run the merge through the other tests to see if there's
>> any other issues with it.)
> 
> It also failed on the clang build: all the usermode binaries
> failed like this:
> 
> /usr/bin/ld: capstone/libcapstone.a(cs.o): relocation R_X86_64_32S
> against `.bss' can not be used when making a PIE object; recompile
> with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(utils.o): relocation R_X86_64_32S
> against symbol `cs_mem_malloc' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(ARMModule.o): relocation
> R_X86_64_32S against symbol `arch_init' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(AArch64Module.o): relocation
> R_X86_64_32S against symbol `arch_init' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(PPCModule.o): relocation
> R_X86_64_32S against symbol `arch_init' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86Module.o): relocation
> R_X86_64_32S against symbol `arch_init' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(ARMDisassembler.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(ARMInstPrinter.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(ARMMapping.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(AArch64Disassembler.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(AArch64InstPrinter.o): relocation
> R_X86_64_32S against symbol `cs_mem_free' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(AArch64Mapping.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(PPCDisassembler.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(PPCInstPrinter.o): relocation
> R_X86_64_32S against symbol `cs_mem_free' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(PPCMapping.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86Disassembler.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86IntelInstPrinter.o): relocation
> R_X86_64_32S against symbol `cs_mem_free' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86ATTInstPrinter.o): relocation
> R_X86_64_32S against symbol `cs_mem_free' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86Mapping.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE
> object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(AArch64BaseInfo.o): relocation
> R_X86_64_32S against symbol `cs_mem_free' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: capstone/libcapstone.a(X86DisassemblerDecoder.o):
> relocation R_X86_64_32S against `.rodata' can not be used when making
> a PIE object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output

Is that why your "configure: fix performance regression due to PIC
objects" patch has been dropped from your pull request?

Thanks,

Phil.

Re: [PATCH 0/2] .mailmap: Fixes since v5.1

[Erik Smit]

On Sun, 4 Oct 2020 at 19:26, Philippe Mathieu-Daudé  wrote:
>
> Fix incorrect entries committed during 5.1-5.2.
>
> To the developers Cc'ed:
>
> If you agree with your entry, please reply with a Reviewed-by /
> Acked-by tag. If you disagree or doesn't care, please either
> reply with Nack-by or ignore this patch.
> I'll repost in 2 weeks as formal patch (not RFC) with only the
> entries acked by their author.
>
> Regards,
>
> Phil.
>
> Philippe Mathieu-Daudé (2):
>   .mailmap: Correct Marek Dolata name
>   .mailmap: Fix more contributor entries
>
>  .mailmap | 8 
>  1 file changed, 8 insertions(+)
>
> --
> 2.26.2

Acked-by: Erik Smit 

Re: [PATCH v2] elfload: use g_new/g_malloc and g_autofree

[Markus Armbruster]

Please don't post respins as replies, because our tooling will miss them
there, and even humans may.  Start a new thread instead.  Next time :)

Elena Afanasova  writes:

> Subject: [PATCH v2] elfload: use g_new/g_malloc and g_autofree
>
> Signed-off-by: Elena Afanasova 
> ---
>  bsd-user/elfload.c | 79 --
>  1 file changed, 14 insertions(+), 65 deletions(-)
>
> diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
> index 32378af7b2..bc4be4c874 100644
> --- a/bsd-user/elfload.c
> +++ b/bsd-user/elfload.c
> @@ -838,7 +838,7 @@ static abi_ulong load_elf_interp(struct elfhdr * 
> interp_elf_ex,
>   int interpreter_fd,
>   abi_ulong *interp_load_addr)
>  {
> -struct elf_phdr *elf_phdata  =  NULL;
> +g_autofree struct elf_phdr *elf_phdata = NULL;
>  struct elf_phdr *eppnt;
>  abi_ulong load_addr = 0;
>  int load_addr_set = 0;
> @@ -867,18 +867,13 @@ static abi_ulong load_elf_interp(struct elfhdr * 
> interp_elf_ex,
>  if (sizeof(struct elf_phdr) * interp_elf_ex->e_phnum > 
> TARGET_PAGE_SIZE)
>  return ~(abi_ulong)0UL;
>  
> -elf_phdata =  (struct elf_phdr *)
> -malloc(sizeof(struct elf_phdr) * interp_elf_ex->e_phnum);
> -
> -if (!elf_phdata)
> -  return ~((abi_ulong)0UL);
> +elf_phdata = g_new(struct elf_phdr, interp_elf_ex->e_phnum);
>  
>  /*
>   * If the size of this structure has changed, then punt, since
>   * we will be doing the wrong thing.
>   */
>  if (interp_elf_ex->e_phentsize != sizeof(struct elf_phdr)) {
> -free(elf_phdata);
>  return ~((abi_ulong)0UL);
>  }
>  
> @@ -891,7 +886,6 @@ static abi_ulong load_elf_interp(struct elfhdr * 
> interp_elf_ex,
>  if (retval < 0) {
>  perror("load_elf_interp");
>  exit(-1);
> -free (elf_phdata);
>  return retval;
>  }
>  #ifdef BSWAP_NEEDED
> @@ -940,7 +934,6 @@ static abi_ulong load_elf_interp(struct elfhdr * 
> interp_elf_ex,
>  if (error == -1) {
>/* Real error */
>close(interpreter_fd);
> -  free(elf_phdata);
>return ~((abi_ulong)0UL);
>  }
>  
> @@ -983,7 +976,6 @@ static abi_ulong load_elf_interp(struct elfhdr * 
> interp_elf_ex,
>  PROT_READ|PROT_WRITE|PROT_EXEC,
>  MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0);
>  }
> -free(elf_phdata);
>  
>  *interp_load_addr = load_addr;
>  return ((abi_ulong) interp_elf_ex->e_entry) + load_addr;
> @@ -1036,9 +1028,10 @@ static void load_symbols(struct elfhdr *hdr, int fd)
>  {
>  unsigned int i, nsyms;
>  struct elf_shdr sechdr, symtab, strtab;
> -char *strings;
> -struct syminfo *s;
> -struct elf_sym *syms, *new_syms;
> +g_autofree char *strings = NULL;
> +g_autofree struct syminfo *s = NULL;
> +g_autofree struct elf_sym *syms = NULL;
> +struct elf_sym *new_syms;

Note for later: @strings, @syminfo and @syms are freed on return.

>  
>  lseek(fd, hdr->e_shoff, SEEK_SET);
>  for (i = 0; i < hdr->e_shnum; i++) {
> @@ -1064,24 +1057,12 @@ static void load_symbols(struct elfhdr *hdr, int fd)
>  
>   found:
>  /* Now know where the strtab and symtab are.  Snarf them. */
> -s = malloc(sizeof(*s));
> -syms = malloc(symtab.sh_size);
> -if (!syms) {
> -free(s);
> -return;
> -}
> -s->disas_strtab = strings = malloc(strtab.sh_size);
> -if (!s->disas_strtab) {
> -free(s);
> -free(syms);
> -return;
> -}
> +s = g_new(struct syminfo, 1);

The smaller change would be

   s = g_malloc(sizeof(*s));

Matter of taste.

> +syms = g_malloc(symtab.sh_size);
> +s->disas_strtab = strings = g_new(char, strtab.sh_size);

I'd prefer the simpler

   s->disas_strtab = strings = g_malloc(strtab.sh_size);

Yes, it returns void * whereas g_new() returns char *, but the char * is
vanishingly unlikely to catch actual bugs.

>  
>  lseek(fd, symtab.sh_offset, SEEK_SET);
>  if (read(fd, syms, symtab.sh_size) != symtab.sh_size) {
> -free(s);
> -free(syms);
> -free(strings);
>  return;
>  }
>  
> @@ -1113,22 +1094,13 @@ static void load_symbols(struct elfhdr *hdr, int fd)
>  that we threw away.  Whether or not this has any effect on the
>  memory allocation depends on the malloc implementation and how
>  many symbols we managed to discard. */
> -new_syms = realloc(syms, nsyms * sizeof(*syms));
> -if (new_syms == NULL) {
> -free(s);
> -free(syms);
> -free(strings);
> -return;
> -}
> +new_syms = g_realloc(syms, nsyms * sizeof(*syms));
>  syms = new_syms;
>  
>  qsort(syms, nsyms, si

Re: [PATCH 0/5] qapi: Restrict machine (and migration) specific commands

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> Reduce the machine code pulled into qemu-storage-daemon.

I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
Juan for PATCH 5.  David already ACKed.

Can do the pull request.

Re: [PATCH v2] sd: Exhibit support for CMD23

[Philippe Mathieu-Daudé]

Hi Sai,

On 9/16/20 7:51 PM, Sai Pavan Boddu wrote:
> Update 'SCR.CMD_SUPPORT' register with support of CMD23.
> 
> Signed-off-by: Sai Pavan Boddu 
> Reported-by: Rahul Thati 
> ---
> Changes for V2:
>   Fix commit message
> 
>  hw/sd/sd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 0012882..16d1b61 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -335,7 +335,7 @@ static void sd_set_scr(SDState *sd)
>  if (sd->spec_version >= SD_PHY_SPECv3_01_VERS) {
>  sd->scr[2] |= 1 << 7;   /* Spec Version 3.0X */
>  }
> -sd->scr[3] = 0x00;
> +sd->scr[3] = 0x2;   /* CMD23 supported */

You need to check:
- spec_version >= SD_PHY_SPECv3_01_VERS
- sd->size > SDSC_MAX_CAPACITY

Then you should also update the TRAN_SPEED value in sd_set_csd().

>  /* reserved for manufacturer usage */
>  sd->scr[4] = 0x00;
>  sd->scr[5] = 0x00;
> 

Re: [RFC PATCH 13/21] contrib/gitdm: Add more entries to the Red Hat domain

[Frediano Ziglio]

Hi,
  can I disagree? If the contribution is personal I use my personal
address, if the contribution is from the job in the company I'm using the
company address.

Regards,
   Frediano


Il giorno dom 4 ott 2020 alle ore 19:05 Philippe Mathieu-Daudé <
f4...@amsat.org> ha scritto:

> Cc: Frediano Ziglio 
> Cc: Frediano Ziglio 
> Cc: Nir Soffer 
> Cc: Nir Soffer 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> To the developers Cc'ed: If you agree with your entry, please
> reply with a Reviewed-by/Acked-by tag. If you disagree or doesn't
> care, please either reply with Nack-by or ignore this patch.
> I'll repost in 2 weeks as formal patch (not RFC) with only the
> entries acked by their author.
> ---
>  contrib/gitdm/group-map-redhat | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/contrib/gitdm/group-map-redhat
> b/contrib/gitdm/group-map-redhat
> index d15db2d35e..0419e82795 100644
> --- a/contrib/gitdm/group-map-redhat
> +++ b/contrib/gitdm/group-map-redhat
> @@ -6,3 +6,5 @@ da...@gibson.dropbear.id.au
>  laur...@vivier.eu
>  p...@fedoraproject.org
>  arm...@pond.sub.org
> +fredd...@gmail.com
> +nir...@gmail.com
> --
> 2.26.2
>
>

Re: [PATCH v2] tests/boot_linux_console: Boot Trusted Firmware-A on the Raspberry Pi 3

[Philippe Mathieu-Daudé]

On 2/17/20 11:34 AM, Philippe Mathieu-Daudé wrote:
> This test runs Trusted Firmware-A on the Raspberry Pi 3.
> We deliberately stop the boot process when the EDK2 UEFI version
> is displayed.
> 
> The binary is build on AppVeyor CI using Pete Batard repository [1].
> ATF v2.1 binary are used (see [2]). Extra documentation in [3].
> 
> It is very simple and fast:
> 
>   $ avocado --show=app,console run -t atf tests/acceptance
>   JOB ID : 1e748d7c9e9011cf0af3250ddc8ebf2389d6204e
>   JOB LOG: avocado/job-results/job-2020-02-16T18.08-1e748d7/job.log
>(1/1) 
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_aarch64_raspi3_atf:
>   console: NOTICE:  Booting Trusted Firmware
>   console: NOTICE:  BL1: v2.1(release):v2.1
>   console: NOTICE:  BL1: Built : 15:26:06, May 13 2019
>   console: NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) 
> [0x00a02082]
>   console: NOTICE:  BL1: Booting BL2
>   console: ERROR:   rpi3_sdhost: timeout status 0x40
>   console: NOTICE:  BL2: v2.1(release):v2.1
>   console: NOTICE:  BL2: Built : 15:26:01, May 13 2019
>   console: NOTICE:  BL1: Booting BL31
>   console: NOTICE:  BL31: v2.1(release):v2.1
>   console: NOTICE:  BL31: Built : 15:26:04, May 13 2019
>   console: =UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on 
> Feb 14 2020)
>   PASS (1.54 s)
>   RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
> CANCEL 0
>   JOB TIME   : 1.88 s
> 
> [1] https://github.com/pbatard/RPi3#summary
> [2] 
> https://github.com/ARM-software/arm-trusted-firmware/blob/v2.1/docs/plat/rpi3.rst
> [3] http://www.skylyrac.net/2018-02-01-port-arm-tf-to-rpi3.html
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v2: Start with a single core powered-on
> ---
>  tests/acceptance/boot_linux_console.py | 24 
>  1 file changed, 24 insertions(+)

Thanks, applied to my acceptance-testing tree.

Re: [PATCH] tests/acceptance: Add a 'virt_kvm' test using the GICv3

[Philippe Mathieu-Daudé]

On 9/30/20 12:48 AM, Philippe Mathieu-Daudé wrote:
> The current 'virt_kvm' test is restricted to GICv2, but can also
> work with a GICv3. Duplicate it but add a GICv3 test which can be
> tested on some hardware.
> 
> Noticed while running:
> 
>  $ avocado --show=app run -t machine:virt tests/acceptance/
>  ...
>  (2/6) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm: ERROR: 
> Unexpected empty reply from server (1.82 s)
> 
> The job.log content is:
> 
>   L0351 DEBUG| Output: 'qemu-system-aarch64: host does not support in-kernel 
> GICv2 emulation\n'
> 
> With this patch:
> 
>  $ avocado --show=app run -t device:gicv3 tests/acceptance/
>  (1/1) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm_gicv3: 
> PASS (55.10 s)
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/boot_linux.py | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)

Thanks, applied to my acceptance-testing tree.

Re: scripts/gdb: issues when loading modules after lx-symbols

[Stefano Garzarella]

On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
> On 01.10.20 16:31, Stefano Garzarella wrote:
> > Hi,
> > I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
> > 
> > If the modules are already loaded, and I do 'lx-symbols', all work fine.
> > But, if I load a kernel module after 'lx-symbols', I had this issue:
> > 
> > [ 5093.393940] invalid opcode:  [#1] SMP PTI
> > [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
> > 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
> > [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > 1.13.0-2.fc32 04/01/2014
> > [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
> > [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 c1 
> > fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 cc 
> > <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
> > [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
> > [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
> > 4ee3
> > [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
> > c010a0c0
> > [ 5093.416349] RBP: c9563e50 R08:  R09: 
> > 0002
> > [ 5093.418044] R10: 0096 R11: 08a4 R12: 
> > 88807a0d1280
> > [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
> > c9563e70
> > [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
> > knlGS:
> > [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
> > [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
> > 00170ef0
> > [ 5093.435096] DR0:  DR1:  DR2: 
> > 
> > [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
> > 0400
> > [ 5093.439689] Call Trace:
> > [ 5093.440954]  ? load_module+0x24b6/0x27d0
> > [ 5093.443212]  ? __kernel_read+0xd6/0x150
> > [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
> > [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
> > [ 5093.449098]  do_syscall_64+0x38/0x50
> > [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 5093.456153] RIP: 0033:0x7f018f75c43d
> > [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 
> > 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 
> > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
> > [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
> > 0139
> > [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
> > 7f018f75c43d
> > [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
> > 0003
> > [ 5093.478049] RBP: 0004 R08:  R09: 
> > 
> > [ 5093.481298] R10: 0003 R11: 0246 R12: 
> > 
> > [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
> > 557e5c9775c0
> > [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel kvm 
> > irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa]
> > [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
> > 
> > Guest kernel: Linux 5.9-rc7
> > gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
> > I tried with QEMU 4.2.1 and the latest master branch: same issue.
> > 
> > 
> > I did some digging, and skipping the gdb 'add-symbol-file' command in 
> > symbol.py
> > avoid the issue, but of course I don't have the symbols loaded:
> > 
> > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
> > index 1be9763cf8bb..eadfaa4d4907 100644
> > --- a/scripts/gdb/linux/symbols.py
> > +++ b/scripts/gdb/linux/symbols.py
> > @@ -129,7 +129,7 @@ lx-symbols command."""
> >  filename=module_file,
> >  addr=module_addr,
> >  sections=self._section_arguments(module))
> > -gdb.execute(cmdline, to_string=True)
> > +#gdb.execute(cmdline, to_string=True)
> >  if module_name not in self.loaded_modules:
> >  self.loaded_modules.append(module_name)
> >  else:
> > 
> > I tried several modules and this happens every time after '(gdb) 
> > lx-symbols'.
> > 
> > Do you have any hints?
> > 
> I assume you are debugging a kernel inside QEMU/KVM, right?

Right!

> Does it work
> without -enable-kvm?

Yes, disabling kvm it works.

> 
> Debugging guests in KVM mode at least was unstable for a long time. I
> avoided setting soft-BPs - which is what the script does for the sake of
> tracking modules loading -, falling back to hw-BPs, as I had no time to
> debug that further. /Maybe/ that's the issue here.

Thanks for the suggestion, I'll try to have a look.

Stefano

Re: [PATCH v7 2/4] curses: Fixes compiler error that complain don't have langinfo.h on msys2/mingw

[Daniel P . Berrangé]

On Sat, Oct 03, 2020 at 02:08:38AM +0800, Yonggang Luo wrote:
> msys2/mingw lacks the POSIX-required langinfo.h.
> 
> gcc test.c -DNCURSES_WIDECHAR -I/mingw64/include/ncursesw -pipe -lncursesw 
> -lgnurx -ltre -lintl -liconv
> test.c:4:10: fatal error: langinfo.h: No such file or directory
> 4 | #include 
>   |  ^~~~
> compilation terminated.
> 
> So we using g_get_codeset instead of nl_langinfo(CODESET)
> 
> Signed-off-by: Yonggang Luo 
> Reviewed-by: Gerd Hoffmann 
> ---
>  configure   |  5 +
>  ui/curses.c | 10 +-
>  2 files changed, 6 insertions(+), 9 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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 v7 0/4] Fixes curses on msys2/mingw

[Daniel P . Berrangé]

Only one of the 4 patches in this series appears to have been sent.

On Sat, Oct 03, 2020 at 02:08:37AM +0800, Yonggang Luo wrote:
> V6-V7
> Update the configure script for
> * curses: Fixes compiler error that complain don't have langinfo.h on msys2/m=
> ingw
> 
> V5-V6
> Dropping configure: Fixes ncursesw detection under msys2/mingw by convert the=
> m to meson first.
> That need the meson 0.56 upstream to fixes the curses detection.
> Add
> * configure: fixes indent of $meson setup
> 
> Yonggang Luo (4):
>   configure: fixes indent of $meson setup
>   curses: Fixes compiler error that complain don't have langinfo.h on
> msys2/mingw
>   curses: Fixes curses compiling errors.
>   win32: Simplify gmtime_r detection not depends on if  _POSIX_C_SOURCE
> are defined on msys2/mingw
> 
>  configure | 47 +--
>  include/sysemu/os-win32.h |  4 ++--
>  ui/curses.c   | 14 ++--
>  util/oslib-win32.c|  4 ++--
>  4 files changed, 16 insertions(+), 53 deletions(-)
> 
> --=20
> 2.28.0.windows.1
> 
> 

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

[PULL 00/19] Build system + MCE patches for 2020-10-05

[Paolo Bonzini]

The following changes since commit 469e72ab7dbbd7ff4ee601e5ea7c29545d46593b:

  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
(2020-10-02 16:19:42 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to d72d6dcb0d633bb08c2dc5a959a47608a1655018:

  dockerfiles: add diffutils to Fedora (2020-10-05 09:14:19 +0200)


* move target configuration to default-configs/targets (myself)
* Memory failure event (Zhenwei)


Paolo Bonzini (16):
  travis: remove TCI test
  default-configs: move files to default-configs/devices/
  configure: convert accelerator variables to meson options
  configure: rewrite accelerator defaults as tests
  configure: move accelerator logic to meson
  configure: remove dead variable
  configure: compute derivatives of target name in meson
  configure: remove useless config-target.mak symbols
  configure: remove target configuration
  default-configs: remove default-configs/devices for user-mode targets
  configure: move OpenBSD W^X test to meson
  default-configs: use TARGET_ARCH key
  default-configs: remove redundant keys
  meson: move sparse detection to Meson and rewrite check_sparse.py
  tests: tcg: do not use implicit rules
  dockerfiles: add diffutils to Fedora

Zhenwei Pi (3):
  target-i386: seperate MCIP & MCE_MASK error reason
  qapi/run-state.json: introduce memory failure event
  target-i386: post memory failure event to QMP

 .travis.yml|   8 -
 configure  | 627 +++--
 default-configs/aarch64-linux-user.mak |   1 -
 default-configs/aarch64_be-linux-user.mak  |   1 -
 default-configs/alpha-linux-user.mak   |   1 -
 default-configs/arm-linux-user.mak |   1 -
 default-configs/armeb-linux-user.mak   |   1 -
 default-configs/cris-linux-user.mak|   1 -
 default-configs/{ => devices}/aarch64-softmmu.mak  |   0
 default-configs/{ => devices}/alpha-softmmu.mak|   0
 default-configs/{ => devices}/arm-softmmu.mak  |   0
 default-configs/{ => devices}/avr-softmmu.mak  |   0
 default-configs/{ => devices}/cris-softmmu.mak |   0
 default-configs/{ => devices}/hppa-softmmu.mak |   0
 default-configs/{ => devices}/i386-softmmu.mak |   0
 default-configs/{ => devices}/lm32-softmmu.mak |   0
 default-configs/{ => devices}/m68k-softmmu.mak |   0
 .../{ => devices}/microblaze-softmmu.mak   |   0
 .../{ => devices}/microblazeel-softmmu.mak |   0
 .../{ => devices}/mips-softmmu-common.mak  |   0
 default-configs/{ => devices}/mips-softmmu.mak |   0
 default-configs/{ => devices}/mips64-softmmu.mak   |   0
 default-configs/{ => devices}/mips64el-softmmu.mak |   0
 default-configs/{ => devices}/mipsel-softmmu.mak   |   0
 default-configs/{ => devices}/moxie-softmmu.mak|   0
 default-configs/{ => devices}/nios2-softmmu.mak|   0
 default-configs/{ => devices}/or1k-softmmu.mak |   0
 default-configs/{ => devices}/ppc-softmmu.mak  |   0
 default-configs/{ => devices}/ppc64-softmmu.mak|   0
 default-configs/{ => devices}/riscv32-softmmu.mak  |   0
 default-configs/{ => devices}/riscv64-softmmu.mak  |   0
 default-configs/{ => devices}/rx-softmmu.mak   |   0
 default-configs/{ => devices}/s390x-softmmu.mak|   0
 default-configs/{ => devices}/sh4-softmmu.mak  |   0
 default-configs/{ => devices}/sh4eb-softmmu.mak|   0
 default-configs/{ => devices}/sparc-softmmu.mak|   0
 default-configs/{ => devices}/sparc64-softmmu.mak  |   0
 default-configs/{ => devices}/tricore-softmmu.mak  |   0
 .../{ => devices}/unicore32-softmmu.mak|   0
 default-configs/{ => devices}/x86_64-softmmu.mak   |   0
 default-configs/{ => devices}/xtensa-softmmu.mak   |   0
 default-configs/{ => devices}/xtensaeb-softmmu.mak |   0
 default-configs/hppa-linux-user.mak|   1 -
 default-configs/i386-bsd-user.mak  |   1 -
 default-configs/i386-linux-user.mak|   1 -
 default-configs/m68k-linux-user.mak|   1 -
 default-configs/microblaze-linux-user.mak  |   1 -
 default-configs/microblazeel-linux-user.mak|   1 -
 default-configs/mips-linux-user.mak|   1 -
 default-configs/mips64-linux-user.mak  |   1 -
 default-configs/mips64el-linux-user.mak|   1 -
 default-configs/mipsel-linux-user.mak  |   1 -
 default-configs/mipsn32-linux-user.mak |   1 -
 default-configs/mipsn32el-linux-user.mak   |   1 -
 default-configs/nios2-linux-user.mak   |   1 -
 default-configs/or1k-linux-user.mak|  

[PULL 02/19] default-configs: move files to default-configs/devices/

[Paolo Bonzini]

Make room for target files in default-configs/targets/

Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure | 6 +++---
 default-configs/{ => devices}/aarch64-linux-user.mak  | 0
 default-configs/{ => devices}/aarch64-softmmu.mak | 0
 default-configs/{ => devices}/aarch64_be-linux-user.mak   | 0
 default-configs/{ => devices}/alpha-linux-user.mak| 0
 default-configs/{ => devices}/alpha-softmmu.mak   | 0
 default-configs/{ => devices}/arm-linux-user.mak  | 0
 default-configs/{ => devices}/arm-softmmu.mak | 0
 default-configs/{ => devices}/armeb-linux-user.mak| 0
 default-configs/{ => devices}/avr-softmmu.mak | 0
 default-configs/{ => devices}/cris-linux-user.mak | 0
 default-configs/{ => devices}/cris-softmmu.mak| 0
 default-configs/{ => devices}/hppa-linux-user.mak | 0
 default-configs/{ => devices}/hppa-softmmu.mak| 0
 default-configs/{ => devices}/i386-bsd-user.mak   | 0
 default-configs/{ => devices}/i386-linux-user.mak | 0
 default-configs/{ => devices}/i386-softmmu.mak| 0
 default-configs/{ => devices}/lm32-softmmu.mak| 0
 default-configs/{ => devices}/m68k-linux-user.mak | 0
 default-configs/{ => devices}/m68k-softmmu.mak| 0
 default-configs/{ => devices}/microblaze-linux-user.mak   | 0
 default-configs/{ => devices}/microblaze-softmmu.mak  | 0
 default-configs/{ => devices}/microblazeel-linux-user.mak | 0
 default-configs/{ => devices}/microblazeel-softmmu.mak| 0
 default-configs/{ => devices}/mips-linux-user.mak | 0
 default-configs/{ => devices}/mips-softmmu-common.mak | 0
 default-configs/{ => devices}/mips-softmmu.mak| 0
 default-configs/{ => devices}/mips64-linux-user.mak   | 0
 default-configs/{ => devices}/mips64-softmmu.mak  | 0
 default-configs/{ => devices}/mips64el-linux-user.mak | 0
 default-configs/{ => devices}/mips64el-softmmu.mak| 0
 default-configs/{ => devices}/mipsel-linux-user.mak   | 0
 default-configs/{ => devices}/mipsel-softmmu.mak  | 0
 default-configs/{ => devices}/mipsn32-linux-user.mak  | 0
 default-configs/{ => devices}/mipsn32el-linux-user.mak| 0
 default-configs/{ => devices}/moxie-softmmu.mak   | 0
 default-configs/{ => devices}/nios2-linux-user.mak| 0
 default-configs/{ => devices}/nios2-softmmu.mak   | 0
 default-configs/{ => devices}/or1k-linux-user.mak | 0
 default-configs/{ => devices}/or1k-softmmu.mak| 0
 default-configs/{ => devices}/ppc-linux-user.mak  | 0
 default-configs/{ => devices}/ppc-softmmu.mak | 0
 default-configs/{ => devices}/ppc64-linux-user.mak| 0
 default-configs/{ => devices}/ppc64-softmmu.mak   | 0
 default-configs/{ => devices}/ppc64abi32-linux-user.mak   | 0
 default-configs/{ => devices}/ppc64le-linux-user.mak  | 0
 default-configs/{ => devices}/riscv32-linux-user.mak  | 0
 default-configs/{ => devices}/riscv32-softmmu.mak | 0
 default-configs/{ => devices}/riscv64-linux-user.mak  | 0
 default-configs/{ => devices}/riscv64-softmmu.mak | 0
 default-configs/{ => devices}/rx-softmmu.mak  | 0
 default-configs/{ => devices}/s390x-linux-user.mak| 0
 default-configs/{ => devices}/s390x-softmmu.mak   | 0
 default-configs/{ => devices}/sh4-linux-user.mak  | 0
 default-configs/{ => devices}/sh4-softmmu.mak | 0
 default-configs/{ => devices}/sh4eb-linux-user.mak| 0
 default-configs/{ => devices}/sh4eb-softmmu.mak   | 0
 default-configs/{ => devices}/sparc-bsd-user.mak  | 0
 default-configs/{ => devices}/sparc-linux-user.mak| 0
 default-configs/{ => devices}/sparc-softmmu.mak   | 0
 default-configs/{ => devices}/sparc32plus-linux-user.mak  | 0
 default-configs/{ => devices}/sparc64-bsd-user.mak| 0
 default-configs/{ => devices}/sparc64-linux-user.mak  | 0
 default-configs/{ => devices}/sparc64-softmmu.mak | 0
 default-configs/{ => devices}/tilegx-linux-user.mak   | 0
 default-configs/{ => devices}/tricore-softmmu.mak | 0
 default-configs/{ => devices}/unicore32-softmmu.mak   | 0
 default-configs/{ => devices}/x86_64-bsd-user.mak | 0
 default-configs/{ => devices}/x86_64-linux-user.mak   | 0
 default-configs/{ => devices}/x86_64-softmmu.mak  | 0
 default-configs/{ => devices}/xtensa-linux-user.mak   | 0
 default-configs/{ => devices}/xtensa-softmmu.mak  | 0
 default-configs/{ => devices}/xtensaeb-linux-user.mak | 0
 default-configs/{ => devices}/xtensaeb-softmmu.mak| 0
 meson.build   | 2 +-
 75 files changed, 4 insertions(+), 4 deletions(-)
 rename default-configs/{ => devices}/aarch64-linux-user.mak (100%)
 rename default-configs

[PULL 08/19] configure: remove useless config-target.mak symbols

[Paolo Bonzini]

Omit symbols that are not needed by softmmu or bsd-user targets,
in preparation for moving the generated config-target.mak files
into the source tree.

Signed-off-by: Paolo Bonzini 
---
 configure | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 7058ac10e9..a8e314dd53 100755
--- a/configure
+++ b/configure
@@ -7471,7 +7471,7 @@ case "$target_name" in
   mips|mipsel)
 mttcg="yes"
 TARGET_ARCH=mips
-echo "TARGET_ABI_MIPSO32=y" >> $config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI_MIPSO32=y" >> 
$config_target_mak
 TARGET_SYSTBL_ABI=o32
 TARGET_SYSTBL=syscall_o32.tbl
   ;;
@@ -7479,8 +7479,8 @@ case "$target_name" in
 mttcg="yes"
 TARGET_ARCH=mips64
 TARGET_BASE_ARCH=mips
-echo "TARGET_ABI_MIPSN32=y" >> $config_target_mak
-echo "TARGET_ABI32=y" >> $config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI_MIPSN32=y" >> 
$config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI32=y" >> 
$config_target_mak
 TARGET_SYSTBL_ABI=n32
 TARGET_SYSTBL=syscall_n32.tbl
   ;;
@@ -7488,7 +7488,7 @@ case "$target_name" in
 mttcg="no"
 TARGET_ARCH=mips64
 TARGET_BASE_ARCH=mips
-echo "TARGET_ABI_MIPSN64=y" >> $config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI_MIPSN64=y" >> 
$config_target_mak
 TARGET_SYSTBL_ABI=n64
 TARGET_SYSTBL=syscall_n64.tbl
   ;;
@@ -7524,7 +7524,7 @@ case "$target_name" in
 TARGET_BASE_ARCH=ppc
 TARGET_ABI_DIR=ppc
 TARGET_SYSTBL_ABI=common,nospu,32
-echo "TARGET_ABI32=y" >> $config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI32=y" >> 
$config_target_mak
 gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml power-vsx.xml"
   ;;
   riscv32)
@@ -7562,7 +7562,7 @@ case "$target_name" in
 TARGET_BASE_ARCH=sparc
 TARGET_ABI_DIR=sparc
 TARGET_SYSTBL_ABI=common,32
-echo "TARGET_ABI32=y" >> $config_target_mak
+test "$target_user_only" = yes && echo "TARGET_ABI32=y" >> 
$config_target_mak
   ;;
   s390x)
 TARGET_SYSTBL_ABI=common,64
@@ -7600,15 +7600,18 @@ upper() {
 target_arch_name="$(upper $TARGET_ARCH)"
 echo "TARGET_$target_arch_name=y" >> $config_target_mak
 echo "TARGET_BASE_ARCH=$TARGET_BASE_ARCH" >> $config_target_mak
-if [ "$TARGET_ABI_DIR" = "" ]; then
-  TARGET_ABI_DIR=$TARGET_ARCH
+if test "$target_user_only" = "yes" ; then
+  if [ "$TARGET_ABI_DIR" = "" ]; then
+TARGET_ABI_DIR=$TARGET_ARCH
+  fi
+  echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak
 fi
-echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak
-if [ "$TARGET_SYSTBL_ABI" != "" ]; then
+if test "$target_linux_user" = "yes" ; then
+  if [ "$TARGET_SYSTBL_ABI" != "" ]; then
 echo "TARGET_SYSTBL_ABI=$TARGET_SYSTBL_ABI" >> $config_target_mak
 echo "TARGET_SYSTBL=$TARGET_SYSTBL" >> $config_target_mak
+  fi
 fi
-
 if test "$target_aligned_only" = "yes" ; then
   echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
 fi
-- 
2.26.2

[PULL 13/19] default-configs: remove redundant keys

[Paolo Bonzini]

TARGET_BASE_ARCH and TARGET_ABI_DIR are 99% of the time the same
as TARGET_ARCH, remove them if so.

Signed-off-by: Paolo Bonzini 
---
 default-configs/targets/aarch64-linux-user.mak  | 1 -
 default-configs/targets/aarch64_be-linux-user.mak   | 1 -
 default-configs/targets/alpha-linux-user.mak| 2 --
 default-configs/targets/alpha-softmmu.mak   | 1 -
 default-configs/targets/arm-linux-user.mak  | 2 --
 default-configs/targets/arm-softmmu.mak | 1 -
 default-configs/targets/armeb-linux-user.mak| 2 --
 default-configs/targets/avr-softmmu.mak | 1 -
 default-configs/targets/cris-linux-user.mak | 2 --
 default-configs/targets/cris-softmmu.mak| 1 -
 default-configs/targets/hppa-linux-user.mak | 2 --
 default-configs/targets/hppa-softmmu.mak| 1 -
 default-configs/targets/i386-bsd-user.mak   | 2 --
 default-configs/targets/i386-linux-user.mak | 2 --
 default-configs/targets/i386-softmmu.mak| 1 -
 default-configs/targets/lm32-softmmu.mak| 1 -
 default-configs/targets/m68k-linux-user.mak | 2 --
 default-configs/targets/m68k-softmmu.mak| 1 -
 default-configs/targets/microblaze-linux-user.mak   | 2 --
 default-configs/targets/microblaze-softmmu.mak  | 1 -
 default-configs/targets/microblazeel-linux-user.mak | 2 --
 default-configs/targets/microblazeel-softmmu.mak| 1 -
 default-configs/targets/mips-linux-user.mak | 2 --
 default-configs/targets/mips-softmmu.mak| 1 -
 default-configs/targets/mips64-linux-user.mak   | 1 -
 default-configs/targets/mips64el-linux-user.mak | 1 -
 default-configs/targets/mipsel-linux-user.mak   | 2 --
 default-configs/targets/mipsel-softmmu.mak  | 1 -
 default-configs/targets/mipsn32-linux-user.mak  | 1 -
 default-configs/targets/mipsn32el-linux-user.mak| 1 -
 default-configs/targets/moxie-softmmu.mak   | 1 -
 default-configs/targets/nios2-linux-user.mak| 2 --
 default-configs/targets/nios2-softmmu.mak   | 1 -
 default-configs/targets/or1k-linux-user.mak | 2 --
 default-configs/targets/or1k-softmmu.mak| 1 -
 default-configs/targets/ppc-linux-user.mak  | 2 --
 default-configs/targets/ppc-softmmu.mak | 1 -
 default-configs/targets/rx-softmmu.mak  | 1 -
 default-configs/targets/s390x-linux-user.mak| 2 --
 default-configs/targets/s390x-softmmu.mak   | 1 -
 default-configs/targets/sh4-linux-user.mak  | 2 --
 default-configs/targets/sh4-softmmu.mak | 1 -
 default-configs/targets/sh4eb-linux-user.mak| 2 --
 default-configs/targets/sh4eb-softmmu.mak   | 1 -
 default-configs/targets/sparc-bsd-user.mak  | 2 --
 default-configs/targets/sparc-linux-user.mak| 2 --
 default-configs/targets/sparc-softmmu.mak   | 1 -
 default-configs/targets/sparc64-bsd-user.mak| 1 -
 default-configs/targets/sparc64-linux-user.mak  | 1 -
 default-configs/targets/tilegx-linux-user.mak   | 2 --
 default-configs/targets/tricore-softmmu.mak | 1 -
 default-configs/targets/unicore32-softmmu.mak   | 1 -
 default-configs/targets/x86_64-bsd-user.mak | 1 -
 default-configs/targets/x86_64-linux-user.mak   | 1 -
 default-configs/targets/xtensa-linux-user.mak   | 2 --
 default-configs/targets/xtensa-softmmu.mak  | 1 -
 default-configs/targets/xtensaeb-linux-user.mak | 2 --
 default-configs/targets/xtensaeb-softmmu.mak| 1 -
 meson.build | 8 
 59 files changed, 8 insertions(+), 81 deletions(-)

diff --git a/default-configs/targets/aarch64-linux-user.mak 
b/default-configs/targets/aarch64-linux-user.mak
index d6c4a35c39..163c9209f4 100644
--- a/default-configs/targets/aarch64-linux-user.mak
+++ b/default-configs/targets/aarch64-linux-user.mak
@@ -1,5 +1,4 @@
 TARGET_ARCH=aarch64
 TARGET_BASE_ARCH=arm
-TARGET_ABI_DIR=aarch64
 TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml 
gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml gdb-xml/arm-vfp3.xml 
gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
 TARGET_HAS_BFLT=y
diff --git a/default-configs/targets/aarch64_be-linux-user.mak 
b/default-configs/targets/aarch64_be-linux-user.mak
index 5e2d615c11..4c953cf8c5 100644
--- a/default-configs/targets/aarch64_be-linux-user.mak
+++ b/default-configs/targets/aarch64_be-linux-user.mak
@@ -1,6 +1,5 @@
 TARGET_ARCH=aarch64
 TARGET_BASE_ARCH=arm
-TARGET_ABI_DIR=aarch64
 TARGET_WORDS_BIGENDIAN=y
 TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml 
gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml gdb-xml/arm-vfp3.xml 
gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
 TARGET_HAS_BFLT=y
diff --git a/default-configs/targets/alpha-linux-user.mak 
b/default-configs/targets/alpha-linux-user.mak
index e21f7cdefd..7e62fd796a 100644
--- a/default-configs/targets/alpha-linux-user.mak
+++

[PULL 10/19] default-configs: remove default-configs/devices for user-mode targets

[Paolo Bonzini]

We no longer need dummy files to detect targets, since
default-configs/targets/ exists.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure   | 6 +++---
 default-configs/devices/aarch64-linux-user.mak  | 1 -
 default-configs/devices/aarch64_be-linux-user.mak   | 1 -
 default-configs/devices/alpha-linux-user.mak| 1 -
 default-configs/devices/arm-linux-user.mak  | 1 -
 default-configs/devices/armeb-linux-user.mak| 1 -
 default-configs/devices/cris-linux-user.mak | 1 -
 default-configs/devices/hppa-linux-user.mak | 1 -
 default-configs/devices/i386-bsd-user.mak   | 1 -
 default-configs/devices/i386-linux-user.mak | 1 -
 default-configs/devices/m68k-linux-user.mak | 1 -
 default-configs/devices/microblaze-linux-user.mak   | 1 -
 default-configs/devices/microblazeel-linux-user.mak | 1 -
 default-configs/devices/mips-linux-user.mak | 1 -
 default-configs/devices/mips64-linux-user.mak   | 1 -
 default-configs/devices/mips64el-linux-user.mak | 1 -
 default-configs/devices/mipsel-linux-user.mak   | 1 -
 default-configs/devices/mipsn32-linux-user.mak  | 1 -
 default-configs/devices/mipsn32el-linux-user.mak| 1 -
 default-configs/devices/nios2-linux-user.mak| 1 -
 default-configs/devices/or1k-linux-user.mak | 1 -
 default-configs/devices/ppc-linux-user.mak  | 1 -
 default-configs/devices/ppc64-linux-user.mak| 1 -
 default-configs/devices/ppc64abi32-linux-user.mak   | 1 -
 default-configs/devices/ppc64le-linux-user.mak  | 1 -
 default-configs/devices/riscv32-linux-user.mak  | 1 -
 default-configs/devices/riscv64-linux-user.mak  | 1 -
 default-configs/devices/s390x-linux-user.mak| 1 -
 default-configs/devices/sh4-linux-user.mak  | 1 -
 default-configs/devices/sh4eb-linux-user.mak| 1 -
 default-configs/devices/sparc-bsd-user.mak  | 1 -
 default-configs/devices/sparc-linux-user.mak| 1 -
 default-configs/devices/sparc32plus-linux-user.mak  | 1 -
 default-configs/devices/sparc64-bsd-user.mak| 1 -
 default-configs/devices/sparc64-linux-user.mak  | 1 -
 default-configs/devices/tilegx-linux-user.mak   | 1 -
 default-configs/devices/x86_64-bsd-user.mak | 1 -
 default-configs/devices/x86_64-linux-user.mak   | 1 -
 default-configs/devices/xtensa-linux-user.mak   | 1 -
 default-configs/devices/xtensaeb-linux-user.mak | 1 -
 40 files changed, 3 insertions(+), 42 deletions(-)
 delete mode 100644 default-configs/devices/aarch64-linux-user.mak
 delete mode 100644 default-configs/devices/aarch64_be-linux-user.mak
 delete mode 100644 default-configs/devices/alpha-linux-user.mak
 delete mode 100644 default-configs/devices/arm-linux-user.mak
 delete mode 100644 default-configs/devices/armeb-linux-user.mak
 delete mode 100644 default-configs/devices/cris-linux-user.mak
 delete mode 100644 default-configs/devices/hppa-linux-user.mak
 delete mode 100644 default-configs/devices/i386-bsd-user.mak
 delete mode 100644 default-configs/devices/i386-linux-user.mak
 delete mode 100644 default-configs/devices/m68k-linux-user.mak
 delete mode 100644 default-configs/devices/microblaze-linux-user.mak
 delete mode 100644 default-configs/devices/microblazeel-linux-user.mak
 delete mode 100644 default-configs/devices/mips-linux-user.mak
 delete mode 100644 default-configs/devices/mips64-linux-user.mak
 delete mode 100644 default-configs/devices/mips64el-linux-user.mak
 delete mode 100644 default-configs/devices/mipsel-linux-user.mak
 delete mode 100644 default-configs/devices/mipsn32-linux-user.mak
 delete mode 100644 default-configs/devices/mipsn32el-linux-user.mak
 delete mode 100644 default-configs/devices/nios2-linux-user.mak
 delete mode 100644 default-configs/devices/or1k-linux-user.mak
 delete mode 100644 default-configs/devices/ppc-linux-user.mak
 delete mode 100644 default-configs/devices/ppc64-linux-user.mak
 delete mode 100644 default-configs/devices/ppc64abi32-linux-user.mak
 delete mode 100644 default-configs/devices/ppc64le-linux-user.mak
 delete mode 100644 default-configs/devices/riscv32-linux-user.mak
 delete mode 100644 default-configs/devices/riscv64-linux-user.mak
 delete mode 100644 default-configs/devices/s390x-linux-user.mak
 delete mode 100644 default-configs/devices/sh4-linux-user.mak
 delete mode 100644 default-configs/devices/sh4eb-linux-user.mak
 delete mode 100644 default-configs/devices/sparc-bsd-user.mak
 delete mode 100644 default-configs/devices/sparc-linux-user.mak
 delete mode 100644 default-configs/devices/sparc32plus-linux-user.mak
 delete mode 100644 default-configs/devices/sparc64-bsd-user.mak
 delete mode 100644 default-configs/devices/sparc64-linux-user.mak
 delete mode 100644 default-configs/devices/tilegx-linux-user.mak
 delete mode 100644 default-configs/devices/x86_64-bsd-user.mak
 delete mode 100644 defau

[PULL 07/19] configure: compute derivatives of target name in meson

[Paolo Bonzini]

Several CONFIG_* symbols in config-target.mak are easily computed from just
the target name.  We do not need them in config-target.mak, and can instead
place them in the config_target dictionary only.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure   | 11 +--
 meson.build | 27 ---
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/configure b/configure
index 2133239593..7058ac10e9 100755
--- a/configure
+++ b/configure
@@ -7599,7 +7599,6 @@ upper() {
 
 target_arch_name="$(upper $TARGET_ARCH)"
 echo "TARGET_$target_arch_name=y" >> $config_target_mak
-echo "TARGET_NAME=$target_name" >> $config_target_mak
 echo "TARGET_BASE_ARCH=$TARGET_BASE_ARCH" >> $config_target_mak
 if [ "$TARGET_ABI_DIR" = "" ]; then
   TARGET_ABI_DIR=$TARGET_ARCH
@@ -7617,21 +7616,15 @@ if test "$target_bigendian" = "yes" ; then
   echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
 fi
 if test "$target_softmmu" = "yes" ; then
-  echo "CONFIG_SOFTMMU=y" >> $config_target_mak
   if test "$mttcg" = "yes" ; then
 echo "TARGET_SUPPORTS_MTTCG=y" >> $config_target_mak
   fi
 fi
 if test "$target_user_only" = "yes" ; then
-  echo "CONFIG_USER_ONLY=y" >> $config_target_mak
-  echo "CONFIG_QEMU_INTERP_PREFIX=\"$interp_prefix1\"" >> $config_target_mak
   symlink "../qemu-$target_name" "$target_dir/qemu-$target_name"
 else
   symlink "../qemu-system-$target_name" "$target_dir/qemu-system-$target_name"
 fi
-if test "$target_linux_user" = "yes" ; then
-  echo "CONFIG_LINUX_USER=y" >> $config_target_mak
-fi
 list=""
 if test ! -z "$gdb_xml_files" ; then
   for x in $gdb_xml_files; do
@@ -7643,9 +7636,6 @@ fi
 if test "$target_user_only" = "yes" && test "$bflt" = "yes"; then
   echo "TARGET_HAS_BFLT=y" >> $config_target_mak
 fi
-if test "$target_bsd_user" = "yes" ; then
-  echo "CONFIG_BSD_USER=y" >> $config_target_mak
-fi
 
 done # for target in $targets
 
@@ -7655,6 +7645,7 @@ fi
 if [ "$capstone" = "git" -o "$capstone" = "internal" ]; then
   subdirs="$subdirs capstone"
 fi
+echo "CONFIG_QEMU_INTERP_PREFIX=$interp_prefix" | sed 's/%M/@0@/' >> 
$config_host_mak
 echo "SUBDIRS=$subdirs" >> $config_host_mak
 if test -n "$LIBCAPSTONE"; then
   echo "LIBCAPSTONE=$LIBCAPSTONE" >> $config_host_mak
diff --git a/meson.build b/meson.build
index 43ce1272b9..4de1524941 100644
--- a/meson.build
+++ b/meson.build
@@ -639,12 +639,15 @@ config_host_data.set('QEMU_VERSION_MAJOR', 
meson.project_version().split('.')[0]
 config_host_data.set('QEMU_VERSION_MINOR', 
meson.project_version().split('.')[1])
 config_host_data.set('QEMU_VERSION_MICRO', 
meson.project_version().split('.')[2])
 
+ignored = ['CONFIG_QEMU_INTERP_PREFIX'] # actually per-target
 arrays = ['CONFIG_AUDIO_DRIVERS', 'CONFIG_BDRV_RW_WHITELIST', 
'CONFIG_BDRV_RO_WHITELIST']
 strings = ['HOST_DSOSUF', 'CONFIG_IASL', 'bindir', 'prefix', 'qemu_confdir', 
'qemu_datadir',
'qemu_moddir', 'qemu_localstatedir', 'qemu_helperdir', 
'qemu_localedir',
'qemu_icondir', 'qemu_desktopdir', 'qemu_firmwarepath', 
'sysconfdir']
 foreach k, v: config_host
-  if arrays.contains(k)
+  if ignored.contains(k)
+# do nothing
+  elif arrays.contains(k)
 if v != ''
   v = '"' + '", "'.join(v.split()) + '", '
 endif
@@ -721,7 +724,23 @@ kconfig_external_symbols = [
 ignored = ['TARGET_XML_FILES', 'TARGET_ABI_DIR', 'TARGET_DIRS']
 
 foreach target : target_dirs
-  config_target = keyval.load(meson.current_build_dir() / target / 
'config-target.mak')
+  config_target = { 'TARGET_NAME': target.split('-')[0] }
+  if target.endswith('linux-user')
+assert(targetos == 'linux')
+config_target += { 'CONFIG_LINUX_USER': 'y' }
+  elif target.endswith('bsd-user')
+assert('CONFIG_BSD' in config_host)
+config_target += { 'CONFIG_BSD_USER': 'y' }
+  elif target.endswith('softmmu')
+config_target += { 'CONFIG_SOFTMMU': 'y' }
+  endif
+  if target.endswith('-user')
+config_target += {
+  'CONFIG_USER_ONLY': 'y',
+  'CONFIG_QEMU_INTERP_PREFIX':
+
config_host['CONFIG_QEMU_INTERP_PREFIX'].format(config_target['TARGET_NAME'])
+}
+  endif
 
   have_accel = false
   foreach sym: accelerators
@@ -736,6 +755,8 @@ foreach target : target_dirs
   endforeach
   assert(have_accel)
 
+  config_target += keyval.load('default-configs/targets' / target + '.mak')
+
   foreach k, v: disassemblers
 if config_host['ARCH'].startswith(k) or 
config_target['TARGET_BASE_ARCH'].startswith(k)
   foreach sym: v
@@ -753,7 +774,7 @@ foreach target : target_dirs
   # do nothing
 elif k == 'TARGET_BASE_ARCH'
   config_target_data.set('TARGET_' + v.to_upper(), 1)
-elif k == 'TARGET_NAME'
+elif k == 'TARGET_NAME' or k == 'CONFIG_QEMU_INTERP_PREFIX'
   config_target_data.set_quoted(k, v)
 elif v == 'y'
   config_target_data.set(k, 1)
-- 
2.26.2

[PULL 01/19] travis: remove TCI test

[Paolo Bonzini]

TCI is already covered on gitlab CI, so we can remove it.

Cc: Thomas Huth 
Cc: Alex Bennée 
Signed-off-by: Paolo Bonzini 
---
 .travis.yml | 8 
 1 file changed, 8 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 519e62432d..1054ec5d29 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -226,14 +226,6 @@ jobs:
 - TEST_CMD=""
 
 
-# Check the TCG interpreter (TCI)
-- name: "GCC TCI"
-  env:
-- CONFIG="--enable-debug-tcg --enable-tcg-interpreter --disable-kvm 
--disable-containers
-
--target-list=alpha-softmmu,arm-softmmu,hppa-softmmu,m68k-softmmu,microblaze-softmmu,moxie-softmmu,ppc-softmmu,s390x-softmmu,x86_64-softmmu"
-- TEST_CMD="make check-qtest check-tcg V=1"
-
-
 # We don't need to exercise every backend with every front-end
 - name: "GCC trace log,simple,syslog (user)"
   env:
-- 
2.26.2

[PULL 16/19] qapi/run-state.json: introduce memory failure event

[Paolo Bonzini]

From: zhenwei pi 

Introduce memory failure events for hypervisor and guest. This lets
mft: Need exactly one file argument.  Try `mft --help' for more
information.

Suggested by Peter Maydell, rename events name&description to make
them architecture-neutral; and suggested by Paolo, add more info to
distinguish a mce is AR/AO, and if a previous MCE was still being
processed in the guest.

Signed-off-by: zhenwei pi 
Message-Id: <20200930100440.1060708-3-pizhen...@bytedance.com>
Signed-off-by: Paolo Bonzini 
---
 qapi/run-state.json | 90 +
 1 file changed, 90 insertions(+)

diff --git a/qapi/run-state.json b/qapi/run-state.json
index 7cc9f96a5b..964c8ef391 100644
--- a/qapi/run-state.json
+++ b/qapi/run-state.json
@@ -475,3 +475,93 @@
'psw-mask': 'uint64',
'psw-addr': 'uint64',
'reason': 'S390CrashReason' } }
+
+##
+# @MEMORY_FAILURE:
+#
+# Emitted when a memory failure occurs on host side.
+#
+# @recipient: recipient is defined as @MemoryFailureRecipient.
+#
+# @action: action that has been taken. action is defined as 
@MemoryFailureAction.
+#
+# @flags: flags for MemoryFailureAction. action is defined as 
@MemoryFailureFlags.
+#
+# Since: 5.2
+#
+# Example:
+#
+# <- { "event": "MEMORY_FAILURE",
+#  "data": { "recipient": "hypervisor",
+#"action": "fatal",
+#"flags": { 'action-required': false } }
+#
+##
+{ 'event': 'MEMORY_FAILURE',
+  'data': { 'recipient': 'MemoryFailureRecipient',
+'action': 'MemoryFailureAction',
+'flags': 'MemoryFailureFlags'} }
+
+##
+# @MemoryFailureRecipient:
+#
+# Hardware memory failure occurs, handled by recipient.
+#
+# @hypervisor: memory failure at QEMU process address space.
+#  (none guest memory, but used by QEMU itself).
+#
+# @guest: memory failure at guest memory,
+#
+# Since: 5.2
+#
+##
+{ 'enum': 'MemoryFailureRecipient',
+  'data': [ 'hypervisor',
+'guest' ] }
+
+
+##
+# @MemoryFailureAction:
+#
+# Actions taken by QEMU in response to a hardware memory failure.
+#
+# @ignore: the memory failure could be ignored.  This will only be the case
+#  for action-optional failures.
+#
+# @inject: memory failure occurred in guest memory, the guest enabled MCE
+#  handling mechanism, and QEMU could inject the MCE into the guest
+#  successfully.
+#
+# @fatal: the failure is unrecoverable.  This occurs for action-required
+# failures if the recipient is the hypervisor; QEMU will exit.
+#
+# @reset: the failure is unrecoverable but confined to the guest.  This
+# occurs if the recipient is a guest guest which is not ready
+# to handle memory failures.
+#
+# Since: 5.2
+#
+##
+{ 'enum': 'MemoryFailureAction',
+  'data': [ 'ignore',
+'inject',
+'fatal',
+'reset' ] }
+
+##
+# @MemoryFailureFlags:
+#
+# Additional information on memory failures.
+#
+# @action-required: whether a memory failure event is action-required
+#   or action-optional (e.g. a failure during memory scrub).
+#
+# @recursive: whether the failure occurred while the previous
+# failure was still in progress.
+#
+# Since: 5.2
+#
+##
+{ 'struct': 'MemoryFailureFlags',
+  'data': { 'action-required': 'bool',
+'recursive': 'bool'} }
-- 
2.26.2

[PULL 04/19] configure: rewrite accelerator defaults as tests

[Paolo Bonzini]

Prepare to process "auto" in meson rather than configure: standardize the
shape of the code that changes "auto" to enabled/disabled, to ease the review
when it will be moved to meson.

Signed-off-by: Paolo Bonzini 
---
 configure | 58 ---
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/configure b/configure
index 5cbfab9968..9dec87e186 100755
--- a/configure
+++ b/configure
@@ -428,10 +428,10 @@ vhost_scsi=""
 vhost_vsock=""
 vhost_user=""
 vhost_user_fs=""
-kvm="disabled"
-hax="disabled"
-hvf="disabled"
-whpx="disabled"
+kvm="auto"
+hax="auto"
+hvf="auto"
+whpx="auto"
 rdma=""
 pvrdma=""
 gprof="no"
@@ -817,8 +817,6 @@ HOST_VARIANT_DIR=""
 case $targetos in
 MINGW32*)
   mingw32="yes"
-  hax="enabled"
-  whpx="auto"
   vhost_user="no"
   audio_possible_drivers="dsound sdl"
   if check_include dsound.h; then
@@ -852,7 +850,6 @@ DragonFly)
 ;;
 NetBSD)
   bsd="yes"
-  hax="enabled"
   make="${MAKE-gmake}"
   audio_drv_list="oss try-sdl"
   audio_possible_drivers="oss sdl"
@@ -869,8 +866,6 @@ OpenBSD)
 Darwin)
   bsd="yes"
   darwin="yes"
-  hax="enabled"
-  hvf="auto"
   if [ "$cpu" = "x86_64" ] ; then
 QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS"
 QEMU_LDFLAGS="-arch x86_64 $QEMU_LDFLAGS"
@@ -906,7 +901,6 @@ Linux)
   audio_possible_drivers="oss alsa sdl pa"
   linux="yes"
   linux_user="yes"
-  kvm="enabled"
   QEMU_INCLUDES="-isystem ${source_path}/linux-headers -Ilinux-headers 
$QEMU_INCLUDES"
 ;;
 esac
@@ -2665,6 +2659,29 @@ if test "$seccomp" != "no" ; then
 seccomp="no"
 fi
 fi
+
+##
+# simple accelerator probes
+
+if test "$kvm" != "disabled" ; then
+  if test "$linux" = yes ; then
+kvm=enabled
+  else
+if test "$kvm" = "enabled" ; then
+  feature_not_found "kvm" "KVM is only available on Linux"
+fi
+kvm=disabled
+  fi
+fi
+
+if test "$hax" = "auto" ; then
+  if test "$mingw" = yes || test "$darwin" = yes || test "$targetos" = NetBSD; 
then
+hax=enabled
+  else
+hax=disabled
+  fi
+fi
+
 ##
 # xen probe
 
@@ -2985,14 +3002,15 @@ fi
 
 ##
 # Windows Hypervisor Platform accelerator (WHPX) check
-if test "$whpx" = "enabled" && test "$ARCH" != "x86_64"; then
-  error_exit "WHPX requires 64-bit host"
-fi
-if test "$whpx" != "disabled" && test "$ARCH" = "x86_64"; then
-if check_include "WinHvPlatform.h" && check_include "WinHvEmulation.h"; 
then
-whpx="yes"
+if test "$whpx" != "disabled"; then
+if test "$mingw32" = yes && test "$ARCH" = "x86_64" &&
+check_include "WinHvPlatform.h" && check_include 
"WinHvEmulation.h"; then
+whpx="enabled"
 else
-if test "$whpx" = "auto"; then
+if test "$whpx" = "enabled"; then
+if test "$ARCH" != "x86_64"; then
+error_exit "WHPX requires 64-bit host"
+fi
 feature_not_found "WinHvPlatform" "WinHvEmulation is not installed"
 fi
 whpx="disabled"
@@ -5828,13 +5846,13 @@ if [ "$hvf" != "disabled" ] ; then
 #include 
 int main() { return 0;}
 EOF
-  if ! compile_object ""; then
+  if test "$darwin" = yes && compile_object ""; then
+hvf='enabled'
+  else
 if test "$hvf" = "enabled"; then
error_exit "Hypervisor.framework not available"
 fi
 hvf='disabled'
-  else
-hvf='enabled'
   fi
 fi
 
-- 
2.26.2

[PULL 11/19] configure: move OpenBSD W^X test to meson

[Paolo Bonzini]

The TCG option is now passed through to Meson.

Signed-off-by: Paolo Bonzini 
---
 configure   | 15 ---
 meson.build |  8 +++-
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/configure b/configure
index a32c43a905..b31bf24d60 100755
--- a/configure
+++ b/configure
@@ -1594,10 +1594,6 @@ if [ "$ARCH" = "unknown" ]; then
   linux_user="no"
 fi
 
-if [ "$bsd_user" = "no" -a "$linux_user" = "no" -a "$softmmu" = "no" ] ; then
-  tcg="disabled"
-fi
-
 default_target_list=""
 
deprecated_targets_list=ppc64abi32-linux-user,tilegx-linux-user,lm32-softmmu,unicore32-softmmu
 deprecated_features=""
@@ -6041,17 +6037,6 @@ if test "$mingw32" = "yes" ; then
 done
 fi
 
-# Disable OpenBSD W^X if available
-if test "$tcg" = "enabled" && test "$targetos" = "OpenBSD"; then
-cat > $TMPC < 0
+# Disable OpenBSD W^X if available
+emulator_link_args = cc.get_supported_link_arguments('-Wl,-z,wxneeded')
+  endif
 endif
 
 accelerators = []
@@ -1247,7 +1253,7 @@ foreach target : target_dirs
   c_args = ['-DNEED_CPU_H',
 '-DCONFIG_TARGET="@0@-config-target.h"'.format(target),
 '-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target)]
-  link_args = []
+  link_args = emulator_link_args
 
   config_target += config_host
   target_inc = [include_directories('target' / 
config_target['TARGET_BASE_ARCH'])]
-- 
2.26.2

[PULL 03/19] configure: convert accelerator variables to meson options

[Paolo Bonzini]

Prepare for moving the tests to meson.  For now they only have
enabled/disabled as the possible values when meson is invoked,
but "auto" will be a possibility later, when configure will only
parse the command line options.

Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure | 132 +++---
 meson_options.txt |  15 ++
 tests/meson.build |   2 +-
 3 files changed, 83 insertions(+), 66 deletions(-)

diff --git a/configure b/configure
index 1981f58aa9..5cbfab9968 100755
--- a/configure
+++ b/configure
@@ -220,7 +220,7 @@ glob() {
 }
 
 supported_hax_target() {
-test "$hax" = "yes" || return 1
+test "$hax" = "enabled" || return 1
 glob "$1" "*-softmmu" || return 1
 case "${1%-softmmu}" in
 i386|x86_64)
@@ -231,7 +231,7 @@ supported_hax_target() {
 }
 
 supported_kvm_target() {
-test "$kvm" = "yes" || return 1
+test "$kvm" = "enabled" || return 1
 glob "$1" "*-softmmu" || return 1
 case "${1%-softmmu}:$cpu" in
 aarch64:aarch64 | \
@@ -247,7 +247,7 @@ supported_kvm_target() {
 }
 
 supported_xen_target() {
-test "$xen" = "yes" || return 1
+test "$xen" = "enabled" || return 1
 glob "$1" "*-softmmu" || return 1
 # Only i386 and x86_64 provide the xenpv machine.
 case "${1%-softmmu}" in
@@ -259,7 +259,7 @@ supported_xen_target() {
 }
 
 supported_hvf_target() {
-test "$hvf" = "yes" || return 1
+test "$hvf" = "enabled" || return 1
 glob "$1" "*-softmmu" || return 1
 case "${1%-softmmu}" in
 x86_64)
@@ -270,7 +270,7 @@ supported_hvf_target() {
 }
 
 supported_whpx_target() {
-test "$whpx" = "yes" || return 1
+test "$whpx" = "enabled" || return 1
 glob "$1" "*-softmmu" || return 1
 case "${1%-softmmu}" in
 i386|x86_64)
@@ -310,7 +310,7 @@ supported_target() {
 add_to deprecated_features $1
 fi
 
-test "$tcg" = "yes" && return 0
+test "$tcg" = "enabled" && return 0
 supported_kvm_target "$1" && return 0
 supported_xen_target "$1" && return 0
 supported_hax_target "$1" && return 0
@@ -413,14 +413,14 @@ vnc_png="auto"
 xkbcommon="auto"
 xen=""
 xen_ctrl_version=""
-xen_pci_passthrough=""
+xen_pci_passthrough="auto"
 linux_aio=""
 linux_io_uring=""
 cap_ng=""
 attr=""
 libattr=""
 xfs=""
-tcg="yes"
+tcg="enabled"
 membarrier=""
 vhost_net=""
 vhost_crypto=""
@@ -428,10 +428,10 @@ vhost_scsi=""
 vhost_vsock=""
 vhost_user=""
 vhost_user_fs=""
-kvm="no"
-hax="no"
-hvf="no"
-whpx="no"
+kvm="disabled"
+hax="disabled"
+hvf="disabled"
+whpx="disabled"
 rdma=""
 pvrdma=""
 gprof="no"
@@ -817,8 +817,8 @@ HOST_VARIANT_DIR=""
 case $targetos in
 MINGW32*)
   mingw32="yes"
-  hax="yes"
-  whpx=""
+  hax="enabled"
+  whpx="auto"
   vhost_user="no"
   audio_possible_drivers="dsound sdl"
   if check_include dsound.h; then
@@ -852,7 +852,7 @@ DragonFly)
 ;;
 NetBSD)
   bsd="yes"
-  hax="yes"
+  hax="enabled"
   make="${MAKE-gmake}"
   audio_drv_list="oss try-sdl"
   audio_possible_drivers="oss sdl"
@@ -869,8 +869,8 @@ OpenBSD)
 Darwin)
   bsd="yes"
   darwin="yes"
-  hax="yes"
-  hvf=""
+  hax="enabled"
+  hvf="auto"
   if [ "$cpu" = "x86_64" ] ; then
 QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS"
 QEMU_LDFLAGS="-arch x86_64 $QEMU_LDFLAGS"
@@ -906,7 +906,7 @@ Linux)
   audio_possible_drivers="oss alsa sdl pa"
   linux="yes"
   linux_user="yes"
-  kvm="yes"
+  kvm="enabled"
   QEMU_INCLUDES="-isystem ${source_path}/linux-headers -Ilinux-headers 
$QEMU_INCLUDES"
 ;;
 esac
@@ -1188,33 +1188,33 @@ for opt do
   ;;
   --enable-netmap) netmap="yes"
   ;;
-  --disable-xen) xen="no"
+  --disable-xen) xen="disabled"
   ;;
-  --enable-xen) xen="yes"
+  --enable-xen) xen="enabled"
   ;;
-  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  --disable-xen-pci-passthrough) xen_pci_passthrough="disabled"
   ;;
-  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  --enable-xen-pci-passthrough) xen_pci_passthrough="enabled"
   ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
   ;;
-  --disable-kvm) kvm="no"
+  --disable-kvm) kvm="disabled"
   ;;
-  --enable-kvm) kvm="yes"
+  --enable-kvm) kvm="enabled"
   ;;
-  --disable-hax) hax="no"
+  --disable-hax) hax="disabled"
   ;;
-  --enable-hax) hax="yes"
+  --enable-hax) hax="enabled"
   ;;
-  --disable-hvf) hvf="no"
+  --disable-hvf) hvf="disabled"
   ;;
-  --enable-hvf) hvf="yes"
+  --enable-hvf) hvf="enabled"
   ;;
-  --disable-whpx) whpx="no"
+  --disable-whpx) whpx="disabled"
   ;;
-  --enable-whpx) whpx="yes"
+  --enable-whpx) whpx="enabled"
   ;;
   --disable-tcg-interpreter) tcg_interpreter="no"
   ;;
@@ -1224,9 +1224,9 @@ for opt do
   ;;
   --enable-cap-ng) cap_ng="yes"
   ;;
-  --disable-tcg) tcg="no"
+  --disable-tcg) tcg="disabled"
   ;;
-  --enable-tcg) tcg="yes"
+  --enable-tcg) tcg="enabled"
   ;;
   --disable-malloc-trim) malloc_trim="disabled"
   ;;
@@ -1711,7 +1711,7 @@ if [ "$ARCH" = "unknown" ]; then
 fi
 
 if [ "$bsd_user" = 

[PULL 17/19] target-i386: post memory failure event to QMP

[Paolo Bonzini]

From: zhenwei pi 

Post memory failure event through QMP to handle hardware memory corrupted
event. Rather than simply printing to the log, QEMU could report more
effective message to the client. For example, if a guest receives an MCE,
evacuating the host could be a good idea.

Signed-off-by: zhenwei pi 
Message-Id: <20200930100440.1060708-4-pizhen...@bytedance.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/helper.c | 24 
 target/i386/kvm.c| 13 -
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/target/i386/helper.c b/target/i386/helper.c
index 17e1684ff9..32fa21a7bb 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -18,6 +18,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qapi/qapi-events-run-state.h"
 #include "cpu.h"
 #include "exec/exec-all.h"
 #include "qemu/qemu-print.h"
@@ -851,6 +852,15 @@ typedef struct MCEInjectionParams {
 int flags;
 } MCEInjectionParams;
 
+static void emit_guest_memory_failure(MemoryFailureAction action, bool ar,
+  bool recursive)
+{
+MemoryFailureFlags mff = {.action_required = ar, .recursive = recursive};
+
+qapi_event_send_memory_failure(MEMORY_FAILURE_RECIPIENT_GUEST, action,
+   &mff);
+}
+
 static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data data)
 {
 MCEInjectionParams *params = data.host_ptr;
@@ -859,16 +869,18 @@ static void do_inject_x86_mce(CPUState *cs, 
run_on_cpu_data data)
 uint64_t *banks = cenv->mce_banks + 4 * params->bank;
 g_autofree char *msg = NULL;
 bool need_reset = false;
+bool recursive;
+bool ar = !!(params->status & MCI_STATUS_AR);
 
 cpu_synchronize_state(cs);
+recursive = !!(cenv->mcg_status & MCG_STATUS_MCIP);
 
 /*
  * If there is an MCE exception being processed, ignore this SRAO MCE
  * unless unconditional injection was requested.
  */
-if (!(params->flags & MCE_INJECT_UNCOND_AO)
-&& !(params->status & MCI_STATUS_AR)
-&& (cenv->mcg_status & MCG_STATUS_MCIP)) {
+if (!(params->flags & MCE_INJECT_UNCOND_AO) && !ar && recursive) {
+emit_guest_memory_failure(MEMORY_FAILURE_ACTION_IGNORE, ar, recursive);
 return;
 }
 
@@ -896,7 +908,7 @@ static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data 
data)
 return;
 }
 
-if (cenv->mcg_status & MCG_STATUS_MCIP) {
+if (recursive) {
 need_reset = true;
 msg = g_strdup_printf("CPU %d: Previous MCE still in progress, "
   "raising triple fault", cs->cpu_index);
@@ -909,6 +921,8 @@ static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data 
data)
 }
 
 if (need_reset) {
+emit_guest_memory_failure(MEMORY_FAILURE_ACTION_RESET, ar,
+  recursive);
 monitor_printf(params->mon, "%s", msg);
 qemu_log_mask(CPU_LOG_RESET, "%s\n", msg);
 qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
@@ -934,6 +948,8 @@ static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data 
data)
 } else {
 banks[1] |= MCI_STATUS_OVER;
 }
+
+emit_guest_memory_failure(MEMORY_FAILURE_ACTION_INJECT, ar, recursive);
 }
 
 void cpu_x86_inject_mce(Monitor *mon, X86CPU *cpu, int bank,
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index f6dae4cfb6..8b12387d30 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -13,6 +13,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qapi/qapi-events-run-state.h"
 #include "qapi/error.h"
 #include 
 #include 
@@ -549,8 +550,17 @@ static void kvm_mce_inject(X86CPU *cpu, hwaddr paddr, int 
code)
(MCM_ADDR_PHYS << 6) | 0xc, flags);
 }
 
+static void emit_hypervisor_memory_failure(MemoryFailureAction action, bool ar)
+{
+MemoryFailureFlags mff = {.action_required = ar, .recursive = false};
+
+qapi_event_send_memory_failure(MEMORY_FAILURE_RECIPIENT_HYPERVISOR, action,
+   &mff);
+}
+
 static void hardware_memory_error(void *host_addr)
 {
+emit_hypervisor_memory_failure(MEMORY_FAILURE_ACTION_FATAL, true);
 error_report("QEMU got Hardware memory error at addr %p", host_addr);
 exit(1);
 }
@@ -605,7 +615,8 @@ void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void 
*addr)
 hardware_memory_error(addr);
 }
 
-/* Hope we are lucky for AO MCE */
+/* Hope we are lucky for AO MCE, just notify a event */
+emit_hypervisor_memory_failure(MEMORY_FAILURE_ACTION_IGNORE, false);
 }
 
 static void kvm_reset_exception(CPUX86State *env)
-- 
2.26.2

[PULL 06/19] configure: remove dead variable

[Paolo Bonzini]

Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/configure b/configure
index 9224ac47e6..2133239593 100755
--- a/configure
+++ b/configure
@@ -811,9 +811,6 @@ fi
 
 # OS specific
 
-# host *BSD for user mode
-HOST_VARIANT_DIR=""
-
 case $targetos in
 MINGW32*)
   mingw32="yes"
@@ -839,14 +836,12 @@ FreeBSD)
   audio_possible_drivers="oss sdl pa"
   # needed for kinfo_getvmmap(3) in libutil.h
   netmap=""  # enable netmap autodetect
-  HOST_VARIANT_DIR="freebsd"
 ;;
 DragonFly)
   bsd="yes"
   make="${MAKE-gmake}"
   audio_drv_list="oss try-sdl"
   audio_possible_drivers="oss sdl pa"
-  HOST_VARIANT_DIR="dragonfly"
 ;;
 NetBSD)
   bsd="yes"
@@ -854,14 +849,12 @@ NetBSD)
   audio_drv_list="oss try-sdl"
   audio_possible_drivers="oss sdl"
   oss_lib="-lossaudio"
-  HOST_VARIANT_DIR="netbsd"
 ;;
 OpenBSD)
   bsd="yes"
   make="${MAKE-gmake}"
   audio_drv_list="try-sdl"
   audio_possible_drivers="sdl"
-  HOST_VARIANT_DIR="openbsd"
 ;;
 Darwin)
   bsd="yes"
@@ -877,7 +870,6 @@ Darwin)
   # Disable attempts to use ObjectiveC features in os/object.h since they
   # won't work when we're compiling with gcc as a C compiler.
   QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS"
-  HOST_VARIANT_DIR="darwin"
 ;;
 SunOS)
   solaris="yes"
@@ -7613,9 +7605,6 @@ if [ "$TARGET_ABI_DIR" = "" ]; then
   TARGET_ABI_DIR=$TARGET_ARCH
 fi
 echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak
-if [ "$HOST_VARIANT_DIR" != "" ]; then
-echo "HOST_VARIANT_DIR=$HOST_VARIANT_DIR" >> $config_target_mak
-fi
 if [ "$TARGET_SYSTBL_ABI" != "" ]; then
 echo "TARGET_SYSTBL_ABI=$TARGET_SYSTBL_ABI" >> $config_target_mak
 echo "TARGET_SYSTBL=$TARGET_SYSTBL" >> $config_target_mak
-- 
2.26.2

[PULL 05/19] configure: move accelerator logic to meson

[Paolo Bonzini]

Move to meson the code to detect the presence of accelerators, and
to define accelerator-specific config-target.h symbols.

The logic for now is duplicated in configure because it is still
in use to build the list of targets (which is in turn used to
create the config-target.mak files).  The next patches remove it.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Signed-off-by: Paolo Bonzini 
---
 configure   |  19 -
 meson.build | 109 
 2 files changed, 94 insertions(+), 34 deletions(-)

diff --git a/configure b/configure
index 9dec87e186..9224ac47e6 100755
--- a/configure
+++ b/configure
@@ -6842,7 +6842,6 @@ if test "$optreset" = "yes" ; then
   echo "HAVE_OPTRESET=y" >> $config_host_mak
 fi
 if test "$tcg" = "enabled"; then
-  echo "CONFIG_TCG=y" >> $config_host_mak
   if test "$tcg_interpreter" = "yes" ; then
 echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak
   fi
@@ -7622,24 +7621,6 @@ if [ "$TARGET_SYSTBL_ABI" != "" ]; then
 echo "TARGET_SYSTBL=$TARGET_SYSTBL" >> $config_target_mak
 fi
 
-if supported_xen_target $target; then
-echo "CONFIG_XEN=y" >> $config_target_mak
-if test "$xen_pci_passthrough" = enabled; then
-echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
-fi
-fi
-if supported_kvm_target $target; then
-echo "CONFIG_KVM=y" >> $config_target_mak
-fi
-if supported_hax_target $target; then
-echo "CONFIG_HAX=y" >> $config_target_mak
-fi
-if supported_hvf_target $target; then
-echo "CONFIG_HVF=y" >> $config_target_mak
-fi
-if supported_whpx_target $target; then
-echo "CONFIG_WHPX=y" >> $config_target_mak
-fi
 if test "$target_aligned_only" = "yes" ; then
   echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
 fi
diff --git a/meson.build b/meson.build
index 41e5763e75..43ce1272b9 100644
--- a/meson.build
+++ b/meson.build
@@ -50,6 +50,28 @@ configure_file(input: files('scripts/ninjatool.py'),
output: 'ninjatool',
configuration: config_host)
 
+if cpu in ['x86', 'x86_64']
+  kvm_targets = ['i386-softmmu', 'x86_64-softmmu']
+elif cpu == 'aarch64'
+  kvm_targets = ['aarch64-softmmu']
+elif cpu == 's390x'
+  kvm_targets = ['s390x-softmmu']
+elif cpu in ['ppc', 'ppc64']
+  kvm_targets = ['ppc-softmmu', 'ppc64-softmmu']
+else
+  kvm_targets = []
+endif
+
+accelerator_targets = { 'CONFIG_KVM': kvm_targets }
+if cpu in ['x86', 'x86_64']
+  accelerator_targets += {
+'CONFIG_HAX': ['i386-softmmu', 'x86_64-softmmu'],
+'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
+'CONFIG_HVF': ['x86_64-softmmu'],
+'CONFIG_WHPX': ['i386-softmmu', 'x86_64-softmmu'],
+  }
+endif
+
 ##
 # Compiler flags #
 ##
@@ -103,7 +125,7 @@ version_res = []
 coref = []
 iokit = []
 cocoa = not_found
-hvf = []
+hvf = not_found
 if targetos == 'windows'
   socket = cc.find_library('ws2_32')
   winmm = cc.find_library('winmm')
@@ -116,7 +138,6 @@ elif targetos == 'darwin'
   coref = dependency('appleframeworks', modules: 'CoreFoundation')
   iokit = dependency('appleframeworks', modules: 'IOKit')
   cocoa = dependency('appleframeworks', modules: 'Cocoa', required: 
get_option('cocoa'))
-  hvf = dependency('appleframeworks', modules: 'Hypervisor')
 elif targetos == 'sunos'
   socket = [cc.find_library('socket'),
 cc.find_library('nsl'),
@@ -127,6 +148,64 @@ elif targetos == 'haiku'
 cc.find_library('bsd')]
 endif
 
+accelerators = []
+if not get_option('kvm').disabled() and targetos == 'linux'
+  accelerators += 'CONFIG_KVM'
+endif
+if not get_option('xen').disabled() and 'CONFIG_XEN_BACKEND' in config_host
+  accelerators += 'CONFIG_XEN'
+  have_xen_pci_passthrough = not get_option('xen_pci_passthrough').disabled() 
and targetos == 'linux'
+else
+  have_xen_pci_passthrough = false
+endif
+if not get_option('whpx').disabled() and targetos == 'windows'
+  if get_option('whpx').enabled() and cpu != 'x86_64'
+error('WHPX requires 64-bit host')
+  elif cc.has_header('WinHvPlatform.h', required: get_option('whpx')) and \
+   cc.has_header('WinHvEmulation.h', required: get_option('whpx'))
+accelerators += 'CONFIG_WHPX'
+  endif
+endif
+if not get_option('hvf').disabled()
+  hvf = dependency('appleframeworks', modules: 'Hypervisor',
+   required: get_option('hvf'))
+  if hvf.found()
+accelerators += 'CONFIG_HVF'
+  endif
+endif
+if not get_option('hax').disabled()
+  if get_option('hax').enabled() or targetos in ['windows', 'darwin', 'netbsd']
+accelerators += 'CONFIG_HAX'
+  endif
+endif
+if not get_option('tcg').disabled()
+  if cpu not in supported_cpus
+if 'CONFIG_TCG_INTERPRETER' in config_host
+  warning('Unsupported CPU @0@, will use TCG with TCI 
(experimental)'.format(cpu))
+else
+  error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu))
+endif
+  endif
+  accelerators += 'CONFIG_TCG'
+  config_host += { 'CONFIG_TCG': 'y' }
+endif
+
+if 

[PULL 19/19] dockerfiles: add diffutils to Fedora

[Paolo Bonzini]

For some reason diffutils is not included in the Fedora containers anymore,
causing the build to fail.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Neal Gompa 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20201003085054.332992-2-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 tests/docker/dockerfiles/fedora.docker | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 71e4b56977..ec783418c8 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -11,6 +11,7 @@ ENV PACKAGES \
 cyrus-sasl-devel \
 dbus-daemon \
 device-mapper-multipath-devel \
+diffutils \
 findutils \
 gcc \
 gcc-c++ \
-- 
2.26.2

[PULL 12/19] default-configs: use TARGET_ARCH key

[Paolo Bonzini]

Replace the individual TARGET_*=y lines with TARGET_ARCH,
similar to how TARGET_BASE_ARCH is handled already.

Signed-off-by: Paolo Bonzini 
---
 default-configs/targets/aarch64-linux-user.mak  | 2 +-
 default-configs/targets/aarch64-softmmu.mak | 2 +-
 default-configs/targets/aarch64_be-linux-user.mak   | 2 +-
 default-configs/targets/alpha-linux-user.mak| 2 +-
 default-configs/targets/alpha-softmmu.mak   | 2 +-
 default-configs/targets/arm-linux-user.mak  | 2 +-
 default-configs/targets/arm-softmmu.mak | 2 +-
 default-configs/targets/armeb-linux-user.mak| 2 +-
 default-configs/targets/avr-softmmu.mak | 2 +-
 default-configs/targets/cris-linux-user.mak | 2 +-
 default-configs/targets/cris-softmmu.mak| 2 +-
 default-configs/targets/hppa-linux-user.mak | 2 +-
 default-configs/targets/hppa-softmmu.mak| 2 +-
 default-configs/targets/i386-bsd-user.mak   | 2 +-
 default-configs/targets/i386-linux-user.mak | 2 +-
 default-configs/targets/i386-softmmu.mak| 2 +-
 default-configs/targets/lm32-softmmu.mak| 2 +-
 default-configs/targets/m68k-linux-user.mak | 2 +-
 default-configs/targets/m68k-softmmu.mak| 2 +-
 default-configs/targets/microblaze-linux-user.mak   | 2 +-
 default-configs/targets/microblaze-softmmu.mak  | 2 +-
 default-configs/targets/microblazeel-linux-user.mak | 2 +-
 default-configs/targets/microblazeel-softmmu.mak| 2 +-
 default-configs/targets/mips-linux-user.mak | 2 +-
 default-configs/targets/mips-softmmu.mak| 2 +-
 default-configs/targets/mips64-linux-user.mak   | 2 +-
 default-configs/targets/mips64-softmmu.mak  | 2 +-
 default-configs/targets/mips64el-linux-user.mak | 2 +-
 default-configs/targets/mips64el-softmmu.mak| 2 +-
 default-configs/targets/mipsel-linux-user.mak   | 2 +-
 default-configs/targets/mipsel-softmmu.mak  | 2 +-
 default-configs/targets/mipsn32-linux-user.mak  | 2 +-
 default-configs/targets/mipsn32el-linux-user.mak| 2 +-
 default-configs/targets/moxie-softmmu.mak   | 2 +-
 default-configs/targets/nios2-linux-user.mak| 2 +-
 default-configs/targets/nios2-softmmu.mak   | 2 +-
 default-configs/targets/or1k-linux-user.mak | 2 +-
 default-configs/targets/or1k-softmmu.mak| 2 +-
 default-configs/targets/ppc-linux-user.mak  | 2 +-
 default-configs/targets/ppc-softmmu.mak | 2 +-
 default-configs/targets/ppc64-linux-user.mak| 2 +-
 default-configs/targets/ppc64-softmmu.mak   | 2 +-
 default-configs/targets/ppc64abi32-linux-user.mak   | 2 +-
 default-configs/targets/ppc64le-linux-user.mak  | 2 +-
 default-configs/targets/riscv32-linux-user.mak  | 2 +-
 default-configs/targets/riscv32-softmmu.mak | 2 +-
 default-configs/targets/riscv64-linux-user.mak  | 2 +-
 default-configs/targets/riscv64-softmmu.mak | 2 +-
 default-configs/targets/rx-softmmu.mak  | 2 +-
 default-configs/targets/s390x-linux-user.mak| 2 +-
 default-configs/targets/s390x-softmmu.mak   | 2 +-
 default-configs/targets/sh4-linux-user.mak  | 2 +-
 default-configs/targets/sh4-softmmu.mak | 2 +-
 default-configs/targets/sh4eb-linux-user.mak| 2 +-
 default-configs/targets/sh4eb-softmmu.mak   | 2 +-
 default-configs/targets/sparc-bsd-user.mak  | 2 +-
 default-configs/targets/sparc-linux-user.mak| 2 +-
 default-configs/targets/sparc-softmmu.mak   | 2 +-
 default-configs/targets/sparc32plus-linux-user.mak  | 2 +-
 default-configs/targets/sparc64-bsd-user.mak| 2 +-
 default-configs/targets/sparc64-linux-user.mak  | 2 +-
 default-configs/targets/sparc64-softmmu.mak | 2 +-
 default-configs/targets/tilegx-linux-user.mak   | 2 +-
 default-configs/targets/tricore-softmmu.mak | 2 +-
 default-configs/targets/unicore32-softmmu.mak   | 2 +-
 default-configs/targets/x86_64-bsd-user.mak | 2 +-
 default-configs/targets/x86_64-linux-user.mak   | 2 +-
 default-configs/targets/x86_64-softmmu.mak  | 2 +-
 default-configs/targets/xtensa-linux-user.mak   | 2 +-
 default-configs/targets/xtensa-softmmu.mak  | 2 +-
 default-configs/targets/xtensaeb-linux-user.mak | 2 +-
 default-configs/targets/xtensaeb-softmmu.mak| 2 +-
 meson.build | 5 -
 73 files changed, 76 insertions(+), 73 deletions(-)

diff --git a/default-configs/targets/aarch64-linux-user.mak 
b/default-configs/targets/aarch64-linux-user.mak
index 4495e86509..d6c4a35c39 100644
--- a/default-configs/targets/aarch64-linux-user.mak
+++ b/default-configs/targets/aarch64-linux-user.mak
@@ -1,4 +1,4 @@
-TARGET_AARCH64=y
+TARGET_ARCH=aarch64
 TARGET_BASE_ARCH=arm
 TARGET_ABI_DIR=aarch64
 TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.

Re: [RFC PATCH 13/21] contrib/gitdm: Add more entries to the Red Hat domain

[Philippe Mathieu-Daudé]

On Mon, Oct 5, 2020 at 10:05 AM Frediano Ziglio  wrote:
>
> Hi,
>   can I disagree? If the contribution is personal I use my personal address, 
> if the contribution is from the job in the company I'm using the company 
> address.

Certainly! Can I add your personal address to the "individual
contributor" list instead?

>
> Regards,
>Frediano
>
>
> Il giorno dom 4 ott 2020 alle ore 19:05 Philippe Mathieu-Daudé 
>  ha scritto:
>>
>> Cc: Frediano Ziglio 
>> Cc: Frediano Ziglio 
>> Cc: Nir Soffer 
>> Cc: Nir Soffer 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> To the developers Cc'ed: If you agree with your entry, please
>> reply with a Reviewed-by/Acked-by tag. If you disagree or doesn't
>> care, please either reply with Nack-by or ignore this patch.
>> I'll repost in 2 weeks as formal patch (not RFC) with only the
>> entries acked by their author.
>> ---
>>  contrib/gitdm/group-map-redhat | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/contrib/gitdm/group-map-redhat b/contrib/gitdm/group-map-redhat
>> index d15db2d35e..0419e82795 100644
>> --- a/contrib/gitdm/group-map-redhat
>> +++ b/contrib/gitdm/group-map-redhat
>> @@ -6,3 +6,5 @@ da...@gibson.dropbear.id.au
>>  laur...@vivier.eu
>>  p...@fedoraproject.org
>>  arm...@pond.sub.org
>> +fredd...@gmail.com
>> +nir...@gmail.com
>> --
>> 2.26.2
>>

[PULL 09/19] configure: remove target configuration

[Paolo Bonzini]

The config-target.mak files are small constant, we can therefore just
write them down explicitly.

This removes a pretty large part of the configure script, including the
whole logic to detect which accelerators are supported by each target.

Signed-off-by: Paolo Bonzini 
---
 configure | 474 +-
 .../targets/aarch64-linux-user.mak|   5 +
 default-configs/targets/aarch64-softmmu.mak   |   4 +
 .../targets/aarch64_be-linux-user.mak |   6 +
 default-configs/targets/alpha-linux-user.mak  |   6 +
 default-configs/targets/alpha-softmmu.mak |   4 +
 default-configs/targets/arm-linux-user.mak|   7 +
 default-configs/targets/arm-softmmu.mak   |   4 +
 default-configs/targets/armeb-linux-user.mak  |   8 +
 default-configs/targets/avr-softmmu.mak   |   3 +
 default-configs/targets/cris-linux-user.mak   |   3 +
 default-configs/targets/cris-softmmu.mak  |   2 +
 default-configs/targets/hppa-linux-user.mak   |   7 +
 default-configs/targets/hppa-softmmu.mak  |   5 +
 default-configs/targets/i386-bsd-user.mak |   4 +
 default-configs/targets/i386-linux-user.mak   |   6 +
 default-configs/targets/i386-softmmu.mak  |   4 +
 default-configs/targets/lm32-softmmu.mak  |   3 +
 default-configs/targets/m68k-linux-user.mak   |   8 +
 default-configs/targets/m68k-softmmu.mak  |   4 +
 .../targets/microblaze-linux-user.mak |   7 +
 .../targets/microblaze-softmmu.mak|   4 +
 .../targets/microblazeel-linux-user.mak   |   6 +
 .../targets/microblazeel-softmmu.mak  |   3 +
 default-configs/targets/mips-linux-user.mak   |   8 +
 default-configs/targets/mips-softmmu.mak  |   5 +
 default-configs/targets/mips64-linux-user.mak |   8 +
 default-configs/targets/mips64-softmmu.mak|   4 +
 .../targets/mips64el-linux-user.mak   |   7 +
 default-configs/targets/mips64el-softmmu.mak  |   3 +
 default-configs/targets/mipsel-linux-user.mak |   7 +
 default-configs/targets/mipsel-softmmu.mak|   4 +
 .../targets/mipsn32-linux-user.mak|   9 +
 .../targets/mipsn32el-linux-user.mak  |   8 +
 default-configs/targets/moxie-softmmu.mak |   3 +
 default-configs/targets/nios2-linux-user.mak  |   3 +
 default-configs/targets/nios2-softmmu.mak |   2 +
 default-configs/targets/or1k-linux-user.mak   |   4 +
 default-configs/targets/or1k-softmmu.mak  |   3 +
 default-configs/targets/ppc-linux-user.mak|   7 +
 default-configs/targets/ppc-softmmu.mak   |   4 +
 default-configs/targets/ppc64-linux-user.mak  |   7 +
 default-configs/targets/ppc64-softmmu.mak |   5 +
 .../targets/ppc64abi32-linux-user.mak |   8 +
 .../targets/ppc64le-linux-user.mak|   6 +
 .../targets/riscv32-linux-user.mak|   4 +
 default-configs/targets/riscv32-softmmu.mak   |   4 +
 .../targets/riscv64-linux-user.mak|   4 +
 default-configs/targets/riscv64-softmmu.mak   |   4 +
 default-configs/targets/rx-softmmu.mak|   3 +
 default-configs/targets/s390x-linux-user.mak  |   7 +
 default-configs/targets/s390x-softmmu.mak |   5 +
 default-configs/targets/sh4-linux-user.mak|   7 +
 default-configs/targets/sh4-softmmu.mak   |   3 +
 default-configs/targets/sh4eb-linux-user.mak  |   8 +
 default-configs/targets/sh4eb-softmmu.mak |   4 +
 default-configs/targets/sparc-bsd-user.mak|   5 +
 default-configs/targets/sparc-linux-user.mak  |   7 +
 default-configs/targets/sparc-softmmu.mak |   4 +
 .../targets/sparc32plus-linux-user.mak|   8 +
 default-configs/targets/sparc64-bsd-user.mak  |   5 +
 .../targets/sparc64-linux-user.mak|   7 +
 default-configs/targets/sparc64-softmmu.mak   |   4 +
 default-configs/targets/tilegx-linux-user.mak |   3 +
 default-configs/targets/tricore-softmmu.mak   |   2 +
 default-configs/targets/unicore32-softmmu.mak |   2 +
 default-configs/targets/x86_64-bsd-user.mak   |   4 +
 default-configs/targets/x86_64-linux-user.mak |   6 +
 default-configs/targets/x86_64-softmmu.mak|   4 +
 default-configs/targets/xtensa-linux-user.mak |   7 +
 default-configs/targets/xtensa-softmmu.mak|   4 +
 .../targets/xtensaeb-linux-user.mak   |   8 +
 default-configs/targets/xtensaeb-softmmu.mak  |   5 +
 meson.build   |  27 +-
 74 files changed, 412 insertions(+), 455 deletions(-)
 create mode 100644 default-configs/targets/aarch64-linux-user.mak
 create mode 100644 default-configs/targets/aarch64-softmmu.mak
 create mode 100644 default-configs/targets/aarch64_be-linux-user.mak
 create mode 100644 default-configs/targets/alpha-linux-user.mak
 create mode 100644 default-configs/targets/alpha-softmmu.mak
 create mode 100644 default-configs/targets/arm-linux-user.mak
 create mode 100644 default-configs/targets/arm-softmmu.mak
 create mode 100644 default-configs/targets/armeb-linux-user.mak
 create mode 100644 default-configs/targets/avr-softmmu.mak
 cr

Re: [RFC PATCH 13/21] contrib/gitdm: Add more entries to the Red Hat domain

[Frediano Ziglio]

Il giorno lun 5 ott 2020 alle ore 09:39 Philippe Mathieu-Daudé <
f4...@amsat.org> ha scritto:

> On Mon, Oct 5, 2020 at 10:05 AM Frediano Ziglio 
> wrote:
> >
> > Hi,
> >   can I disagree? If the contribution is personal I use my personal
> address, if the contribution is from the job in the company I'm using the
> company address.
>
> Certainly! Can I add your personal address to the "individual
> contributor" list instead?
>
>
Sure

>
> > Regards,
> >Frediano
> >
> >
> > Il giorno dom 4 ott 2020 alle ore 19:05 Philippe Mathieu-Daudé <
> f4...@amsat.org> ha scritto:
> >>
> >> Cc: Frediano Ziglio 
> >> Cc: Frediano Ziglio 
> >> Cc: Nir Soffer 
> >> Cc: Nir Soffer 
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >> To the developers Cc'ed: If you agree with your entry, please
> >> reply with a Reviewed-by/Acked-by tag. If you disagree or doesn't
> >> care, please either reply with Nack-by or ignore this patch.
> >> I'll repost in 2 weeks as formal patch (not RFC) with only the
> >> entries acked by their author.
> >> ---
> >>  contrib/gitdm/group-map-redhat | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/contrib/gitdm/group-map-redhat
> b/contrib/gitdm/group-map-redhat
> >> index d15db2d35e..0419e82795 100644
> >> --- a/contrib/gitdm/group-map-redhat
> >> +++ b/contrib/gitdm/group-map-redhat
> >> @@ -6,3 +6,5 @@ da...@gibson.dropbear.id.au
> >>  laur...@vivier.eu
> >>  p...@fedoraproject.org
> >>  arm...@pond.sub.org
> >> +fredd...@gmail.com
> >> +nir...@gmail.com
> >> --
> >> 2.26.2
> >>
>

[PULL 14/19] meson: move sparse detection to Meson and rewrite check_sparse.py

[Paolo Bonzini]

Pass the path to the program to scripts/check_sparse.py, which
previously was not included in config-host.mak.  Change
scripts/check_sparse.py to work with cgcc, which seems to
work better with sparse 0.6.x.

Signed-off-by: Paolo Bonzini 
---
 configure   | 24 +++---
 meson.build | 10 +---
 meson_options.txt   |  2 ++
 scripts/check_sparse.py | 56 +
 4 files changed, 57 insertions(+), 35 deletions(-)

diff --git a/configure b/configure
index b31bf24d60..baa245b5ad 100755
--- a/configure
+++ b/configure
@@ -303,7 +303,7 @@ sdl_image="auto"
 virtfs=""
 mpath="auto"
 vnc="enabled"
-sparse="no"
+sparse="auto"
 vde=""
 vnc_sasl="auto"
 vnc_jpeg="auto"
@@ -1040,9 +1040,9 @@ for opt do
   ;;
   --disable-tsan) tsan="no"
   ;;
-  --enable-sparse) sparse="yes"
+  --enable-sparse) sparse="enabled"
   ;;
-  --disable-sparse) sparse="no"
+  --disable-sparse) sparse="disabled"
   ;;
   --disable-strip) strip_opt="no"
   ;;
@@ -2875,19 +2875,6 @@ if test "$gettext" != "false" ; then
   fi
 fi
 
-##
-# Sparse probe
-if test "$sparse" != "no" ; then
-  if has sparse; then
-sparse=yes
-  else
-if test "$sparse" = "yes" ; then
-  feature_not_found "sparse" "Install sparse binary"
-fi
-sparse=no
-  fi
-fi
-
 ##
 # X11 probe
 if $pkg_config --exists "x11"; then
@@ -7127,9 +7114,6 @@ echo "QEMU_CXXFLAGS=$QEMU_CXXFLAGS" >> $config_host_mak
 echo "QEMU_INCLUDES=$QEMU_INCLUDES" >> $config_host_mak
 echo "GLIB_CFLAGS=$glib_cflags" >> $config_host_mak
 echo "GLIB_LIBS=$glib_libs" >> $config_host_mak
-if test "$sparse" = "yes" ; then
-  echo "SPARSE_CFLAGS = -Wbitwise -Wno-transparent-union -Wno-old-initializer 
-Wno-non-pointer-null" >> $config_host_mak
-fi
 echo "QEMU_LDFLAGS=$QEMU_LDFLAGS" >> $config_host_mak
 echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak
 echo "LD_I386_EMULATION=$ld_i386_emulation" >> $config_host_mak
@@ -7382,7 +7366,7 @@ NINJA=${ninja:-$PWD/ninjatool} $meson setup \
 -Dstrip=$(if test "$strip_opt" = yes; then echo true; else echo false; 
fi) \
 -Db_pie=$(if test "$pie" = yes; then echo true; else echo false; fi) \
 -Db_coverage=$(if test "$gcov" = yes; then echo true; else echo false; 
fi) \
-   -Dmalloc=$malloc -Dmalloc_trim=$malloc_trim \
+   -Dmalloc=$malloc -Dmalloc_trim=$malloc_trim -Dsparse=$sparse \
-Dkvm=$kvm -Dhax=$hax -Dwhpx=$whpx -Dhvf=$hvf \
-Dxen=$xen -Dxen_pci_passthrough=$xen_pci_passthrough -Dtcg=$tcg \
-Dcocoa=$cocoa -Dmpath=$mpath -Dsdl=$sdl -Dsdl_image=$sdl_image \
diff --git a/meson.build b/meson.build
index 9a90d19113..1dd3f49011 100644
--- a/meson.build
+++ b/meson.build
@@ -102,11 +102,13 @@ if host_machine.system() == 'darwin'
   add_languages('objc', required: false, native: false)
 endif
 
-if 'SPARSE_CFLAGS' in config_host
+sparse = find_program('cgcc', required: get_option('sparse'))
+if sparse.found()
   run_target('sparse',
  command: [find_program('scripts/check_sparse.py'),
-   config_host['SPARSE_CFLAGS'].split(),
-   'compile_commands.json'])
+   'compile_commands.json', sparse.full_path(), 
'-Wbitwise',
+   '-Wno-transparent-union', '-Wno-old-initializer',
+   '-Wno-non-pointer-null'])
 endif
 
 ###
@@ -1557,7 +1559,7 @@ summary_info += {'host CPU':  cpu}
 summary_info += {'host endianness':   build_machine.endian()}
 summary_info += {'target list':   ' '.join(target_dirs)}
 summary_info += {'gprof enabled': config_host.has_key('CONFIG_GPROF')}
-summary_info += {'sparse enabled':
meson.get_compiler('c').cmd_array().contains('cgcc')}
+summary_info += {'sparse enabled':sparse.found()}
 summary_info += {'strip binaries':get_option('strip')}
 summary_info += {'profiler':  config_host.has_key('CONFIG_PROFILER')}
 summary_info += {'static build':  config_host.has_key('CONFIG_STATIC')}
diff --git a/meson_options.txt b/meson_options.txt
index 05adc7a179..bc5c674642 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -5,6 +5,8 @@ option('docdir', type : 'string', value : 'doc',
 
 option('gettext', type : 'boolean', value : true,
description: 'Localization of the GTK+ user interface')
+option('sparse', type : 'feature', value : 'auto',
+   description: 'sparse checker')
 
 option('malloc_trim', type : 'feature', value : 'auto',
description: 'enable libc malloc_trim() for memory optimization')
diff --git a/scripts/check_sparse.py b/scripts/check_sparse.py
index 0de7aa55d9..2956124442 100644
--- a/scripts/check_sparse.py
+++ b/scripts/check_sparse.py
@@ -1,25 +1,59 @@
 #! /usr/bin/env python3
 
-# Invoke sparse based on the contents of compile_commands.json
+# Invoke sparse based on the contents of compile_commands.json,
+# als

Re: [PULL v2 00/92] Misc patches for 2020-09-24

[Paolo Bonzini]

On 05/10/20 09:51, Philippe Mathieu-Daudé wrote:
> Is that why your "configure: fix performance regression due to PIC
> objects" patch has been dropped from your pull request?

Partly.

Regarding this particular failure, since Richard's capstone patches are 
being merged, I think it's easier to do the same with slirp and libfdt 
and drop the submodule rules from the makefile altogether.  Then we can
merge safely "configure: fix performance regression due to PIC objects"
and also simplify the CFLAGS/LDFLAGS patches.

Second, I am hoping that https://github.com/mesonbuild/meson/pull/7760 
gets in 0.56.0; then the fix can be simply

diff --git a/meson.build b/meson.build
index 1dd3f49011..d29b9d41db 100644
--- a/meson.build
+++ b/meson.build
@@ -1,6 +1,6 @@
 project('qemu', ['c'], meson_version: '>=0.55.0',
-default_options: ['warning_level=1', 'c_std=gnu99', 'cpp_std=gnu++11',
-  'b_colorout=auto'],
+default_options: ['warning_level=1', 'c_std=gnu99', 'cpp_std=gnu++11', 
'b_colorout=auto'] +
+ (meson.version().version_compare('>=0.56.0') ? 
['b_staticpic=false'] : []),
 version: run_command('head', meson.source_root() / 
'VERSION').stdout().strip())
 
 not_found = dependency('', required: false)
 
Paolo

[PULL 15/19] target-i386: seperate MCIP & MCE_MASK error reason

[Paolo Bonzini]

From: zhenwei pi 

Previously we would only get a simple string "Triple fault" in qemu
log. Add detailed message for the two reasons to describe why qemu
has to reset the guest.

Signed-off-by: zhenwei pi 
Message-Id: <20200930100440.1060708-2-pizhen...@bytedance.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/helper.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/target/i386/helper.c b/target/i386/helper.c
index 70be53e2c3..17e1684ff9 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -857,6 +857,8 @@ static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data 
data)
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *cenv = &cpu->env;
 uint64_t *banks = cenv->mce_banks + 4 * params->bank;
+g_autofree char *msg = NULL;
+bool need_reset = false;
 
 cpu_synchronize_state(cs);
 
@@ -894,16 +896,25 @@ static void do_inject_x86_mce(CPUState *cs, 
run_on_cpu_data data)
 return;
 }
 
-if ((cenv->mcg_status & MCG_STATUS_MCIP) ||
-!(cenv->cr[4] & CR4_MCE_MASK)) {
-monitor_printf(params->mon,
-   "CPU %d: Previous MCE still in progress, raising"
-   " triple fault\n",
-   cs->cpu_index);
-qemu_log_mask(CPU_LOG_RESET, "Triple fault\n");
+if (cenv->mcg_status & MCG_STATUS_MCIP) {
+need_reset = true;
+msg = g_strdup_printf("CPU %d: Previous MCE still in progress, "
+  "raising triple fault", cs->cpu_index);
+}
+
+if (!(cenv->cr[4] & CR4_MCE_MASK)) {
+need_reset = true;
+msg = g_strdup_printf("CPU %d: MCE capability is not enabled, "
+  "raising triple fault", cs->cpu_index);
+}
+
+if (need_reset) {
+monitor_printf(params->mon, "%s", msg);
+qemu_log_mask(CPU_LOG_RESET, "%s\n", msg);
 qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
 return;
 }
+
 if (banks[1] & MCI_STATUS_VAL) {
 params->status |= MCI_STATUS_OVER;
 }
-- 
2.26.2

Re: [PATCH] qom: Improve error message displayed with missing object properties

[Paolo Bonzini]

On 20/09/20 17:53, Philippe Mathieu-Daudé wrote:
> Instead of only displaying the property missing, also display
> the object name. This help developer to quickly figure out the
> mistake without opening a debugger.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  qom/object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/qom/object.c b/qom/object.c
> index 387efb25ebe..257914b1fe3 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -1259,7 +1259,8 @@ ObjectProperty *object_property_find(Object *obj, const 
> char *name,
>  return prop;
>  }
>  
> -error_setg(errp, "Property '.%s' not found", name);
> +error_setg(errp, "Property '%s.%s' not found",
> +   object_get_typename(obj), name);
>  return NULL;
>  }
>  
> 

Acked-by: Paolo Bonzini 

I think it's okay for qemu-trivial.

Re: [PATCH 0/5] qapi: Restrict machine (and migration) specific commands

[Paolo Bonzini]

On 05/10/20 10:01, Markus Armbruster wrote:
> Philippe Mathieu-Daudé  writes:
> 
>> Reduce the machine code pulled into qemu-storage-daemon.
> I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
> Juan for PATCH 5.  David already ACKed.
> 
> Can do the pull request.
> 

If it counts, :) for patch 1-4:

Acked-by: Paolo Bonzini 

Generally these patches to remove code from user-mode emulators
fall into the "if it builds it's fine" bucket, since I assume
we want the "misc" subschema to be as small as possible.

Paolo

[PULL 18/19] tests: tcg: do not use implicit rules

[Paolo Bonzini]

Use pattern rules to clarify which targets are going to match the
rule and to provide clearer error messages.

Signed-off-by: Paolo Bonzini 
---
 tests/Makefile.include | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 40d909badc..5aca98e60c 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -50,21 +50,21 @@ RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, 
$(TARGET_DIRS))
 $(foreach PROBE_TARGET,$(TARGET_DIRS), \
$(eval -include $(SRC_PATH)/tests/tcg/Makefile.prereqs))
 
-build-tcg-tests-%: $(if $(CONFIG_PLUGIN),test-plugins)
+$(BUILD_TCG_TARGET_RULES): build-tcg-tests-%: $(if 
$(CONFIG_PLUGIN),test-plugins)
$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) \
-f $(SRC_PATH)/tests/tcg/Makefile.qemu \
SRC_PATH=$(SRC_PATH) \
V="$(V)" TARGET="$*" guest-tests, \
"BUILD", "TCG tests for $*")
 
-run-tcg-tests-%: build-tcg-tests-% all
+$(RUN_TCG_TARGET_RULES): run-tcg-tests-%: build-tcg-tests-% all
$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) \
-f $(SRC_PATH)/tests/tcg/Makefile.qemu \
SRC_PATH=$(SRC_PATH) SPEED="$(SPEED)" \
V="$(V)" TARGET="$*" run-guest-tests, \
"RUN", "TCG tests for $*")
 
-clean-tcg-tests-%:
+$(CLEAN_TCG_TARGET_RULES): clean-tcg-tests-%:
$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) \
-f $(SRC_PATH)/tests/tcg/Makefile.qemu \
SRC_PATH=$(SRC_PATH) TARGET="$*" clean-guest-tests, \
-- 
2.26.2

[PATCH v2 0/2] hw/virtio-pci: AER capability

[andrew]

From: Andrew Melnychenko 

Now, AER capability for virtio-pci is disabled by default.
AER capability is only for PCI with PCIe interface on PCIe bus.
During migration - device "realize" should initialize AER
if requested by device properties.

Andrew (2):
  hw/virtio-pci Added counter for pcie capabilities offsets.
  hw/virtio-pci Added AER capability.

 hw/virtio/virtio-pci.c | 20 +++-
 hw/virtio/virtio-pci.h |  4 
 2 files changed, 23 insertions(+), 1 deletion(-)

-- 
2.28.0

[PATCH v2 1/2] hw/virtio-pci Added counter for pcie capabilities offsets.

[andrew]

From: Andrew 

Removed hardcoded offset for ats. Added cap offset counter
for future capabilities like AER.

Signed-off-by: Andrew Melnychenko 
---
 hw/virtio/virtio-pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 5bc769f685..ae60c1e249 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1788,6 +1788,7 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 
 if (pcie_port && pci_is_express(pci_dev)) {
 int pos;
+uint16_t last_pcie_cap_offset = PCI_CONFIG_SPACE_SIZE;
 
 pos = pcie_endpoint_cap_init(pci_dev, 0);
 assert(pos > 0);
@@ -1823,7 +1824,8 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 }
 
 if (proxy->flags & VIRTIO_PCI_FLAG_ATS) {
-pcie_ats_init(pci_dev, 256);
+pcie_ats_init(pci_dev, last_pcie_cap_offset);
+last_pcie_cap_offset += PCI_EXT_CAP_ATS_SIZEOF;
 }
 
 if (proxy->flags & VIRTIO_PCI_FLAG_INIT_FLR) {
-- 
2.28.0

[PATCH v2 2/2] hw/virtio-pci Added AER capability.

[andrew]

From: Andrew 

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1857668
Added AER capability for virtio-pci devices.
Also added property for devices, by default AER is enabled.

Signed-off-by: Andrew Melnychenko 
---
 hw/virtio/virtio-pci.c | 16 
 hw/virtio/virtio-pci.h |  4 
 2 files changed, 20 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index ae60c1e249..e0a7936f9c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1807,6 +1807,12 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
  */
 pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
 
+if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
+pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
+  PCI_ERR_SIZEOF, NULL);
+last_pcie_cap_offset += PCI_ERR_SIZEOF;
+}
+
 if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
 /* Init error enabling flags */
 pcie_cap_deverr_init(pci_dev);
@@ -1848,7 +1854,15 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 
 static void virtio_pci_exit(PCIDevice *pci_dev)
 {
+VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
+bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
+ !pci_bus_is_root(pci_get_bus(pci_dev));
+
 msix_uninit_exclusive_bar(pci_dev);
+if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
+pci_is_express(pci_dev)) {
+pcie_aer_exit(pci_dev);
+}
 }
 
 static void virtio_pci_reset(DeviceState *qdev)
@@ -1901,6 +1915,8 @@ static Property virtio_pci_properties[] = {
 VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
 DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
+DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_AER_BIT, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 91096f0291..3986b4f0e3 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -45,6 +45,7 @@ enum {
 VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
 VIRTIO_PCI_FLAG_INIT_PM_BIT,
 VIRTIO_PCI_FLAG_INIT_FLR_BIT,
+VIRTIO_PCI_FLAG_AER_BIT,
 };
 
 /* Need to activate work-arounds for buggy guests at vmstate load. */
@@ -84,6 +85,9 @@ enum {
 /* Init Function Level Reset capability */
 #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
 
+/* Advanced Error Reporting capability */
+#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
+
 typedef struct {
 MSIMessage msg;
 int virq;
-- 
2.28.0

Re: scripts/gdb: issues when loading modules after lx-symbols

[Jan Kiszka]

On 05.10.20 10:14, Stefano Garzarella wrote:
> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
>> On 01.10.20 16:31, Stefano Garzarella wrote:
>>> Hi,
>>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
>>>
>>> If the modules are already loaded, and I do 'lx-symbols', all work fine.
>>> But, if I load a kernel module after 'lx-symbols', I had this issue:
>>>
>>> [ 5093.393940] invalid opcode:  [#1] SMP PTI
>>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
>>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
>>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
>>> 1.13.0-2.fc32 04/01/2014
>>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
>>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 c1 
>>> fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 cc 
>>> <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
>>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
>>> [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
>>> 4ee3
>>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
>>> c010a0c0
>>> [ 5093.416349] RBP: c9563e50 R08:  R09: 
>>> 0002
>>> [ 5093.418044] R10: 0096 R11: 08a4 R12: 
>>> 88807a0d1280
>>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
>>> c9563e70
>>> [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
>>> knlGS:
>>> [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
>>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
>>> 00170ef0
>>> [ 5093.435096] DR0:  DR1:  DR2: 
>>> 
>>> [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
>>> 0400
>>> [ 5093.439689] Call Trace:
>>> [ 5093.440954]  ? load_module+0x24b6/0x27d0
>>> [ 5093.443212]  ? __kernel_read+0xd6/0x150
>>> [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
>>> [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
>>> [ 5093.449098]  do_syscall_64+0x38/0x50
>>> [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [ 5093.456153] RIP: 0033:0x7f018f75c43d
>>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 
>>> 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 
>>> <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
>>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
>>> 0139
>>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
>>> 7f018f75c43d
>>> [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
>>> 0003
>>> [ 5093.478049] RBP: 0004 R08:  R09: 
>>> 
>>> [ 5093.481298] R10: 0003 R11: 0246 R12: 
>>> 
>>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
>>> 557e5c9775c0
>>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel kvm 
>>> irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa]
>>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
>>>
>>> Guest kernel: Linux 5.9-rc7
>>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
>>> I tried with QEMU 4.2.1 and the latest master branch: same issue.
>>>
>>>
>>> I did some digging, and skipping the gdb 'add-symbol-file' command in 
>>> symbol.py
>>> avoid the issue, but of course I don't have the symbols loaded:
>>>
>>> diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
>>> index 1be9763cf8bb..eadfaa4d4907 100644
>>> --- a/scripts/gdb/linux/symbols.py
>>> +++ b/scripts/gdb/linux/symbols.py
>>> @@ -129,7 +129,7 @@ lx-symbols command."""
>>>  filename=module_file,
>>>  addr=module_addr,
>>>  sections=self._section_arguments(module))
>>> -gdb.execute(cmdline, to_string=True)
>>> +#gdb.execute(cmdline, to_string=True)
>>>  if module_name not in self.loaded_modules:
>>>  self.loaded_modules.append(module_name)
>>>  else:
>>>
>>> I tried several modules and this happens every time after '(gdb) 
>>> lx-symbols'.
>>>
>>> Do you have any hints?
>>>
>> I assume you are debugging a kernel inside QEMU/KVM, right?
> 
> Right!
> 
>> Does it work
>> without -enable-kvm?
> 
> Yes, disabling kvm it works.
> 

OK, there it is, still...
What may also "work" is going down to single core.

>>
>> Debugging guests in KVM mode at least was unstable for a long time. I
>> avoided setting soft-BPs - which is what the script does for the sake of
>> tracking modules loading -, falling back to hw-BPs, as I had no time to
>> debug that further. /Maybe/ that's the issue here.
> 
> Thanks for the sugg

Re: [RFC PATCH 09/21] contrib/gitdm: Add Nutanix to the domain map

[Philippe Mathieu-Daudé]

On 10/5/20 7:22 AM, Ani Sinha wrote:
> 
> 
> On Sun, Oct 4, 2020 at 23:34 Philippe Mathieu-Daudé  > wrote:
> 
> There is a number of contributors from this domain,
> add its own entry to the gitdm domain map.
> 
> Cc: Ani Sinha mailto:ani.si...@nutanix.com>>
> Cc: David Vrabel  >
> Cc: Felipe Franciosi mailto:fel...@nutanix.com>>
> Cc: Jonathan Davies  >
> Cc: Malcolm Crossley mailto:malc...@nutanix.com>>
> Cc: Mike Cui mailto:c...@nutanix.com>>
> Cc: Peter Turschmid  >
> Cc: Prerna Saxena  >
> Cc: Raphael Norwitz  >
> Cc: Swapnil Ingle  >
> Cc: Ani Sinha mailto:a...@anisinha.ca>>
> 
> 
> I’ve left Nutanix and not part of the company anymore. Malcolm, David,
> Mike also has left Nutanix.
> 
> 
> 
> Signed-off-by: Philippe Mathieu-Daudé  >
> ---
> One Reviewed-by/Ack-by from someone from this domain
> should be sufficient to get this patch merged.
> 
> Ani, can you confirm the a...@anisinha.ca  email?
> Should it go into 'individual contributors' instead?
> 
> 
> Yes I’m an individual contributor now. 
> 
> 
> ---
>  contrib/gitdm/domain-map        | 1 +
>  contrib/gitdm/group-map-nutanix | 2 ++
>  gitdm.config                    | 1 +
>  3 files changed, 4 insertions(+)
>  create mode 100644 contrib/gitdm/group-map-nutanix
> 
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index 4850eab4c4..39251fd97c 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -24,6 +24,7 @@ linaro.org       Linaro
>  codesourcery.com  Mentor Graphics
>  microsoft.com    Microsoft
>  nokia.com        Nokia
> +nutanix.com      Nutanix
>  oracle.com       Oracle
>  proxmox.com      Proxmox
>  redhat.com       Red Hat
> diff --git a/contrib/gitdm/group-map-nutanix
> b/contrib/gitdm/group-map-nutanix
> new file mode 100644
> index 00..a3f11425b3
> --- /dev/null
> +++ b/contrib/gitdm/group-map-nutanix
> @@ -0,0 +1,2 @@
> +raphael.s.norw...@gmail.com 
> +a...@anisinha.ca 
> 
> 
> Same here. Not part of Nutanix. 

OK I'll correct, thanks for the feedback.

> 
> 
> diff --git a/gitdm.config b/gitdm.config
> index c01c219078..4f821ab8ba 100644
> --- a/gitdm.config
> +++ b/gitdm.config
> @@ -37,6 +37,7 @@ GroupMap contrib/gitdm/group-map-cadence Cadence
> Design Systems
>  GroupMap contrib/gitdm/group-map-codeweavers CodeWeavers
>  GroupMap contrib/gitdm/group-map-ibm IBM
>  GroupMap contrib/gitdm/group-map-janustech Janus Technologies
> +GroupMap contrib/gitdm/group-map-nutanix Nutanix
> 
>  # Also group together our prolific individual contributors
>  # and those working under academic auspices
> -- 
> 2.26.2
> 

Re: [PULL 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 10/1/20 9:18 AM, Laszlo Ersek wrote:
> On 09/29/20 17:46, Kevin Wolf wrote:
>> Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben:
>>> Since our format is consumable by the fw_cfg device,
>>> we can implement the FW_CFG_DATA_GENERATOR interface.
>>>
>>> Example of use to dump the cipher suites (if tracing enabled):
>>>
>>>   $ qemu-system-x86_64 -S \
>>> -object tls-cipher-suites,id=mysuite1,priority=@SYSTEM \
>>> -fw_cfg name=etc/path/to/ciphers,gen_id=mysuite1 \
>>> -trace qcrypto\*
>>>   159066.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM
>>>   159066.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] 
>>> version=TLS1.3 name=TLS_AES_256_GCM_SHA384
>>>   159066.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] 
>>> version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256
>>>   159066.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] 
>>> version=TLS1.3 name=TLS_AES_128_GCM_SHA256
>>>   159066.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] 
>>> version=TLS1.3 name=TLS_AES_128_CCM_SHA256
>>>   159066.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] 
>>> version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384
>>>   159066.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] 
>>> version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305
>>>   159066.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] 
>>> version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1
>>>   159066.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] 
>>> version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256
>>>   159066.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] 
>>> version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1
>>>   159066.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] 
>>> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
>>>   159066.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] 
>>> version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305
>>>   159066.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] 
>>> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM
>>>   159066.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] 
>>> version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
>>>   159066.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] 
>>> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
>>>   159066.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] 
>>> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM
>>>   159066.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] 
>>> version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1
>>>   159066.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] 
>>> version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384
>>>   159066.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] 
>>> version=TLS1.2 name=TLS_RSA_AES_256_CCM
>>>   159066.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] 
>>> version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1
>>>   159066.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] 
>>> version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256
>>>   159066.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] 
>>> version=TLS1.2 name=TLS_RSA_AES_128_CCM
>>>   159066.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] 
>>> version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1
>>>   159066.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] 
>>> version=TLS1.2 name=TLS_DHE_RSA_AES_256_GCM_SHA384
>>>   159066.197320:qcrypto_tls_cipher_suite_info data=[0xcc,0xaa] 
>>> version=TLS1.2 name=TLS_DHE_RSA_CHACHA20_POLY1305
>>>   159066.197325:qcrypto_tls_cipher_suite_info data=[0xc0,0x9f] 
>>> version=TLS1.2 name=TLS_DHE_RSA_AES_256_CCM
>>>   159066.197329:qcrypto_tls_cipher_suite_info data=[0x00,0x39] 
>>> version=TLS1.0 name=TLS_DHE_RSA_AES_256_CBC_SHA1
>>>   159066.197333:qcrypto_tls_cipher_suite_info data=[0x00,0x9e] 
>>> version=TLS1.2 name=TLS_DHE_RSA_AES_128_GCM_SHA256
>>>   159066.197337:qcrypto_tls_cipher_suite_info data=[0xc0,0x9e] 
>>> version=TLS1.2 name=TLS_DHE_RSA_AES_128_CCM
>>>   159066.197341:qcrypto_tls_cipher_suite_info data=[0x00,0x33] 
>>> version=TLS1.0 name=TLS_DHE_RSA_AES_128_CBC_SHA1
>>>   159066.197345:qcrypto_tls_cipher_suite_count count: 29
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> Reviewed-by: Daniel P. Berrangé 
>>> Acked-by: Laszlo Ersek 
>>> Message-Id: <20200623172726.21040-6-phi...@redhat.com>
>>
>> I noticed only now that this breaks '--object help' in
>> qemu-storage-daemon:
>>
>> $ qemu-storage-daemon --object help
>> List of user creatable objects:
>> qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 
>> 'tls-creds'
>> Aborted (core dumped)
>>
>> The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the
>> storage daemon because it requires other system emulator stuff.
> 
> Ouch. I've been completely oblivious to "--object help" and how it
> affects qemu-storage-daemon. Sorry about that.
> 

Re: [RFC PATCH 20/21] contrib/gitdm: Add Yandex to the domain map

[Roman Kagan]

On Sun, Oct 04, 2020 at 08:04:42PM +0200, Philippe Mathieu-Daudé wrote:
> There is a number of contributors from this domain,
> add its own entry to the gitdm domain map.
> 
> Cc: Alexey Kirillov 
> Cc: Alexey Krasikov 
> Cc: Anton Kuchin 
> Cc: Dima Stepanov 
> Cc: Evgeny Yakovlev 
> Cc: Roman Kagan 
> Cc: Yury Kotov 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> One Reviewed-by/Ack-by from someone from this domain
> should be sufficient to get this patch merged.
> ---
>  contrib/gitdm/domain-map | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index 7170ddea7a..4e6bf16e4e 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -42,3 +42,4 @@ wdc.com Western Digital
>  windriver.com   Wind River
>  xilinx.com  Xilinx
>  yadro.com   YADRO
> +yandex-team.ru  Yandex

Reviewed-by: Roman Kagan 

Thanks!
Roman.

Re: [PATCH v3 17/19] hw/arm: Automatically select the 'virt' machine on KVM

[Philippe Mathieu-Daudé]

On 10/1/20 5:05 PM, Philippe Mathieu-Daudé wrote:
> On 10/1/20 9:38 AM, Paolo Bonzini wrote:
>> On 29/09/20 22:36, Philippe Mathieu-Daudé wrote:
>>> Yes, the problem if I don't restrict to KVM, when
>>> using the Xen accelerator odd things occur
>>> (using configure --enable-xen --disable-tcg --disable-kvm):
>>>
>>> Compiling C object libqemu-i386-softmmu.fa.p/hw_cpu_a15mpcore.c.o
>>> hw/cpu/a15mpcore.c:28:10: fatal error: kvm_arm.h: No such file or directory
>>>
>>> See
>>> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Use_of_qemu-system-i386_on_ARM
>>
>> I don't understand.  Is Xen adding CONFIG_ARM_VIRT=y to
>> default-configs/i386-softmmu.mak??
> 
> No, this is when using:
> 
>  config ARM_VIRT
>  bool
> +default y
> 
> I had the understanding devices in hw/$BASEARCH would be only
> included for $ARCH, but I was wrong, any arch kconfig-include
> the devices of the other archs.
> 
> I tried the following diff which doesn't build because various
> devices in *non*-archdep folders use arch-specific Kconfig values:
> 
> -- >8 --
> diff --git a/meson.build b/meson.build
> index 9ab5d514d7..cfe19d0007 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -575,6 +575,7 @@ foreach target : target_dirs
>  if fs.is_file(target_kconfig)
>minikconf_input += [target_kconfig]
>  endif
> +minikconf_input += 'hw' / config_target['TARGET_BASE_ARCH'] / 'Kconfig'
>  config_devices_mak = configure_file(
>input: minikconf_input,
>output: config_devices_mak,
> diff --git a/hw/Kconfig b/hw/Kconfig
> index 4de1797ffd..64c120175a 100644
> --- a/hw/Kconfig
> +++ b/hw/Kconfig
> @@ -41,29 +41,29 @@ source vfio/Kconfig
>  source watchdog/Kconfig
> 
>  # arch Kconfig
> -source arm/Kconfig
> -source alpha/Kconfig
> -source avr/Kconfig
> -source cris/Kconfig
> -source hppa/Kconfig
> -source i386/Kconfig
> -source lm32/Kconfig
> -source m68k/Kconfig
> -source microblaze/Kconfig
> -source mips/Kconfig
> -source moxie/Kconfig
> -source nios2/Kconfig
> -source openrisc/Kconfig
> -source ppc/Kconfig
> -source riscv/Kconfig
> -source rx/Kconfig
> -source s390x/Kconfig
> -source sh4/Kconfig
> -source sparc/Kconfig
> -source sparc64/Kconfig
> -source tricore/Kconfig
> -source unicore32/Kconfig
> -source xtensa/Kconfig
> 
>  # Symbols used by multiple targets
>  config TEST_DEVICES
> ---

List of arch-indep Kconfig using arch-defined selectors:

hw/acpi/Kconfig:42:depends on PC
hw/intc/Kconfig:31:depends on ARM_GIC && KVM
hw/intc/Kconfig:36:depends on OPENPIC && KVM
hw/intc/Kconfig:40:depends on POWERNV || PSERIES
hw/intc/Kconfig:49:depends on XICS && KVM
hw/intc/Kconfig:60:depends on S390_FLIC && KVM
hw/mem/Kconfig:11:depends on (PC || PSERIES || ARM_VIRT)
hw/pci-bridge/Kconfig:8:default y if Q35
hw/timer/Kconfig:14:default y if PC
hw/tpm/Kconfig:18:depends on TPM && PC
hw/tpm/Kconfig:24:depends on TPM && PSERIES
hw/vfio/Kconfig:16:depends on LINUX && S390_CCW_VIRTIO
hw/vfio/Kconfig:38:depends on LINUX && S390_CCW_VIRTIO

Re: scripts/gdb: issues when loading modules after lx-symbols

[Stefano Garzarella]

On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
> On 05.10.20 10:14, Stefano Garzarella wrote:
> > On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
> >> On 01.10.20 16:31, Stefano Garzarella wrote:
> >>> Hi,
> >>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
> >>>
> >>> If the modules are already loaded, and I do 'lx-symbols', all work fine.
> >>> But, if I load a kernel module after 'lx-symbols', I had this issue:
> >>>
> >>> [ 5093.393940] invalid opcode:  [#1] SMP PTI
> >>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
> >>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
> >>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> >>> 1.13.0-2.fc32 04/01/2014
> >>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
> >>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 
> >>> c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 
> >>> cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
> >>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
> >>> [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
> >>> 4ee3
> >>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
> >>> c010a0c0
> >>> [ 5093.416349] RBP: c9563e50 R08:  R09: 
> >>> 0002
> >>> [ 5093.418044] R10: 0096 R11: 08a4 R12: 
> >>> 88807a0d1280
> >>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
> >>> c9563e70
> >>> [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
> >>> knlGS:
> >>> [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
> >>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
> >>> 00170ef0
> >>> [ 5093.435096] DR0:  DR1:  DR2: 
> >>> 
> >>> [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
> >>> 0400
> >>> [ 5093.439689] Call Trace:
> >>> [ 5093.440954]  ? load_module+0x24b6/0x27d0
> >>> [ 5093.443212]  ? __kernel_read+0xd6/0x150
> >>> [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
> >>> [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
> >>> [ 5093.449098]  do_syscall_64+0x38/0x50
> >>> [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [ 5093.456153] RIP: 0033:0x7f018f75c43d
> >>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
> >>> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 
> >>> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
> >>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
> >>> 0139
> >>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
> >>> 7f018f75c43d
> >>> [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
> >>> 0003
> >>> [ 5093.478049] RBP: 0004 R08:  R09: 
> >>> 
> >>> [ 5093.481298] R10: 0003 R11: 0246 R12: 
> >>> 
> >>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
> >>> 557e5c9775c0
> >>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel 
> >>> kvm irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa]
> >>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
> >>>
> >>> Guest kernel: Linux 5.9-rc7
> >>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
> >>> I tried with QEMU 4.2.1 and the latest master branch: same issue.
> >>>
> >>>
> >>> I did some digging, and skipping the gdb 'add-symbol-file' command in 
> >>> symbol.py
> >>> avoid the issue, but of course I don't have the symbols loaded:
> >>>
> >>> diff --git a/scripts/gdb/linux/symbols.py 
> >>> b/scripts/gdb/linux/symbols.py
> >>> index 1be9763cf8bb..eadfaa4d4907 100644
> >>> --- a/scripts/gdb/linux/symbols.py
> >>> +++ b/scripts/gdb/linux/symbols.py
> >>> @@ -129,7 +129,7 @@ lx-symbols command."""
> >>>  filename=module_file,
> >>>  addr=module_addr,
> >>>  sections=self._section_arguments(module))
> >>> -gdb.execute(cmdline, to_string=True)
> >>> +#gdb.execute(cmdline, to_string=True)
> >>>  if module_name not in self.loaded_modules:
> >>>  self.loaded_modules.append(module_name)
> >>>  else:
> >>>
> >>> I tried several modules and this happens every time after '(gdb) 
> >>> lx-symbols'.
> >>>
> >>> Do you have any hints?
> >>>
> >> I assume you are debugging a kernel inside QEMU/KVM, right?
> > 
> > Right!
> > 
> >> Does it work
> >> without -enable-kvm?
> > 
> > Yes, disabling kvm it works.
> > 
> 
> OK, there it is, still...
> What may also "work" is going down to single core.

No, I tried with single core

Re: [RFC PATCH 10/21] contrib/gitdm: Add Nuvia to the domain map

[Graeme Gregory]

On Sun, Oct 04, 2020 at 08:04:32PM +0200, Philippe Mathieu-Daudé wrote:
> There is a number of contributions from this domain,
> add its own entry to the gitdm domain map.
> 
> Cc: Graeme Gregory 
> Cc: Leif Lindholm 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Graeme Gregory 

> ---
> One Reviewed-by/Ack-by from someone from this domain
> should be sufficient to get this patch merged.
> ---
>  contrib/gitdm/domain-map | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index 39251fd97c..d7dca5efd4 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -25,6 +25,7 @@ codesourcery.com Mentor Graphics
>  microsoft.com   Microsoft
>  nokia.com   Nokia
>  nutanix.com Nutanix
> +nuviainc.comNUVIA
>  oracle.com  Oracle
>  proxmox.com Proxmox
>  redhat.com  Red Hat
> -- 
> 2.26.2
> 

Re: Emulate Rpi with QEMU fails

[Alex Bennée]

Peter Maydell  writes:

> On Sun, 4 Oct 2020 at 18:44, Alex Bennée  wrote:
>> Thomas <74cmo...@gmail.com> writes:
>> > I'm trying to emulate Rpi with QEMU.
>> > I found
>> > [url=1]this[/url]
>> > arcticle in Raspberry Pi Geek documenting the steps including persistent
>> > storage on host.
>> >
>> > However when starting the emulation with command
>> > qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -serial stdio -hda
>> > 2020-08-20-raspios-buster-armhf-lite.img -net
>> > "user,hostfwd=tcp::5022-:22" -dtb versatile-pb-buster.dtb -kernel
>> > kernel-qemu-5.4.51-buster -append "root=/dev/sda2 rootfstype=ext4 rw
>> > panic=1" -no-reboot
>>
>> Let's start with the fact you are using a versatilepb machine type with
>> a versatilepb dtb and not the rasppi model.
>
> Given the name of the kernel image, this probably actually *is*
> built for versatilepb, or it wouldn't have got as far as failing
> to mount the root partition. There seems to be a lot of confusion
> in the raspberry pi community about the difference between
> running the raspi userspace plus a for-versatilepb kernel
> versus running a full raspi setup.

Ahh your German is considerably better than mine ;-) Looking more
closely at the blog it seems to be predicated on extracting a Raspbian
kernel which at least stands a fighting chance of being a multi_config
kernel - like the buster above.

I can see why these sorts of shenanigans used to be pulled when there
where no RaspPi models although if all you want to do is run an ARM user
space what's wrong with using linux-user for this sort of thing?

> Anyway, failing to mount the rootfs and not listing any
> sda devices is not a problem with the fstab, because the system
> hasn't got as far as being able to mount the filesystem with a
> fstab on it yet. One possibility is that the kernel is
> missing the device drivers for either PCI or for the SCSI
> controller that gets plugged in to versatilepb by default.
>
> My guess at the cause is that you're trying to boot a Linux 5.something
> kernel and you've run into the issue described in this thread:
> https://lists.gnu.org/archive/html/qemu-discuss/2020-09/msg00023.html
> where the Linux 5.x sym53c8xx scsi driver is not compatible with QEMU's
> emulation of that device. If that's the case then you should see
> earlier in the kernel boot log error messages similar to the ones
> that Roger reported. The fix would be either to use an older
> kernel, or to change the QEMU commandline to use a different
> SCSI controller (or to use a virtio block device).

Do we have any documentation for the RaspPi models? The acceptance tests
look like they support the inbuilt MMC/SD controller device:

kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
   serial_kernel_cmdline[uart_id] +
   ' root=/dev/mmcblk0p2 rootwait ' +
   'dwc_otg.fiq_fsm_enable=0')

It would be useful to fill the hole in the documentation so gently steer
people away from these hybrid franken-machine approaches.

>
> thanks
> -- PMM


-- 
Alex Bennée

Re: scripts/gdb: issues when loading modules after lx-symbols

[Jan Kiszka]

On 05.10.20 11:29, Stefano Garzarella wrote:
> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
>> On 05.10.20 10:14, Stefano Garzarella wrote:
>>> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
 On 01.10.20 16:31, Stefano Garzarella wrote:
> Hi,
> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
>
> If the modules are already loaded, and I do 'lx-symbols', all work fine.
> But, if I load a kernel module after 'lx-symbols', I had this issue:
>
> [ 5093.393940] invalid opcode:  [#1] SMP PTI
> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> 1.13.0-2.fc32 04/01/2014
> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 
> c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 
> cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
> [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
> 4ee3
> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
> c010a0c0
> [ 5093.416349] RBP: c9563e50 R08:  R09: 
> 0002
> [ 5093.418044] R10: 0096 R11: 08a4 R12: 
> 88807a0d1280
> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
> c9563e70
> [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
> knlGS:
> [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
> 00170ef0
> [ 5093.435096] DR0:  DR1:  DR2: 
> 
> [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [ 5093.439689] Call Trace:
> [ 5093.440954]  ? load_module+0x24b6/0x27d0
> [ 5093.443212]  ? __kernel_read+0xd6/0x150
> [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
> [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
> [ 5093.449098]  do_syscall_64+0x38/0x50
> [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 5093.456153] RIP: 0033:0x7f018f75c43d
> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 
> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
> 0139
> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
> 7f018f75c43d
> [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
> 0003
> [ 5093.478049] RBP: 0004 R08:  R09: 
> 
> [ 5093.481298] R10: 0003 R11: 0246 R12: 
> 
> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
> 557e5c9775c0
> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel 
> kvm irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa]
> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
>
> Guest kernel: Linux 5.9-rc7
> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
> I tried with QEMU 4.2.1 and the latest master branch: same issue.
>
>
> I did some digging, and skipping the gdb 'add-symbol-file' command in 
> symbol.py
> avoid the issue, but of course I don't have the symbols loaded:
>
> diff --git a/scripts/gdb/linux/symbols.py 
> b/scripts/gdb/linux/symbols.py
> index 1be9763cf8bb..eadfaa4d4907 100644
> --- a/scripts/gdb/linux/symbols.py
> +++ b/scripts/gdb/linux/symbols.py
> @@ -129,7 +129,7 @@ lx-symbols command."""
>  filename=module_file,
>  addr=module_addr,
>  sections=self._section_arguments(module))
> -gdb.execute(cmdline, to_string=True)
> +#gdb.execute(cmdline, to_string=True)
>  if module_name not in self.loaded_modules:
>  self.loaded_modules.append(module_name)
>  else:
>
> I tried several modules and this happens every time after '(gdb) 
> lx-symbols'.
>
> Do you have any hints?
>
 I assume you are debugging a kernel inside QEMU/KVM, right?
>>>
>>> Right!
>>>
 Does it work
 without -enable-kvm?
>>>
>>> Yes, disabling kvm it works.
>>>
>>
>> OK, there it is, still...
>> What may also "work" is going down

Re: [PATCH v2] elfload: use g_new/g_malloc and g_autofree

[Peter Maydell]

On Sun, 4 Oct 2020 at 13:22, Elena Afanasova  wrote:
>
> Subject: [PATCH v2] elfload: use g_new/g_malloc and g_autofree
>
> Signed-off-by: Elena Afanasova 
> ---
>  bsd-user/elfload.c | 79 --
>  1 file changed, 14 insertions(+), 65 deletions(-)

Random question -- how are you testing this change? (bsd-user
isn't covered by 'make check' I think).

thanks
-- PMM

Re: [PATCH v3 1/6] plugins: Fixes a issue when dlsym failed, the handle not closed

[Alex Bennée]

Yonggang Luo  writes:

> Signed-off-by: Yonggang Luo 
> Reviewed-by: Philippe Mathieu-Daudé 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [PATCH v3 2/6] plugin: Fixes compiling errors on msys2/mingw

[Alex Bennée]

Yonggang Luo  writes:

> Signed-off-by: Yonggang Luo 
> Reviewed-by: Philippe Mathieu-Daudé 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [PATCH v2 2/2] hw/virtio-pci Added AER capability.

[Michael S. Tsirkin]

On Mon, Oct 05, 2020 at 12:01:40PM +0300, and...@daynix.com wrote:
> From: Andrew 
> 
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1857668
> Added AER capability for virtio-pci devices.
> Also added property for devices, by default AER is enabled.


Looking at code it's disabled by default, isn't it?

> 
> Signed-off-by: Andrew Melnychenko 
> ---
>  hw/virtio/virtio-pci.c | 16 
>  hw/virtio/virtio-pci.h |  4 
>  2 files changed, 20 insertions(+)
> 
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index ae60c1e249..e0a7936f9c 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1807,6 +1807,12 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
>   */
>  pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
>  
> +if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
> +pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
> +  PCI_ERR_SIZEOF, NULL);
> +last_pcie_cap_offset += PCI_ERR_SIZEOF;
> +}
> +
>  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
>  /* Init error enabling flags */
>  pcie_cap_deverr_init(pci_dev);
> @@ -1848,7 +1854,15 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
>  
>  static void virtio_pci_exit(PCIDevice *pci_dev)
>  {
> +VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
> +bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
> + !pci_bus_is_root(pci_get_bus(pci_dev));
> +
>  msix_uninit_exclusive_bar(pci_dev);
> +if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
> +pci_is_express(pci_dev)) {
> +pcie_aer_exit(pci_dev);
> +}
>  }
>  
>  static void virtio_pci_reset(DeviceState *qdev)
> @@ -1901,6 +1915,8 @@ static Property virtio_pci_properties[] = {
>  VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
>  DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
>  VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> +DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_AER_BIT, false),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 91096f0291..3986b4f0e3 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -45,6 +45,7 @@ enum {
>  VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
>  VIRTIO_PCI_FLAG_INIT_PM_BIT,
>  VIRTIO_PCI_FLAG_INIT_FLR_BIT,
> +VIRTIO_PCI_FLAG_AER_BIT,
>  };
>  
>  /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -84,6 +85,9 @@ enum {
>  /* Init Function Level Reset capability */
>  #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
>  
> +/* Advanced Error Reporting capability */
> +#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
> +
>  typedef struct {
>  MSIMessage msg;
>  int virq;
> -- 
> 2.28.0

Re: [PATCH v2 0/2] hw/virtio-pci: AER capability

[Michael S. Tsirkin]

On Mon, Oct 05, 2020 at 12:01:38PM +0300, and...@daynix.com wrote:
> From: Andrew Melnychenko 
> 
> Now, AER capability for virtio-pci is disabled by default.
> AER capability is only for PCI with PCIe interface on PCIe bus.
> During migration - device "realize" should initialize AER
> if requested by device properties.

Could you add motivation to individual patches please?

> Andrew (2):
>   hw/virtio-pci Added counter for pcie capabilities offsets.
>   hw/virtio-pci Added AER capability.
> 
>  hw/virtio/virtio-pci.c | 20 +++-
>  hw/virtio/virtio-pci.h |  4 
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> -- 
> 2.28.0

Re: [PATCH v3 3/6] cirrus: Enable plugin in cirrus for windows

[Alex Bennée]

Yonggang Luo  writes:

> Signed-off-by: Yonggang Luo 

If the build doesn't work until your later fixes then this should be the
last patch in the series. 

> ---
>  .cirrus.yml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 86ea33926a..5363142373 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -104,7 +104,8 @@ windows_msys2_task:
>  - C:\tools\msys64\usr\bin\bash.exe -lc "mkdir build"
>  - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && ../configure
>--python=python3 --ninja=ninja
> -  
> --target-list-exclude=i386-softmmu,arm-softmmu,ppc-softmmu,mips-softmmu"
> +  --target-list-exclude=i386-softmmu,arm-softmmu,ppc-softmmu,mips-softmmu
> +  --enable-plugins"
>  - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && make 
> -j$NUMBER_OF_PROCESSORS"
>test_script:
>  - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && make V=1 check"


-- 
Alex Bennée

Re: [PATCH v3 4/6] plugin: define QEMU_PLUGIN_API_IMPLEMENTATION first

[Alex Bennée]

Yonggang Luo  writes:

> This is used to distinguish from the qemu and plugin in
> header qemu-plugin.h
>
> Signed-off-by: Yonggang Luo 
> ---
>  plugins/api.c  | 1 +
>  plugins/core.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/plugins/api.c b/plugins/api.c
> index bbdc5a4eb4..f16922ca8b 100644
> --- a/plugins/api.c
> +++ b/plugins/api.c
> @@ -35,6 +35,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#define QEMU_PLUGIN_API_IMPLEMENTATION
>  #include "qemu/plugin.h"

This doesn't do anything in this patch. You should split the special
handling in the plugin header and combine it in this patch. Also I'm not
quite sure of the logic you are trying to achieve later on:

  #if !defined(QEMU_PLUGIN_API_IMPLEMENTATION)
  #if defined(QEMU_PLUGIN_IMPLEMENTATION)
  #define QEMU_PLUGIN_EXTERN
  #else
  #define QEMU_PLUGIN_EXTERN extern
  #endif

It seems to me you could get away with only one symbol - ideally just
defined in plugins/api.c so you don't need to churn the plugins with
changes, e.g.

  #ifdef QEMU_PLUGIN_API_IMPLEMENTATION
  #define QEMU_PLUGIN_EXTERN
  #else
  #define QEMU_PLUGIN_EXTERN extern
  #endif

But I'd still like to have a better answer as to why we need the extern?
Is this a limitation of the mingw compiler or some windows special?

>  #include "cpu.h"
>  #include "sysemu/sysemu.h"
> diff --git a/plugins/core.c b/plugins/core.c
> index 51bfc94787..7a79ea4179 100644
> --- a/plugins/core.c
> +++ b/plugins/core.c
> @@ -12,6 +12,7 @@
>   * SPDX-License-Identifier: GPL-2.0-or-later
>   */
>  #include "qemu/osdep.h"
> +#define QEMU_PLUGIN_API_IMPLEMENTATION
>  #include "qemu/error-report.h"
>  #include "qemu/config-file.h"
>  #include "qapi/error.h"

I don't think we include qemu/plugin.h from this file although it does
raise the question of what happens when other parts of QEMU include the
internal qemu/plugins.h header.

-- 
Alex Bennée

Re: [PATCH v3 5/6] plugin: getting qemu_plugin_get_hwaddr only expose one function prototype

[Alex Bennée]

Yonggang Luo  writes:

> This is used for counting how much function are export to qemu plugin.
>
> Signed-off-by: Yonggang Luo 
> ---
>  plugins/api.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/plugins/api.c b/plugins/api.c
> index f16922ca8b..d325084385 100644
> --- a/plugins/api.c
> +++ b/plugins/api.c
> @@ -252,10 +252,12 @@ bool qemu_plugin_mem_is_store(qemu_plugin_meminfo_t 
> info)
>  
>  #ifdef CONFIG_SOFTMMU
>  static __thread struct qemu_plugin_hwaddr hwaddr_info;
> +#endif
>  
>  struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
>uint64_t vaddr)
>  {
> +#ifdef CONFIG_SOFTMMU
>  CPUState *cpu = current_cpu;
>  unsigned int mmu_idx = info >> TRACE_MEM_MMU_SHIFT;
>  hwaddr_info.is_store = info & TRACE_MEM_ST;
> @@ -267,14 +269,10 @@ struct qemu_plugin_hwaddr 
> *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
>  }
>  
>  return &hwaddr_info;
> -}
>  #else
> -struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
> -  uint64_t vaddr)
> -{
>  return NULL;
> -}
>  #endif
> +}

Hmm I'm not sure about this, surely you want the plugin system to
complain early if your plugin is going to use a function that is
incorrect for the mode you are running in?

Although we do currently unconditionally export the syscall functions
and arguably they should be CONFIG_USER only as well.

>  
>  bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr)
>  {


-- 
Alex Bennée

Re: Emulate Rpi with QEMU fails

[Thomas Schneider]

Hello,

thanks for your replies.

I must admit that I don't fully understand your analysis.
However you made some conclusions that are correct.

In fact I have found a Github repo 
 where a specific kernel 
and versatile-pb are provided + instructions for lauching the emulation 
with the original RPi image file:

$ qemu-system-arm \
  -M versatilepb \
  -cpu arm1176 \
  -m 256 \
  -drive 
"file=/.../2020-05-27-raspios-buster-lite-armhf.img,if=none,index=0,media=disk,format=raw,id=disk0" 
\
  -device 
"virtio-blk-pci,drive=disk0,disable-modern=on,disable-legacy=off" \

  -net "user,hostfwd=tcp::5022-:22" \
  -dtb /.../versatile-pb-buster-5.4.51.dtb \
  -kernel /.../kernel-qemu-5.4.51-buster \
  -append 'root=/dev/vda2 panic=1' \
  -no-reboot

This means it is more recent than the Raspberry Pi Geek article, and the 
emulation works.
But I'm not sure if this usable considering the added models -M raspi2 
and -M raspi3.


Can you please advise how to proceed?

In addition I would like to know if there's a memory limitation using 
models -M raspi2 and -M raspi3?

To my understanding there's a limitation to 256MB using -M versatilepb.
If yes, I consider to another raw image located on host's temporary 
filesystem and use this a swap in the client.


And how can I make use of a client network device that is based on 
host's tap device connected to a network bridge?


THX


Am 05.10.2020 um 11:40 schrieb Alex Bennée:

Peter Maydell  writes:


On Sun, 4 Oct 2020 at 18:44, Alex Bennée  wrote:

Thomas <74cmo...@gmail.com> writes:

I'm trying to emulate Rpi with QEMU.
I found
[url=1]this[/url]
arcticle in Raspberry Pi Geek documenting the steps including persistent
storage on host.

However when starting the emulation with command
qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -serial stdio -hda
2020-08-20-raspios-buster-armhf-lite.img -net
"user,hostfwd=tcp::5022-:22" -dtb versatile-pb-buster.dtb -kernel
kernel-qemu-5.4.51-buster -append "root=/dev/sda2 rootfstype=ext4 rw
panic=1" -no-reboot

Let's start with the fact you are using a versatilepb machine type with
a versatilepb dtb and not the rasppi model.

Given the name of the kernel image, this probably actually *is*
built for versatilepb, or it wouldn't have got as far as failing
to mount the root partition. There seems to be a lot of confusion
in the raspberry pi community about the difference between
running the raspi userspace plus a for-versatilepb kernel
versus running a full raspi setup.

Ahh your German is considerably better than mine ;-) Looking more
closely at the blog it seems to be predicated on extracting a Raspbian
kernel which at least stands a fighting chance of being a multi_config
kernel - like the buster above.

I can see why these sorts of shenanigans used to be pulled when there
where no RaspPi models although if all you want to do is run an ARM user
space what's wrong with using linux-user for this sort of thing?


Anyway, failing to mount the rootfs and not listing any
sda devices is not a problem with the fstab, because the system
hasn't got as far as being able to mount the filesystem with a
fstab on it yet. One possibility is that the kernel is
missing the device drivers for either PCI or for the SCSI
controller that gets plugged in to versatilepb by default.

My guess at the cause is that you're trying to boot a Linux 5.something
kernel and you've run into the issue described in this thread:
https://lists.gnu.org/archive/html/qemu-discuss/2020-09/msg00023.html
where the Linux 5.x sym53c8xx scsi driver is not compatible with QEMU's
emulation of that device. If that's the case then you should see
earlier in the kernel boot log error messages similar to the ones
that Roger reported. The fix would be either to use an older
kernel, or to change the QEMU commandline to use a different
SCSI controller (or to use a virtio block device).

Do we have any documentation for the RaspPi models? The acceptance tests
look like they support the inbuilt MMC/SD controller device:

 kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
serial_kernel_cmdline[uart_id] +
' root=/dev/mmcblk0p2 rootwait ' +
'dwc_otg.fiq_fsm_enable=0')

It would be useful to fill the hole in the documentation so gently steer
people away from these hybrid franken-machine approaches.


thanks
-- PMM

Re: [PATCH v3 17/19] hw/arm: Automatically select the 'virt' machine on KVM

[Paolo Bonzini]

On 05/10/20 11:22, Philippe Mathieu-Daudé wrote:
> List of arch-indep Kconfig using arch-defined selectors:
> 
> hw/acpi/Kconfig:42:depends on PC
> hw/intc/Kconfig:31:depends on ARM_GIC && KVM
> hw/intc/Kconfig:36:depends on OPENPIC && KVM
> hw/intc/Kconfig:40:depends on POWERNV || PSERIES
> hw/intc/Kconfig:49:depends on XICS && KVM
> hw/intc/Kconfig:60:depends on S390_FLIC && KVM
> hw/mem/Kconfig:11:depends on (PC || PSERIES || ARM_VIRT)
> hw/pci-bridge/Kconfig:8:default y if Q35
> hw/timer/Kconfig:14:default y if PC
> hw/tpm/Kconfig:18:depends on TPM && PC
> hw/tpm/Kconfig:24:depends on TPM && PSERIES
> hw/vfio/Kconfig:16:depends on LINUX && S390_CCW_VIRTIO
> hw/vfio/Kconfig:38:depends on LINUX && S390_CCW_VIRTIO
> 

I don't think that's a problem, and also I'm not sure this patch is a
good idea.

See docs/devel/kconfig.rst: "Boards default to false; they are enabled
by the ``default-configs/*.mak`` for the target they apply to".

Paolo

[RFC PATCH 2/3] tests: Only build socket_scm_helper when a softmmu target is available

[Philippe Mathieu-Daudé]

Do not try to build socket_scm_helper if not softmmu target
is available. This fixes:

  $ make check-block
  Generating qemu-version.h with a meson_exe.py custom command
  make: *** No rule to make target 'tests/qemu-iotests/socket_scm_helper', 
needed by 'check-block'.  Stop.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/Makefile.include | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 40d909badc..d25560 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -136,7 +136,9 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) 
get-vm-images
 check:
 
 ifeq ($(CONFIG_TOOLS)$(CONFIG_POSIX),yy)
+ifneq ($(TARGET_DIRS),)
 QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = 
tests/qemu-iotests/socket_scm_helper$(EXESUF)
+endif
 check: check-block
 check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
-- 
2.26.2

[RFC PATCH 0/3] qom: Fix missing interface in qemu-storage-daemon

[Philippe Mathieu-Daudé]

Attempt to fix the issue reported by Kevin.

Introduce a trivial test, but there is currently no
framework in place to test qemu-storage-daemon.

There might be better fix to this QOM issue,
I went for the easiest one I could figure out.

Philippe Mathieu-Daudé (3):
  qom: Always register FW_CFG_DATA_GENERATOR_INTERFACE
  tests: Only build socket_scm_helper when a softmmu target is available
  tests: Add a trivial qemu-storage-daemon test

 hw/nvram/fw_cfg.c|  7 ---
 qom/fw_cfg_interface.c   | 15 +++
 MAINTAINERS  |  1 +
 qom/meson.build  |  5 +
 tests/Makefile.include   |  5 +
 tests/qemu-storage-daemon.sh | 10 ++
 6 files changed, 36 insertions(+), 7 deletions(-)
 create mode 100644 qom/fw_cfg_interface.c
 create mode 100755 tests/qemu-storage-daemon.sh

-- 
2.26.2

[RFC PATCH 1/3] qom: Always register FW_CFG_DATA_GENERATOR_INTERFACE

[Philippe Mathieu-Daudé]

While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed
by a device only available using system-mode (fw_cfg), it is
implemented by a crypto component (tls-cipher-suites) which
is always available when crypto is used.

Commit 69699f3055 introduced the following error in the
qemu-storage-daemon binary:

  $ echo -e \
'{"execute": "qmp_capabilities"}\r\n{"execute": 
"qom-list-types"}\r\n{"execute": "quit"}\r\n' \
| storage-daemon/qemu-storage-daemon --chardev stdio,id=qmp0  --monitor qmp0
  {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 5}, 
"package": ""}, "capabilities": ["oob"]}}
  {"return": {}}
  missing interface 'fw_cfg-data-generator' for object 'tls-creds'
  Aborted (core dumped)

Since QOM dependencies are resolved at runtime, this issue
could not be triggered at linktime, and we don't have test
running the qemu-storage-daemon binary.

Fix by always registering the QOM interface.

Reported-by: Kevin Wolf 
Fixes: 69699f3055 ("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
Signed-off-by: Philippe Mathieu-Daudé 
---
I first used:

+if config_host.has_key('CONFIG_GNUTLS') or have_system
+  qom_ss.add(files('fw_cfg_interface.c'))
+endif

but then realized anything could implement a QOM interface,
so better keep this generic.
---
 hw/nvram/fw_cfg.c  |  7 ---
 qom/fw_cfg_interface.c | 15 +++
 MAINTAINERS|  1 +
 qom/meson.build|  5 +
 4 files changed, 21 insertions(+), 7 deletions(-)
 create mode 100644 qom/fw_cfg_interface.c

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 0e95d057fd..08539a1aab 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -1360,18 +1360,11 @@ static const TypeInfo fw_cfg_mem_info = {
 .class_init= fw_cfg_mem_class_init,
 };
 
-static const TypeInfo fw_cfg_data_generator_interface_info = {
-.parent = TYPE_INTERFACE,
-.name = TYPE_FW_CFG_DATA_GENERATOR_INTERFACE,
-.class_size = sizeof(FWCfgDataGeneratorClass),
-};
-
 static void fw_cfg_register_types(void)
 {
 type_register_static(&fw_cfg_info);
 type_register_static(&fw_cfg_io_info);
 type_register_static(&fw_cfg_mem_info);
-type_register_static(&fw_cfg_data_generator_interface_info);
 }
 
 type_init(fw_cfg_register_types)
diff --git a/qom/fw_cfg_interface.c b/qom/fw_cfg_interface.c
new file mode 100644
index 00..2b19502ffe
--- /dev/null
+++ b/qom/fw_cfg_interface.c
@@ -0,0 +1,15 @@
+#include "qemu/osdep.h"
+#include "hw/nvram/fw_cfg.h"
+
+static const TypeInfo fw_cfg_data_generator_interface_info = {
+.parent = TYPE_INTERFACE,
+.name = TYPE_FW_CFG_DATA_GENERATOR_INTERFACE,
+.class_size = sizeof(FWCfgDataGeneratorClass),
+};
+
+static void fw_cfg_register_types(void)
+{
+type_register_static(&fw_cfg_data_generator_interface_info);
+}
+
+type_init(fw_cfg_register_types)
diff --git a/MAINTAINERS b/MAINTAINERS
index b76fb31861..9c89d54b41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2055,6 +2055,7 @@ R: Gerd Hoffmann 
 S: Supported
 F: docs/specs/fw_cfg.txt
 F: hw/nvram/fw_cfg.c
+F: qom/fw_cfg_interface.c
 F: stubs/fw_cfg.c
 F: include/hw/nvram/fw_cfg.h
 F: include/standard-headers/linux/qemu_fw_cfg.h
diff --git a/qom/meson.build b/qom/meson.build
index a1cd03c82c..7335f8c8a2 100644
--- a/qom/meson.build
+++ b/qom/meson.build
@@ -7,6 +7,11 @@ qom_ss.add(files(
   'qom-qobject.c',
 ))
 
+# interfaces any object might implement
+qom_ss.add(files(
+  'fw_cfg_interface.c',
+))
+
 qmp_ss.add(files('qom-qmp-cmds.c'))
 softmmu_ss.add(files('qom-hmp-cmds.c'))
 
-- 
2.26.2

Re: [PATCH 0/5] qapi: Restrict machine (and migration) specific commands

[Markus Armbruster]

Paolo Bonzini  writes:

> On 05/10/20 10:01, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé  writes:
>> 
>>> Reduce the machine code pulled into qemu-storage-daemon.
>> I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
>> Juan for PATCH 5.  David already ACKed.
>> 
>> Can do the pull request.
>> 
>
> If it counts, :) for patch 1-4:
>
> Acked-by: Paolo Bonzini 
>
> Generally these patches to remove code from user-mode emulators
> fall into the "if it builds it's fine" bucket, since I assume
> we want the "misc" subschema to be as small as possible.

Moving stuff out of qapi/misc.json is good as long as the new home makes
sense.  So, if it builds *and* the maintainers of the new home think it
makes sense to have it there, it's fine.

I don't think we should aim for eliminating every last bit of unused
generated code from every program.  We should aim for a sensible split
into sub-modules.  Unused generated code in a program can be a sign for
a less than sensible split.

[RFC PATCH 3/3] tests: Add a trivial qemu-storage-daemon test

[Philippe Mathieu-Daudé]

This test fails on top of commit 69699f3055
("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
because the TYPE_FW_CFG_DATA_GENERATOR_INTERFACE registered
in hw/nvram/fw_cfg.c is not linked into qemu-storage-daemon:

  $ make check-block
  Generating qemu-version.h with a meson_exe.py custom command
qemu-storage-daemon
  tests/qemu-storage-daemon.sh: line 10: 2089929 Aborted (core 
dumped)

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/Makefile.include   |  3 +++
 tests/qemu-storage-daemon.sh | 10 ++
 2 files changed, 13 insertions(+)
 create mode 100755 tests/qemu-storage-daemon.sh

diff --git a/tests/Makefile.include b/tests/Makefile.include
index d25560..be12581c77 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -142,7 +142,10 @@ endif
 check: check-block
 check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
+   storage-daemon/qemu-storage-daemon \
$(patsubst %-softmmu,qemu-system-%,$(filter 
%-softmmu,$(TARGET_DIRS)))
+   $(call quiet-command, \
+   $(SRC_PATH)/tests/qemu-storage-daemon.sh, 
"qemu-storage-daemon")
@$<
 endif
 
diff --git a/tests/qemu-storage-daemon.sh b/tests/qemu-storage-daemon.sh
new file mode 100755
index 00..9fd4c73400
--- /dev/null
+++ b/tests/qemu-storage-daemon.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+# Test all QOM dependencies are resolved
+storage-daemon/qemu-storage-daemon \
+  --chardev stdio,id=qmp0  --monitor qmp0 \
+  > /dev/null << 'EOF'
+{"execute": "qmp_capabilities"}
+{"execute": "qom-list-types"}
+{"execute": "quit"}
+EOF
-- 
2.26.2

Re: [RFC PATCH 0/3] qom: Fix missing interface in qemu-storage-daemon

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20201005105442.2093105-1-phi...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
if qemu-system-x86_64 --help >/dev/null 2>&1; then
  QEMU=qemu-system-x86_64
elif /usr/libexec/qemu-kvm --help >/dev/null 2>&1; then
  QEMU=/usr/libexec/qemu-kvm
else
  exit 1
fi
make vm-build-freebsd J=21 QEMU=$QEMU
exit 0
=== TEST SCRIPT END ===




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

Re: [PATCH v2 2/2] hw/virtio-pci Added AER capability.

[Andrew Melnichenko]

yes

> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_AER_BIT, *false*),
>

On Mon, Oct 5, 2020 at 1:08 PM Michael S. Tsirkin  wrote:

> On Mon, Oct 05, 2020 at 12:01:40PM +0300, and...@daynix.com wrote:
> > From: Andrew 
> >
> > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1857668
> > Added AER capability for virtio-pci devices.
> > Also added property for devices, by default AER is enabled.
>
>
> Looking at code it's disabled by default, isn't it?
>
> >
> > Signed-off-by: Andrew Melnychenko 
> > ---
> >  hw/virtio/virtio-pci.c | 16 
> >  hw/virtio/virtio-pci.h |  4 
> >  2 files changed, 20 insertions(+)
> >
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index ae60c1e249..e0a7936f9c 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
> > @@ -1807,6 +1807,12 @@ static void virtio_pci_realize(PCIDevice
> *pci_dev, Error **errp)
> >   */
> >  pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
> >
> > +if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
> > +pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
> > +  PCI_ERR_SIZEOF, NULL);
> > +last_pcie_cap_offset += PCI_ERR_SIZEOF;
> > +}
> > +
> >  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
> >  /* Init error enabling flags */
> >  pcie_cap_deverr_init(pci_dev);
> > @@ -1848,7 +1854,15 @@ static void virtio_pci_realize(PCIDevice
> *pci_dev, Error **errp)
> >
> >  static void virtio_pci_exit(PCIDevice *pci_dev)
> >  {
> > +VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
> > +bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
> > + !pci_bus_is_root(pci_get_bus(pci_dev));
> > +
> >  msix_uninit_exclusive_bar(pci_dev);
> > +if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
> > +pci_is_express(pci_dev)) {
> > +pcie_aer_exit(pci_dev);
> > +}
> >  }
> >
> >  static void virtio_pci_reset(DeviceState *qdev)
> > @@ -1901,6 +1915,8 @@ static Property virtio_pci_properties[] = {
> >  VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> >  DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> >  VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> > +DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> > +VIRTIO_PCI_FLAG_AER_BIT, false),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >
> > diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> > index 91096f0291..3986b4f0e3 100644
> > --- a/hw/virtio/virtio-pci.h
> > +++ b/hw/virtio/virtio-pci.h
> > @@ -45,6 +45,7 @@ enum {
> >  VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
> >  VIRTIO_PCI_FLAG_INIT_PM_BIT,
> >  VIRTIO_PCI_FLAG_INIT_FLR_BIT,
> > +VIRTIO_PCI_FLAG_AER_BIT,
> >  };
> >
> >  /* Need to activate work-arounds for buggy guests at vmstate load. */
> > @@ -84,6 +85,9 @@ enum {
> >  /* Init Function Level Reset capability */
> >  #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
> >
> > +/* Advanced Error Reporting capability */
> > +#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
> > +
> >  typedef struct {
> >  MSIMessage msg;
> >  int virq;
> > --
> > 2.28.0
>
>

Re: scripts/gdb: issues when loading modules after lx-symbols

[Stefano Garzarella]

On Mon, Oct 05, 2020 at 11:45:41AM +0200, Jan Kiszka wrote:
> On 05.10.20 11:29, Stefano Garzarella wrote:
> > On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
> >> On 05.10.20 10:14, Stefano Garzarella wrote:
> >>> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
>  On 01.10.20 16:31, Stefano Garzarella wrote:
> > Hi,
> > I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
> >
> > If the modules are already loaded, and I do 'lx-symbols', all work fine.
> > But, if I load a kernel module after 'lx-symbols', I had this issue:
> >
> > [ 5093.393940] invalid opcode:  [#1] SMP PTI
> > [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
> > 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
> > [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > 1.13.0-2.fc32 04/01/2014
> > [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
> > [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 
> > c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 
> > cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
> > [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
> > [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
> > 4ee3
> > [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
> > c010a0c0
> > [ 5093.416349] RBP: c9563e50 R08:  R09: 
> > 0002
> > [ 5093.418044] R10: 0096 R11: 08a4 R12: 
> > 88807a0d1280
> > [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
> > c9563e70
> > [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
> > knlGS:
> > [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
> > [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
> > 00170ef0
> > [ 5093.435096] DR0:  DR1:  DR2: 
> > 
> > [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
> > 0400
> > [ 5093.439689] Call Trace:
> > [ 5093.440954]  ? load_module+0x24b6/0x27d0
> > [ 5093.443212]  ? __kernel_read+0xd6/0x150
> > [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
> > [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
> > [ 5093.449098]  do_syscall_64+0x38/0x50
> > [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 5093.456153] RIP: 0033:0x7f018f75c43d
> > [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
> > 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 
> > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
> > [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
> > 0139
> > [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
> > 7f018f75c43d
> > [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
> > 0003
> > [ 5093.478049] RBP: 0004 R08:  R09: 
> > 
> > [ 5093.481298] R10: 0003 R11: 0246 R12: 
> > 
> > [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
> > 557e5c9775c0
> > [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel 
> > kvm irqbypass virtio_blk virtio_rng rng_core [last unloaded: 
> > virtio_vdpa]
> > [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
> >
> > Guest kernel: Linux 5.9-rc7
> > gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
> > I tried with QEMU 4.2.1 and the latest master branch: same issue.
> >
> >
> > I did some digging, and skipping the gdb 'add-symbol-file' command in 
> > symbol.py
> > avoid the issue, but of course I don't have the symbols loaded:
> >
> > diff --git a/scripts/gdb/linux/symbols.py 
> > b/scripts/gdb/linux/symbols.py
> > index 1be9763cf8bb..eadfaa4d4907 100644
> > --- a/scripts/gdb/linux/symbols.py
> > +++ b/scripts/gdb/linux/symbols.py
> > @@ -129,7 +129,7 @@ lx-symbols command."""
> >  filename=module_file,
> >  addr=module_addr,
> >  sections=self._section_arguments(module))
> > -gdb.execute(cmdline, to_string=True)
> > +#gdb.execute(cmdline, to_string=True)
> >  if module_name not in self.loaded_modules:
> >  self.loaded_modules.append(module_name)
> >  else:
> >
> > I tried several modules and this happens every time after '(gdb) 
> > lx-symbols'.
> >
> > Do you have any hints?
> >
>  I assume you are debugging a k

[PATCH v3 0/2] hw/virtio-pci: AER capability

[andrew]

From: Andrew Melnychenko 

Now, AER capability for virtio-pci is disabled by default.
AER capability is only for PCI with PCIe interface on PCIe bus.
During migration - device "realize" should initialize AER
if requested by device properties.
Also fixed commit message and added proper link to bugzilla.

Andrew (2):
  hw/virtio-pci Added counter for pcie capabilities offsets.
  hw/virtio-pci Added AER capability.

 hw/virtio/virtio-pci.c | 20 +++-
 hw/virtio/virtio-pci.h |  4 
 2 files changed, 23 insertions(+), 1 deletion(-)

-- 
2.28.0

[PATCH v3 1/2] hw/virtio-pci Added counter for pcie capabilities offsets.

[andrew]

From: Andrew 

Removed hardcoded offset for ats. Added cap offset counter
for future capabilities like AER.

Signed-off-by: Andrew Melnychenko 
---
 hw/virtio/virtio-pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 5bc769f685..ae60c1e249 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1788,6 +1788,7 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 
 if (pcie_port && pci_is_express(pci_dev)) {
 int pos;
+uint16_t last_pcie_cap_offset = PCI_CONFIG_SPACE_SIZE;
 
 pos = pcie_endpoint_cap_init(pci_dev, 0);
 assert(pos > 0);
@@ -1823,7 +1824,8 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 }
 
 if (proxy->flags & VIRTIO_PCI_FLAG_ATS) {
-pcie_ats_init(pci_dev, 256);
+pcie_ats_init(pci_dev, last_pcie_cap_offset);
+last_pcie_cap_offset += PCI_EXT_CAP_ATS_SIZEOF;
 }
 
 if (proxy->flags & VIRTIO_PCI_FLAG_INIT_FLR) {
-- 
2.28.0

Re: [PATCH v5 06/14] hw/block/nvme: Add support for active/inactive namespaces

[Niklas Cassel]

On Sun, Oct 04, 2020 at 11:54:13PM +, Dmitry Fomichev wrote:
> On Wed, 2020-09-30 at 13:50 +, Niklas Cassel wrote:
> > On Mon, Sep 28, 2020 at 11:35:20AM +0900, Dmitry Fomichev wrote:
> > > From: Niklas Cassel 
> > > 
> > > In NVMe, a namespace is active if it exists and is attached to the
> > > controller.
> > > 
> > > CAP.CSS (together with the I/O Command Set data structure) defines what
> > > command sets are supported by the controller.
> > > 
> > > CC.CSS (together with Set Profile) can be set to enable a subset of the
> > > available command sets. The namespaces belonging to a disabled command set
> > > will not be able to attach to the controller, and will thus be inactive.
> > > 
> > > E.g., if the user sets CC.CSS to Admin Only, NVM namespaces should be
> > > marked as inactive.
> > > 
> > > The identify namespace, the identify namespace CSI specific, and the 
> > > namespace
> > > list commands have two different versions, one that only shows active
> > > namespaces, and the other version that shows existing namespaces, 
> > > regardless
> > > of whether the namespace is attached or not.
> > > 
> > > Add an attached member to struct NvmeNamespace, and implement the missing 
> > > CNS
> > > commands.
> > > 
> > > The added functionality will also simplify the implementation of namespace
> > > management in the future, since namespace management can also attach and
> > > detach namespaces.
> > 
> > Following my previous discussion with Klaus,
> > I think we need to rewrite this commit message completely:
> > 
> > Subject: hw/block/nvme: Add support for allocated CNS command variants
> > 
> > Many CNS commands have "allocated" command variants.
> > These includes a namespace as long as it is allocated
> > (i.e. a namespace is included regardless if it is active (attached)
> > or not.)
> > 
> > While these commands are optional (they are mandatory for controllers
> > supporting the namespace attachment command), our QEMU implementation
> > is more complete by actually providing support for these CNS values.
> > 
> > However, since our QEMU model currently does not support the namespace
> > attachment command, these new allocated CNS commands will return the same
> > result as the active CNS command variants.
> > 
> > In NVMe, a namespace is active if it exists and is attached to the
> > controller.
> > 
> > CAP.CSS (together with the I/O Command Set data structure) defines what
> > command sets are supported by the controller.
> > 
> > CC.CSS (together with Set Profile) can be set to enable a subset of the
> > available command sets.
> > 
> > Even if a user configures CC.CSS to e.g. Admin only, NVM namespaces
> > will still be attached (and thus marked as active).
> > Similarly, if a user configures CC.CSS to e.g. NVM, ZNS namespaces
> > will still be attached (and thus marked as active).
> > 
> > However, any operation from a disabled command set will result in a
> > Invalid Command Opcode.
> > 
> > Add an attached struct member for struct NvmeNamespace,
> > so that we lay the foundation for namespace attachment
> > support. Also implement logic in the new CNS values to
> > include/exclude namespaces based on this new struct member.
> > The only thing missing hooking up the actual Namespace Attachment
> > command opcode, which allows a user to toggle the attached
> > variable per namespace. The reason for not hooking up this
> > command completely is because the NVMe specification
> > requires that the namespace managment command is supported
> > if the namespacement attachment command is supported.
> > 
> 

(snip)

> > > @@ -2276,6 +2304,22 @@ static int nvme_start_ctrl(NvmeCtrl *n)
> > >  nvme_init_sq(&n->admin_sq, n, n->bar.asq, 0, 0,
> > >   NVME_AQA_ASQS(n->bar.aqa) + 1);
> > >  
> > > +for (i = 1; i <= n->num_namespaces; i++) {
> > > +ns = nvme_ns(n, i);
> > > +if (!ns) {
> > > +continue;
> > > +}
> > > +ns->params.attached = false;
> > > +switch (ns->params.csi) {
> > > +case NVME_CSI_NVM:
> > > +if (NVME_CC_CSS(n->bar.cc) == CSS_NVM_ONLY ||
> > > +NVME_CC_CSS(n->bar.cc) == CSS_CSI) {
> > > +ns->params.attached = true;
> > > +}
> > > +break;
> > > +}
> > > +}
> > > +
> > 
> > Considering that the controller doesn't attach/detach
> > namespaces belonging to command sets that it doesn't
> > support, I think a nicer way is to remove this for-loop,
> > and instead, in nvme_ns_setup() or nvme_ns_init(),
> > always set attached = true. (Since we currently don't
> > support namespace attachment command).
> > 
> > The person that implements the last piece of namespace
> > management and namespace attachment will have to deal
> > with reading "attached" from some kind of persistent state
> 
> 
> I did some spec reading on this topic and it seems that
> this logic is necessary precisely because there is no
> attach/detach command av

[PATCH v3 2/2] hw/virtio-pci Added AER capability.

[andrew]

From: Andrew 

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1878465
Added AER capability for virtio-pci devices.
Also added property for devices, by default AER is disabled.

Signed-off-by: Andrew Melnychenko 
---
 hw/virtio/virtio-pci.c | 16 
 hw/virtio/virtio-pci.h |  4 
 2 files changed, 20 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index ae60c1e249..e0a7936f9c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1807,6 +1807,12 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
  */
 pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
 
+if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
+pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
+  PCI_ERR_SIZEOF, NULL);
+last_pcie_cap_offset += PCI_ERR_SIZEOF;
+}
+
 if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
 /* Init error enabling flags */
 pcie_cap_deverr_init(pci_dev);
@@ -1848,7 +1854,15 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 
 static void virtio_pci_exit(PCIDevice *pci_dev)
 {
+VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
+bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
+ !pci_bus_is_root(pci_get_bus(pci_dev));
+
 msix_uninit_exclusive_bar(pci_dev);
+if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
+pci_is_express(pci_dev)) {
+pcie_aer_exit(pci_dev);
+}
 }
 
 static void virtio_pci_reset(DeviceState *qdev)
@@ -1901,6 +1915,8 @@ static Property virtio_pci_properties[] = {
 VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
 DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
+DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_AER_BIT, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 91096f0291..3986b4f0e3 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -45,6 +45,7 @@ enum {
 VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
 VIRTIO_PCI_FLAG_INIT_PM_BIT,
 VIRTIO_PCI_FLAG_INIT_FLR_BIT,
+VIRTIO_PCI_FLAG_AER_BIT,
 };
 
 /* Need to activate work-arounds for buggy guests at vmstate load. */
@@ -84,6 +85,9 @@ enum {
 /* Init Function Level Reset capability */
 #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
 
+/* Advanced Error Reporting capability */
+#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
+
 typedef struct {
 MSIMessage msg;
 int virq;
-- 
2.28.0

Re: [PATCH v5 10/10] migration: introduce snapshot-{save, load, delete} QMP commands

[Daniel P . Berrangé]

On Mon, Oct 05, 2020 at 09:26:54AM +0200, Markus Armbruster wrote:
> Eric Blake  writes:
> 
> > On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
> >
> > Do we have a query- command handy to easily learn which snapshot names
> > are even available to attempt deletion on?  If not, that's worth a
> > separate patch.
> 
> Oh, I missed that one.  It's the QMP equivalent to "info snapshots", and
> it is required to finish the job.  Since we're at v5, I'd be okay with a
> follow-up patch, as long as it is done for 5.2.

"query-named-block-nodes" returns BlockDeviceInfo struct, which
contains ImageInfo which contains an array of SnapshotInfo. So
we don't need any new query command.


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 v5 10/10] migration: introduce snapshot-{save,load,delete} QMP commands

[Daniel P . Berrangé]

On Fri, Oct 02, 2020 at 02:46:07PM -0500, Eric Blake wrote:
> On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
> > savevm, loadvm and delvm are some of the few HMP commands that have never
> > been converted to use QMP. The reasons for the lack of conversion are
> > that they blocked execution of the event thread, and the semantics
> > around choice of disks were ill-defined.
> > 
> > Despite this downside, however, libvirt and applications using libvirt
> > have used these commands for as long as QMP has existed, via the
> > "human-monitor-command" passthrough command. IOW, while it is clearly
> > desirable to be able to fix the problems, they are not a blocker to
> > all real world usage.
> > 
> > Meanwhile there is a need for other features which involve adding new
> > parameters to the commands. This is possible with HMP passthrough, but
> > it provides no reliable way for apps to introspect features, so using
> > QAPI modelling is highly desirable.
> > 
> > This patch thus introduces new snapshot-{load,save,delete} commands to
> > QMP that are intended to replace the old HMP counterparts. The new
> > commands are given different names, because they will be using the new
> > QEMU job framework and thus will have diverging behaviour from the HMP
> > originals. It would thus be misleading to keep the same name.
> > 
> > While this design uses the generic job framework, the current impl is
> > still blocking. The intention that the blocking problem is fixed later.
> > None the less applications using these new commands should assume that
> > they are asynchronous and thus wait for the job status change event to
> > indicate completion.
> > 
> > In addition to using the job framework, the new commands require the
> > caller to be explicit about all the block device nodes used in the
> > snapshot operations, with no built-in default heuristics in use.
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---

> > +++ b/tests/qemu-iotests/group
> > @@ -291,6 +291,7 @@
> >  277 rw quick
> >  279 rw backing quick
> >  280 rw migration quick
> > +310 rw quick
> >  281 rw quick
> >  282 rw img quick
> >  283 auto quick
> 
> What's wrong with sorted order? I get the renumbering to appease a merge
> conflict, but it also requires rearrangement ;)

This file is a conflict magnet when rebasing to git master if you just
append to the end of it. So I picked a number many bigger than current
max, and stuffed the new entry in the middle to avoid rebase conflicts.



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 v5 09/14] hw/block/nvme: Support Zoned Namespace Command Set

[Niklas Cassel]

On Sun, Oct 04, 2020 at 11:57:07PM +, Dmitry Fomichev wrote:
> On Wed, 2020-09-30 at 14:50 +, Niklas Cassel wrote:
> > On Mon, Sep 28, 2020 at 11:35:23AM +0900, Dmitry Fomichev wrote:
> > > The emulation code has been changed to advertise NVM Command Set when
> > > "zoned" device property is not set (default) and Zoned Namespace
> > > Command Set otherwise.
> > > 
> > > Handlers for three new NVMe commands introduced in Zoned Namespace
> > > Command Set specification are added, namely for Zone Management
> > > Receive, Zone Management Send and Zone Append.
> > > 
> > > Device initialization code has been extended to create a proper
> > > configuration for zoned operation using device properties.
> > > 
> > > Read/Write command handler is modified to only allow writes at the
> > > write pointer if the namespace is zoned. For Zone Append command,
> > > writes implicitly happen at the write pointer and the starting write
> > > pointer value is returned as the result of the command. Write Zeroes
> > > handler is modified to add zoned checks that are identical to those
> > > done as a part of Write flow.
> > > 
> > > The code to support for Zone Descriptor Extensions is not included in
> > > this commit and ZDES 0 is always reported. A later commit in this
> > > series will add ZDE support.
> > > 
> > > This commit doesn't yet include checks for active and open zone
> > > limits. It is assumed that there are no limits on either active or
> > > open zones.
> > > 
> > > Signed-off-by: Niklas Cassel 
> > > Signed-off-by: Hans Holmberg 
> > > Signed-off-by: Ajay Joshi 
> > > Signed-off-by: Chaitanya Kulkarni 
> > > Signed-off-by: Matias Bjorling 
> > > Signed-off-by: Aravind Ramesh 
> > > Signed-off-by: Shin'ichiro Kawasaki 
> > > Signed-off-by: Adam Manzanares 
> > > Signed-off-by: Dmitry Fomichev 
> > > ---
> > >  block/nvme.c |   2 +-
> > >  hw/block/nvme-ns.c   | 185 -
> > >  hw/block/nvme-ns.h   |   6 +-
> > >  hw/block/nvme.c  | 872 +--
> > >  include/block/nvme.h |   6 +-
> > >  5 files changed, 1033 insertions(+), 38 deletions(-)
> > > 
> > > diff --git a/block/nvme.c b/block/nvme.c
> > > index 05485fdd11..7a513c9a17 100644
> > > --- a/block/nvme.c
> > > +++ b/block/nvme.c

(snip)

> > 
> > Please read my comment on nvme_identify_nslist_csi() before reading
> > this comment.
> > 
> > At least for this function, the specification is clear:
> > 
> > "If the host requests a data structure for an I/O Command Set that the
> > controller does not support, the controller shall abort the command with
> > a status of Invalid Field in Command."
> > 
> > If the controller supports the I/O command set == if the Command Set bit
> > is set in the data struct returned by the nvme_identify_cmd_set(),
> > so here we should do something like:
> > 
> > } else if (->csi == NVME_CSI_ZONED && ctrl_has_zns_namespaces()) {
> > ...
> > }
> > 
> 
> With this commit, the controller supports ZNS command set regardless of
> the number of attached ZNS namespaces. It could be zero, but the controller
> still supports it. I think it would be better not to change the behavior
> of this command to depend on whether there are any ZNS namespaces added
> or not.

Ok, always having ZNS Command Set support, regardless if a user defines
a zoned namespace on the QEMU command line or not, does simplify things.

But then in nvme_identify_cmd_set(), you need to call
NVME_SET_CSI(*list, NVME_CSI_ZONED) unconditionally.

(Right now you loop though all namespaces, and only set the support bit
if you find a zoned namespace.)

> > Like I wrote in my review comment in the patch that added support for the 
> > new
> > allocated CNS values, I prefer if we remove this for-loop completely, and
> > simply set attached = true in nvme_ns_setup()/nvme_ns_init() instead.
> > 
> > (I was considering if we should set attach = true in nvme_zoned_init_ns(),
> > but because nvme_ns_setup()/nvme_ns_init() is called for all namespaces,
> > including ZNS namespaces, I don't think that any additional code in
> > nvme_zoned_init_ns() is warranted.)
> 
> I think CC.CSS value is not available during namespace setup and if we
> assign active flag in nvme_zoned_ns_setup(), zoned namespaces may end up
> being active even if NVM Only command set is selected. So keeping this loop
> seems like a good idea.

It is true that CC.CSS is not yet available during namespace setup,
but since the controller itself will never detach namespaces based on
CC.CSS, why are we dependant on CC.CSS being available?

Sure, once someone implements namespace management, they will need
to read if a certain namespace is attached or detached from some
persistent state, perhaps in the zone meta-data file, and set
attached boolean in nvme_ns_init() accordingly, but I still don't see
any dependance on CC.CSS even when namespace management is implemented.



Kind regards,
Niklas

Re: scripts/gdb: issues when loading modules after lx-symbols

[Jan Kiszka]

On 05.10.20 13:05, Stefano Garzarella wrote:
> On Mon, Oct 05, 2020 at 11:45:41AM +0200, Jan Kiszka wrote:
>> On 05.10.20 11:29, Stefano Garzarella wrote:
>>> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
 On 05.10.20 10:14, Stefano Garzarella wrote:
> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
>> On 01.10.20 16:31, Stefano Garzarella wrote:
>>> Hi,
>>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
>>>
>>> If the modules are already loaded, and I do 'lx-symbols', all work fine.
>>> But, if I load a kernel module after 'lx-symbols', I had this issue:
>>>
>>> [ 5093.393940] invalid opcode:  [#1] SMP PTI
>>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
>>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
>>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
>>> 1.13.0-2.fc32 04/01/2014
>>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
>>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 
>>> c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 
>>> cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55
>>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
>>> [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
>>> 4ee3
>>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
>>> c010a0c0
>>> [ 5093.416349] RBP: c9563e50 R08:  R09: 
>>> 0002
>>> [ 5093.418044] R10: 0096 R11: 08a4 R12: 
>>> 88807a0d1280
>>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
>>> c9563e70
>>> [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
>>> knlGS:
>>> [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
>>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
>>> 00170ef0
>>> [ 5093.435096] DR0:  DR1:  DR2: 
>>> 
>>> [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
>>> 0400
>>> [ 5093.439689] Call Trace:
>>> [ 5093.440954]  ? load_module+0x24b6/0x27d0
>>> [ 5093.443212]  ? __kernel_read+0xd6/0x150
>>> [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
>>> [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
>>> [ 5093.449098]  do_syscall_64+0x38/0x50
>>> [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [ 5093.456153] RIP: 0033:0x7f018f75c43d
>>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
>>> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 
>>> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48
>>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
>>> 0139
>>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
>>> 7f018f75c43d
>>> [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
>>> 0003
>>> [ 5093.478049] RBP: 0004 R08:  R09: 
>>> 
>>> [ 5093.481298] R10: 0003 R11: 0246 R12: 
>>> 
>>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
>>> 557e5c9775c0
>>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel 
>>> kvm irqbypass virtio_blk virtio_rng rng_core [last unloaded: 
>>> virtio_vdpa]
>>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
>>>
>>> Guest kernel: Linux 5.9-rc7
>>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
>>> I tried with QEMU 4.2.1 and the latest master branch: same issue.
>>>
>>>
>>> I did some digging, and skipping the gdb 'add-symbol-file' command in 
>>> symbol.py
>>> avoid the issue, but of course I don't have the symbols loaded:
>>>
>>> diff --git a/scripts/gdb/linux/symbols.py 
>>> b/scripts/gdb/linux/symbols.py
>>> index 1be9763cf8bb..eadfaa4d4907 100644
>>> --- a/scripts/gdb/linux/symbols.py
>>> +++ b/scripts/gdb/linux/symbols.py
>>> @@ -129,7 +129,7 @@ lx-symbols command."""
>>>  filename=module_file,
>>>  addr=module_addr,
>>>  sections=self._section_arguments(module))
>>> -gdb.execute(cmdline, to_string=True)
>>> +#gdb.execute(cmdline, to_string=True)
>>>  if module_name not in self.loaded_modules:
>>>  self.loaded_modules.append(module_name)
>>>  else:
>>>
>>> I tried several modules and this happens every time after '(gdb) 
>>> lx-symbols'.
>>>
>>> Do you have any hint

Re: [PULL v3 00/11] capstone + disassembler patch queue

[Peter Maydell]

On Sat, 3 Oct 2020 at 10:38, Richard Henderson
 wrote:
>
> Version 3 adds the method: to the dependency(), which avoids the
> cmake warning, and also matches the bulk of the other dependency()
> invocations throughout meson.build.
>
> I also added the suggested current_source_dir() out of an abundance
> of caution, even though it works for me either way.
>
>
> r~
>
>
> The following changes since commit dd8c1e808f1ca311e1f50bff218c3ee3198b1f02:
>
>   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201002' into 
> staging (2020-10-02 14:29:49 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/rth7680/qemu.git tags/pull-cap-20201003
>
> for you to fetch changes up to c6d3da962f058bca09b25f99da35436816fb6de8:
>
>   disas/capstone: Add skipdata hook for s390x (2020-10-03 04:25:14 -0500)
>
> 
> Update capstone submodule from v3.0.5 to v5 ("next").
> Convert submodule build to meson.
> Enable capstone disassembly for s390x.
> Code cleanups in disas.c
>

Applied, thanks.

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

-- PMM

Re: [PATCH v2 1/4] keyval: Parse help options

[Markus Armbruster]

Markus Armbruster  writes:

[...]
> Making help support opt-in complicates things.  Is there a genuine use
> for not supporting help?  Or is just to keep the users that don't
> support help yet (but should) working without change?  Mind, I'm not
> asking you to make them work, I'm only asking whether you can think of a
> genuine case where help should not work.
>
> What are the existing users that don't support help?  Let's see... many
> in tests/test-keyval.c (ignore), and qobject_input_visitor_new_str().
> That one's used for qemu-system-FOO -audiodev, -display, -blockdev, and
> for qemu-storage-daemon --blockdev, --export, --monitor, --nbd-server.
>
> Attempting to get help for them fails like this:
>
> $ bld-x86/storage-daemon/qemu-storage-daemon --blockdev help
> qemu-storage-daemon: Invalid parameter 'help'
> $ bld-x86/storage-daemon/qemu-storage-daemon --blockdev file,help
> qemu-storage-daemon: Expected '=' after parameter 'help'
>
> I believe making them fail like
>
> qemu-storage-daemon: no help available
>
> would actually be an improvement.

Potential issue: if an option's implied key may have the value "help",
then option argument "help" can be either parsed as "give me help", or
as "implied-key=help".

None of the existing options have this issue:

* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
   "help" is not among its values

* display: union DisplayOptions, implied key "type" is enum
   DisplayType, "help" is not among its values

* blockdev: union BlockdevOptions, implied key "driver is enum
   BlockdevDriver, "help" is not among its values

* export: union BlockExport, implied key "type" is enum BlockExportType,
  "help" is not among its values

* monitor: struct MonitorOptions, implied key "mode"is enum MonitorMode,
  "help" is not among its values

* nbd-server: struct NbdServerOptions, no implied key.

We're good.

What's the risk of not staying good?

The implied keys above are all QAPI enums.

The only existing QAPI enum with a value 'help' is QKeyCode.

The only existing C enum with a name that ends in _HELP is the one
defining Mac keycodes in hw/input/adb-keys.h.

For completeness, I double-checked non of the existing occurences of
string "help" are used as values of option parameters.

We'll almost certainly stay good.

What if we manage to mess this up against all odds?

In my opinion, consistency in getting help is more important than
consistency within a badly designed option: option argument "help"
should give you help even when that means you can't omit the implied key
when its value is "help".

[...]

Re: [RFC PATCH 19/21] contrib/gitdm: Add Yadro to the domain map

[Roman Bolshakov]

On Sun, Oct 04, 2020 at 08:04:41PM +0200, Philippe Mathieu-Daudé wrote:
> There is a number of contributions from this domain,
> add its own entry to the gitdm domain map.
> 
> Cc: Igor Kononenko 
> Cc: Roman Bolshakov 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> One Reviewed-by/Ack-by from someone from this domain
> should be sufficient to get this patch merged.
> ---
>  contrib/gitdm/domain-map | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index 6b3a2c3b4e..7170ddea7a 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -41,3 +41,4 @@ wavecomp.comWavecomp
>  wdc.com Western Digital
>  windriver.com   Wind River
>  xilinx.com  Xilinx
> +yadro.com   YADRO
> -- 
> 2.26.2
> 

Reviewed-by: Roman Bolshakov 

Thanks,
Roman

Re: [PATCH v7 00/14] Reverse debugging

[Paolo Bonzini]

On 03/10/20 19:12, Pavel Dovgalyuk wrote:
> GDB remote protocol supports reverse debugging of the targets.
> It includes 'reverse step' and 'reverse continue' operations.
> The first one finds the previous step of the execution,
> and the second one is intended to stop at the last breakpoint that
> would happen when the program is executed normally.
> 
> Reverse debugging is possible in the replay mode, when at least
> one snapshot was created at the record or replay phase.
> QEMU can use these snapshots for travelling back in time with GDB.
> 
> Running the execution in replay mode allows using GDB reverse debugging
> commands:
>  - reverse-stepi (or rsi): Steps one instruction to the past.
>QEMU loads on of the prior snapshots and proceeds to the desired
>instruction forward. When that step is reaches, execution stops.
>  - reverse-continue (or rc): Runs execution "backwards".
>QEMU tries to find breakpoint or watchpoint by loaded prior snapshot
>and replaying the execution. Then QEMU loads snapshots again and
>replays to the latest breakpoint. When there are no breakpoints in
>the examined section of the execution, QEMU finds one more snapshot
>and tries again. After the first snapshot is processed, execution
>stops at this snapshot.
> 
> The set of patches include the following modifications:
>  - gdbstub update for reverse debugging support
>  - functions that automatically perform reverse step and reverse
>continue operations
>  - hmp/qmp commands for manipulating the replay process
>  - improvement of the snapshotting for saving the execution step
>in the snapshot parameters
>  - avocado-based acceptance tests for reverse debugging
> 
> The patches are available in the repository:
> https://github.com/ispras/qemu/tree/rr-200901
> 
> v7 changes:
>  - updated snapshot info output format
>  - fixed qcow2 snapshot-related tests

Sorry, I'm still seeing a failure

timeout 15  /home/travis/build/bonzini/qemu/build/qemu-system-aarch64 -monitor 
none -display none -chardev file,path=memory-replay.out,id=output -icount 
shift=5,rr=replay,rrfile=record.bin  -M virt -cpu max -display none 
-semihosting-config enable=on,target=native,chardev=output -kernel memory

qemu-system-aarch64: terminating on signal 15 from pid 38312 (timeout)

https://travis-ci.com/gitlab/bonzini/qemu/jobs/395029273

Paolo

Re: [PATCH v5 10/10] migration: introduce snapshot-{save, load, delete} QMP commands

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Mon, Oct 05, 2020 at 09:26:54AM +0200, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>> > On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
>> >
>> > Do we have a query- command handy to easily learn which snapshot names
>> > are even available to attempt deletion on?  If not, that's worth a
>> > separate patch.
>> 
>> Oh, I missed that one.  It's the QMP equivalent to "info snapshots", and
>> it is required to finish the job.  Since we're at v5, I'd be okay with a
>> follow-up patch, as long as it is done for 5.2.
>
> "query-named-block-nodes" returns BlockDeviceInfo struct, which
> contains ImageInfo which contains an array of SnapshotInfo. So
> we don't need any new query command.

My Acked-by stands without a new query then.

[PATCH] migration: block-dirty-bitmap: rewrite dirty_bitmap_load_header

[Paolo Bonzini]

Alex reported an uninitialized variable warning in dirty_bitmap_load_header,
where the compiler cannot understand that the !s->cancelled check must be
true for the following one to pass.

Even though the issue happened only because of -Og, the function is very
convoluted.  Just rewrite it to first look up s->bs and then s->bitmap,
and to avoid long sequences of "else if"s.

Signed-off-by: Paolo Bonzini 
---
 migration/block-dirty-bitmap.c | 138 -
 1 file changed, 68 insertions(+), 70 deletions(-)

diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
index 5bef793ac0..24d749e35e 100644
--- a/migration/block-dirty-bitmap.c
+++ b/migration/block-dirty-bitmap.c
@@ -1010,102 +1010,100 @@ static int dirty_bitmap_load_bits(QEMUFile *f, 
DBMLoadState *s)
 static int dirty_bitmap_load_header(QEMUFile *f, DBMLoadState *s,
 GHashTable *alias_map)
 {
-GHashTable *bitmap_alias_map = NULL;
-Error *local_err = NULL;
-bool nothing;
 s->flags = qemu_get_bitmap_flags(f);
 trace_dirty_bitmap_load_header(s->flags);
 
-nothing = s->flags == (s->flags & DIRTY_BITMAP_MIG_FLAG_EOS);
-
+/* Read the whole header early so we can easily cancel in case of errors.  
*/
 if (s->flags & DIRTY_BITMAP_MIG_FLAG_DEVICE_NAME) {
 if (!qemu_get_counted_string(f, s->node_alias)) {
 error_report("Unable to read node alias string");
 return -EINVAL;
 }
-
-if (!s->cancelled) {
-if (alias_map) {
-const AliasMapInnerNode *amin;
-
-amin = g_hash_table_lookup(alias_map, s->node_alias);
-if (!amin) {
-error_setg(&local_err, "Error: Unknown node alias '%s'",
-   s->node_alias);
-s->bs = NULL;
-} else {
-bitmap_alias_map = amin->subtree;
-s->bs = bdrv_lookup_bs(NULL, amin->string, &local_err);
-}
-} else {
-s->bs = bdrv_lookup_bs(s->node_alias, s->node_alias,
-   &local_err);
-}
-if (!s->bs) {
-error_report_err(local_err);
-cancel_incoming_locked(s);
-}
+}
+if (s->flags & DIRTY_BITMAP_MIG_FLAG_BITMAP_NAME) {
+if (!qemu_get_counted_string(f, s->bitmap_alias)) {
+error_report("Unable to read bitmap alias string");
+return -EINVAL;
 }
-} else if (s->bs) {
+}
+
+if ((s->flags & ~DIRTY_BITMAP_MIG_FLAG_EOS) == 0 || s->cancelled) {
+return 0;
+}
+
+if (s->flags & DIRTY_BITMAP_MIG_FLAG_DEVICE_NAME) {
+Error *local_err = NULL;
 if (alias_map) {
 const AliasMapInnerNode *amin;
 
-/* Must be present in the map, or s->bs would not be set */
 amin = g_hash_table_lookup(alias_map, s->node_alias);
-assert(amin != NULL);
-
-bitmap_alias_map = amin->subtree;
+if (!amin) {
+error_report("Error: Unknown node alias '%s'", s->node_alias);
+s->bs = NULL;
+goto cancel;
+}
+s->bs = bdrv_lookup_bs(NULL, amin->string, &local_err);
+} else {
+s->bs = bdrv_lookup_bs(s->node_alias, s->node_alias, &local_err);
 }
-} else if (!nothing && !s->cancelled) {
+if (!s->bs) {
+error_report_err(local_err);
+goto cancel;
+}
+s->bitmap_name[0] = 0;
+}
+if (!s->bs) {
 error_report("Error: block device name is not set");
-cancel_incoming_locked(s);
+goto cancel;
 }
 
-assert(nothing || s->cancelled || !!alias_map == !!bitmap_alias_map);
-
 if (s->flags & DIRTY_BITMAP_MIG_FLAG_BITMAP_NAME) {
 const char *bitmap_name;
 
-if (!qemu_get_counted_string(f, s->bitmap_alias)) {
-error_report("Unable to read bitmap alias string");
-return -EINVAL;
-}
+if (alias_map) {
+const AliasMapInnerNode *amin;
+GHashTable *bitmap_alias_map;
 
-if (!s->cancelled) {
-if (bitmap_alias_map) {
-bitmap_name = g_hash_table_lookup(bitmap_alias_map,
-  s->bitmap_alias);
-if (!bitmap_name) {
-error_report("Error: Unknown bitmap alias '%s' on node "
- "'%s' (alias '%s')", s->bitmap_alias,
- s->bs->node_name, s->node_alias);
-cancel_incoming_locked(s);
-}
-} else {
-bitmap_name = s->bitmap_alias;
-}
-}
+amin = g_hash_table_lookup(alias_map, s->node_alias);
+bitmap_alias_map = amin->subtree;
 
-if (!s->cancell

[PATCH] ide: clean up ahci_populate_sglist

[Paolo Bonzini]

Alex reported an uninitialized variable warning in ahci_populate_sglist.
Even though the warning is bogus and happens only because of -Og, the
code in the function leaves something to be desired; the condition that
triggers the warning is easily shown to be entirely redundant.

In particular, the loop's "if" condition can be rewritten from
"offset < sum + tbl_entry_size" to "offset - sum < tbl_entry_size";
this is safe since the LHS cannot underflow.  Because off_pos is
exactly "offset - sum" it is clear that it can never be less than
zero or greater than tbl_entry_size.  We can therefore keep the off_idx
check only and, for documentation purposes, reduce off_pos to an unsigned
32-bit integer.

The tracepoint also is not particularly useful at this point, since
we know that (if it ever triggers) off_idx will be -1 and off_pos
uninitialized.  Instead, include the requested offset and the total PRDT
length, which will be smaller than the offset.

Signed-off-by: Paolo Bonzini 
---
 hw/ide/ahci.c   | 12 +---
 hw/ide/trace-events |  2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 680304a24c..997b67a6fc 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -924,8 +924,7 @@ static int ahci_populate_sglist(AHCIDevice *ad, QEMUSGList 
*sglist,
 int r = 0;
 uint64_t sum = 0;
 int off_idx = -1;
-int64_t off_pos = -1;
-int tbl_entry_size;
+uint32_t off_pos = 0;
 IDEBus *bus = &ad->port;
 BusState *qbus = BUS(bus);
 
@@ -952,19 +951,18 @@ static int ahci_populate_sglist(AHCIDevice *ad, 
QEMUSGList *sglist,
 /* Get entries in the PRDT, init a qemu sglist accordingly */
 if (prdtl > 0) {
 AHCI_SG *tbl = (AHCI_SG *)prdt;
-sum = 0;
 for (i = 0; i < prdtl; i++) {
-tbl_entry_size = prdt_tbl_entry_size(&tbl[i]);
-if (offset < (sum + tbl_entry_size)) {
+uint32_t tbl_entry_size = prdt_tbl_entry_size(&tbl[i]);
+if (offset - sum < tbl_entry_size) {
 off_idx = i;
 off_pos = offset - sum;
 break;
 }
 sum += tbl_entry_size;
 }
-if ((off_idx == -1) || (off_pos < 0) || (off_pos > tbl_entry_size)) {
+if (off_idx == -1) {
 trace_ahci_populate_sglist_bad_offset(ad->hba, ad->port_no,
-  off_idx, off_pos);
+  sum, offset);
 r = -1;
 goto out;
 }
diff --git a/hw/ide/trace-events b/hw/ide/trace-events
index 6e357685f9..81706efe80 100644
--- a/hw/ide/trace-events
+++ b/hw/ide/trace-events
@@ -88,7 +88,7 @@ ahci_populate_sglist(void *s, int port) "ahci(%p)[%d]"
 ahci_populate_sglist_no_prdtl(void *s, int port, uint16_t opts) "ahci(%p)[%d]: 
no sg list given by guest: 0x%04x"
 ahci_populate_sglist_no_map(void *s, int port) "ahci(%p)[%d]: DMA mapping 
failed"
 ahci_populate_sglist_short_map(void *s, int port) "ahci(%p)[%d]: mapped less 
than expected"
-ahci_populate_sglist_bad_offset(void *s, int port, int off_idx, int64_t 
off_pos) "ahci(%p)[%d]: Incorrect offset! off_idx: %d, off_pos: %"PRId64
+ahci_populate_sglist_bad_offset(void *s, int port, uint64_t sum, uint64_t 
offset) "ahci(%p)[%d]: Incorrect offset! total PRDT length %"PRIu64", offset: 
%"PRIu64
 ncq_finish(void *s, int port, uint8_t tag) "ahci(%p)[%d][tag:%d]: NCQ transfer 
finished"
 execute_ncq_command_read(void *s, int port, uint8_t tag, int count, int64_t 
lba) "ahci(%p)[%d][tag:%d]: NCQ reading %d sectors from LBA %"PRId64
 execute_ncq_command_unsup(void *s, int port, uint8_t tag, uint8_t cmd) 
"ahci(%p)[%d][tag:%d]: error: unsupported NCQ command (0x%02x) received"
-- 
2.26.2

Re: scripts/gdb: issues when loading modules after lx-symbols

[Stefano Garzarella]

On Mon, Oct 05, 2020 at 01:48:35PM +0200, Jan Kiszka wrote:
> On 05.10.20 13:05, Stefano Garzarella wrote:
> > On Mon, Oct 05, 2020 at 11:45:41AM +0200, Jan Kiszka wrote:
> >> On 05.10.20 11:29, Stefano Garzarella wrote:
> >>> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
>  On 05.10.20 10:14, Stefano Garzarella wrote:
> > On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
> >> On 01.10.20 16:31, Stefano Garzarella wrote:
> >>> Hi,
> >>> I had some issues with gdb scripts and kernel modules in Linux 
> >>> 5.9-rc7.
> >>>
> >>> If the modules are already loaded, and I do 'lx-symbols', all work 
> >>> fine.
> >>> But, if I load a kernel module after 'lx-symbols', I had this issue:
> >>>
> >>> [ 5093.393940] invalid opcode:  [#1] SMP PTI
> >>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted 
> >>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2
> >>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), 
> >>> BIOS 1.13.0-2.fc32 04/01/2014
> >>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270
> >>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff 
> >>> e9 c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 
> >>> 40 00 cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 
> >>> 56 41 55
> >>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246
> >>> [ 5093.412056] RAX:  RBX: c010a0c0 RCX: 
> >>> 4ee3
> >>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: 
> >>> c010a0c0
> >>> [ 5093.416349] RBP: c9563e50 R08:  R09: 
> >>> 0002
> >>> [ 5093.418044] R10: 0096 R11: 08a4 R12: 
> >>> 88807a0d1280
> >>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: 
> >>> c9563e70
> >>> [ 5093.427138] FS:  7f018f632740() GS:88807dc0() 
> >>> knlGS:
> >>> [ 5093.430037] CS:  0010 DS:  ES:  CR0: 80050033
> >>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: 
> >>> 00170ef0
> >>> [ 5093.435096] DR0:  DR1:  DR2: 
> >>> 
> >>> [ 5093.436765] DR3:  DR6: fffe0ff0 DR7: 
> >>> 0400
> >>> [ 5093.439689] Call Trace:
> >>> [ 5093.440954]  ? load_module+0x24b6/0x27d0
> >>> [ 5093.443212]  ? __kernel_read+0xd6/0x150
> >>> [ 5093.445140]  __do_sys_finit_module+0xd3/0xf0
> >>> [ 5093.446877]  __x64_sys_finit_module+0x1a/0x20
> >>> [ 5093.449098]  do_syscall_64+0x38/0x50
> >>> [ 5093.450877]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [ 5093.456153] RIP: 0033:0x7f018f75c43d
> >>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e 
> >>> fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 
> >>> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 
> >>> 89 01 48
> >>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: 
> >>> 0139
> >>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: 
> >>> 7f018f75c43d
> >>> [ 5093.474747] RDX:  RSI: 557e5c964288 RDI: 
> >>> 0003
> >>> [ 5093.478049] RBP: 0004 R08:  R09: 
> >>> 
> >>> [ 5093.481298] R10: 0003 R11: 0246 R12: 
> >>> 
> >>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: 
> >>> 557e5c9775c0
> >>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc 
> >>> kvm_intel kvm irqbypass virtio_blk virtio_rng rng_core [last 
> >>> unloaded: virtio_vdpa]
> >>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]---
> >>>
> >>> Guest kernel: Linux 5.9-rc7
> >>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32
> >>> I tried with QEMU 4.2.1 and the latest master branch: same issue.
> >>>
> >>>
> >>> I did some digging, and skipping the gdb 'add-symbol-file' command in 
> >>> symbol.py
> >>> avoid the issue, but of course I don't have the symbols loaded:
> >>>
> >>> diff --git a/scripts/gdb/linux/symbols.py 
> >>> b/scripts/gdb/linux/symbols.py
> >>> index 1be9763cf8bb..eadfaa4d4907 100644
> >>> --- a/scripts/gdb/linux/symbols.py
> >>> +++ b/scripts/gdb/linux/symbols.py
> >>> @@ -129,7 +129,7 @@ lx-symbols command."""
> >>>  filename=module_file,
> >>>  addr=module_addr,
> >>>  sections=self._section_arguments(module))
> >>> -gdb.execute(cmdline, to_string=True)
> >>> +#gdb.execute(cmdline, to_string=True)
> >>>  

Re: [RFC PATCH 3/3] tests: Add a trivial qemu-storage-daemon test

[Paolo Bonzini]

On 05/10/20 12:54, Philippe Mathieu-Daudé wrote:
> This test fails on top of commit 69699f3055
> ("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
> because the TYPE_FW_CFG_DATA_GENERATOR_INTERFACE registered
> in hw/nvram/fw_cfg.c is not linked into qemu-storage-daemon:
> 
>   $ make check-block
>   Generating qemu-version.h with a meson_exe.py custom command
> qemu-storage-daemon
>   tests/qemu-storage-daemon.sh: line 10: 2089929 Aborted 
> (core dumped)
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/Makefile.include   |  3 +++
>  tests/qemu-storage-daemon.sh | 10 ++
>  2 files changed, 13 insertions(+)
>  create mode 100755 tests/qemu-storage-daemon.sh
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index d25560..be12581c77 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -142,7 +142,10 @@ endif
>  check: check-block
>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>   qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
> + storage-daemon/qemu-storage-daemon \
>   $(patsubst %-softmmu,qemu-system-%,$(filter 
> %-softmmu,$(TARGET_DIRS)))
> + $(call quiet-command, \
> + $(SRC_PATH)/tests/qemu-storage-daemon.sh, 
> "qemu-storage-daemon")
>   @$<
>  endif
>  
> diff --git a/tests/qemu-storage-daemon.sh b/tests/qemu-storage-daemon.sh
> new file mode 100755
> index 00..9fd4c73400
> --- /dev/null
> +++ b/tests/qemu-storage-daemon.sh
> @@ -0,0 +1,10 @@
> +#!/bin/sh
> +
> +# Test all QOM dependencies are resolved
> +storage-daemon/qemu-storage-daemon \
> +  --chardev stdio,id=qmp0  --monitor qmp0 \
> +  > /dev/null << 'EOF'
> +{"execute": "qmp_capabilities"}
> +{"execute": "qom-list-types"}
> +{"execute": "quit"}
> +EOF

I think you should either do this as a qemu-iotests testcase, or use
libqtest.

Paolo

Re: [RFC PATCH 1/3] qom: Always register FW_CFG_DATA_GENERATOR_INTERFACE

[Daniel P . Berrangé]

On Mon, Oct 05, 2020 at 12:54:40PM +0200, Philippe Mathieu-Daudé wrote:
> While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed
> by a device only available using system-mode (fw_cfg), it is
> implemented by a crypto component (tls-cipher-suites) which
> is always available when crypto is used.
> 
> Commit 69699f3055 introduced the following error in the
> qemu-storage-daemon binary:
> 
>   $ echo -e \
> '{"execute": "qmp_capabilities"}\r\n{"execute": 
> "qom-list-types"}\r\n{"execute": "quit"}\r\n' \
> | storage-daemon/qemu-storage-daemon --chardev stdio,id=qmp0  --monitor 
> qmp0
>   {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 5}, 
> "package": ""}, "capabilities": ["oob"]}}
>   {"return": {}}
>   missing interface 'fw_cfg-data-generator' for object 'tls-creds'
>   Aborted (core dumped)
> 
> Since QOM dependencies are resolved at runtime, this issue
> could not be triggered at linktime, and we don't have test
> running the qemu-storage-daemon binary.
> 
> Fix by always registering the QOM interface.
> 
> Reported-by: Kevin Wolf 
> Fixes: 69699f3055 ("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> I first used:
> 
> +if config_host.has_key('CONFIG_GNUTLS') or have_system
> +  qom_ss.add(files('fw_cfg_interface.c'))
> +endif
> 
> but then realized anything could implement a QOM interface,
> so better keep this generic.
> ---
>  hw/nvram/fw_cfg.c  |  7 ---
>  qom/fw_cfg_interface.c | 15 +++

I feel this should be left in hw/nvram, but still added to qom_ss.

The code location should reflect the functional area and maintainership,
so we shouldn't move code just to satisfy linkage problems.

>  MAINTAINERS|  1 +
>  qom/meson.build|  5 +
>  4 files changed, 21 insertions(+), 7 deletions(-)
>  create mode 100644 qom/fw_cfg_interface.c
> 
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 0e95d057fd..08539a1aab 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -1360,18 +1360,11 @@ static const TypeInfo fw_cfg_mem_info = {
>  .class_init= fw_cfg_mem_class_init,
>  };
>  
> -static const TypeInfo fw_cfg_data_generator_interface_info = {
> -.parent = TYPE_INTERFACE,
> -.name = TYPE_FW_CFG_DATA_GENERATOR_INTERFACE,
> -.class_size = sizeof(FWCfgDataGeneratorClass),
> -};
> -
>  static void fw_cfg_register_types(void)
>  {
>  type_register_static(&fw_cfg_info);
>  type_register_static(&fw_cfg_io_info);
>  type_register_static(&fw_cfg_mem_info);
> -type_register_static(&fw_cfg_data_generator_interface_info);
>  }
>  
>  type_init(fw_cfg_register_types)
> diff --git a/qom/fw_cfg_interface.c b/qom/fw_cfg_interface.c
> new file mode 100644
> index 00..2b19502ffe
> --- /dev/null
> +++ b/qom/fw_cfg_interface.c
> @@ -0,0 +1,15 @@
> +#include "qemu/osdep.h"
> +#include "hw/nvram/fw_cfg.h"
> +
> +static const TypeInfo fw_cfg_data_generator_interface_info = {
> +.parent = TYPE_INTERFACE,
> +.name = TYPE_FW_CFG_DATA_GENERATOR_INTERFACE,
> +.class_size = sizeof(FWCfgDataGeneratorClass),
> +};
> +
> +static void fw_cfg_register_types(void)
> +{
> +type_register_static(&fw_cfg_data_generator_interface_info);
> +}
> +
> +type_init(fw_cfg_register_types)
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b76fb31861..9c89d54b41 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2055,6 +2055,7 @@ R: Gerd Hoffmann 
>  S: Supported
>  F: docs/specs/fw_cfg.txt
>  F: hw/nvram/fw_cfg.c
> +F: qom/fw_cfg_interface.c
>  F: stubs/fw_cfg.c
>  F: include/hw/nvram/fw_cfg.h
>  F: include/standard-headers/linux/qemu_fw_cfg.h
> diff --git a/qom/meson.build b/qom/meson.build
> index a1cd03c82c..7335f8c8a2 100644
> --- a/qom/meson.build
> +++ b/qom/meson.build
> @@ -7,6 +7,11 @@ qom_ss.add(files(
>'qom-qobject.c',
>  ))
>  
> +# interfaces any object might implement
> +qom_ss.add(files(
> +  'fw_cfg_interface.c',
> +))
> +
>  qmp_ss.add(files('qom-qmp-cmds.c'))
>  softmmu_ss.add(files('qom-hmp-cmds.c'))
>  
> -- 
> 2.26.2
> 

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: [PULL 00/17] Block patches

[Stefan Hajnoczi]

On Thu, Oct 01, 2020 at 04:12:12PM +0100, Peter Maydell wrote:
> On Thu, 1 Oct 2020 at 16:03, Stefan Hajnoczi  wrote:
> >
> > On Thu, Oct 01, 2020 at 12:23:00PM +0100, Peter Maydell wrote:
> > > This produces this error message on ppc64be Linux:
> > >
> > > make: Entering directory `/home/pm215/qemu/build/all'
> > > make[1]: Entering directory `/home/pm215/qemu/slirp'
> > > make[1]: Nothing to be done for `all'.
> > > make[1]: Leaving directory `/home/pm215/qemu/slirp'
> > > Generating qemu-version.h with a meson_exe.py custom command
> > > Generating qemu-options.def with a meson_exe.py custom command
> > > Generating block-gen.c with a custom command
> > > YAML:1:83: error: unknown enumerated scalar
> > > {"IndentWidth": 4, "BraceWrapping": {"AfterFunction": true},
> > > "BreakBeforeBraces": "Custom", "SortIncludes": false,
> > > "MaxEmptyLinesToKeep": 2}
> > >
> > >^~~~
> > > Error parsing -style: Invalid argument, using LLVM style
> > > YAML:1:83: error: unknown enumerated scalar
> > > {"IndentWidth": 4, "BraceWrapping": {"AfterFunction": true},
> > > "BreakBeforeBraces": "Custom", "SortIncludes": false,
> > > "MaxEmptyLinesToKeep": 2}
> > >
> > >^~~~
> > > Error parsing -style: Invalid argument, using LLVM style
> > > Compiling C object libqemuutil.a.p/util_qemu-error.c.o
> > > Compiling C object libqemuutil.a.p/util_qemu-sockets.c.o
> > > Compiling C object libqemuutil.a.p/util_aio-posix.c.o
> > > Compiling C object libqemuutil.a.p/util_osdep.c.o
> > >
> > > The error does not cause the build to fail, which seems
> > > like it's also a bug...
> > >
> > > (My guess is this is due to some script implicitly wanting
> > > a newer version of something or other than the PPC box
> > > happens to have installed, rather than being an endianness
> > > issue.)
> >
> > Please rerun with make -j1 V=1 so the full command is printed. I'm not
> > sure what is emitting these errors.
> 
> Build tree already overwritten to handle a different pullreq,
> I'm afraid. I can come back and retry later...

No problem. Thanks for pointing out the issue, Vladimir and Peter.

I will send a v2.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH v10 2/9] copy-on-read: add filter append/drop functions

[Vladimir Sementsov-Ogievskiy]

29.09.2020 15:38, Andrey Shinkevich wrote:

Provide API for the COR-filter insertion/removal.
Also, drop the filter child permissions for an inactive state when the
filter node is being removed.

Signed-off-by: Andrey Shinkevich 
---
  block/copy-on-read.c | 84 
  block/copy-on-read.h | 35 ++
  2 files changed, 119 insertions(+)
  create mode 100644 block/copy-on-read.h

diff --git a/block/copy-on-read.c b/block/copy-on-read.c
index cb03e0f..3c8231f 100644
--- a/block/copy-on-read.c
+++ b/block/copy-on-read.c
@@ -23,11 +23,21 @@
  #include "qemu/osdep.h"
  #include "block/block_int.h"
  #include "qemu/module.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qdict.h"
+#include "block/copy-on-read.h"
+
+
+typedef struct BDRVStateCOR {
+bool active;
+} BDRVStateCOR;
  
  
  static int cor_open(BlockDriverState *bs, QDict *options, int flags,

  Error **errp)
  {
+BDRVStateCOR *state = bs->opaque;
+
  bs->file = bdrv_open_child(NULL, options, "file", bs, &child_of_bds,
 BDRV_CHILD_FILTERED | BDRV_CHILD_PRIMARY,
 false, errp);
@@ -42,6 +52,13 @@ static int cor_open(BlockDriverState *bs, QDict *options, 
int flags,
  ((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
  bs->file->bs->supported_zero_flags);
  
+state->active = true;

+
+/*
+ * We don't need to call bdrv_child_refresh_perms() now as the permissions
+ * will be updated later when the filter node gets its parent.
+ */
+
  return 0;
  }
  
@@ -57,6 +74,17 @@ static void cor_child_perm(BlockDriverState *bs, BdrvChild *c,

 uint64_t perm, uint64_t shared,
 uint64_t *nperm, uint64_t *nshared)
  {
+BDRVStateCOR *s = bs->opaque;
+
+if (!s->active) {
+/*
+ * While the filter is being removed
+ */
+*nperm = 0;
+*nshared = BLK_PERM_ALL;
+return;
+}
+
  *nperm = perm & PERM_PASSTHROUGH;
  *nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
  
@@ -135,6 +163,7 @@ static void cor_lock_medium(BlockDriverState *bs, bool locked)
  
  static BlockDriver bdrv_copy_on_read = {

  .format_name= "copy-on-read",
+.instance_size  = sizeof(BDRVStateCOR),
  
  .bdrv_open  = cor_open,

  .bdrv_child_perm= cor_child_perm,
@@ -159,4 +188,59 @@ static void bdrv_copy_on_read_init(void)
  bdrv_register(&bdrv_copy_on_read);
  }
  
+

+BlockDriverState *bdrv_cor_filter_append(BlockDriverState *bs,
+ QDict *node_options,
+ int flags, Error **errp)



Ok, now function can add ~any filter, not only COR.. But it's a pair for 
bdrv_cor_filter_drop(), and with "active" hack we don't want make the functions 
generic I think. So it's OK for now to keep function here and named _cor_.


+{
+BlockDriverState *cor_filter_bs;
+Error *local_err = NULL;
+
+cor_filter_bs = bdrv_open(NULL, NULL, node_options, flags, errp);
+if (cor_filter_bs == NULL) {
+error_prepend(errp, "Could not create COR-filter node: ");
+return NULL;
+}


You've dropped setting ->implicit field if filter_node_name not specified. 
Probably caller now can do it.. I don't really care about implicit case, so it's 
OK for me if it works with iotests.

So,

Reviewed-by: Vladimir Sementsov-Ogievskiy 


--
Best regards,
Vladimir

[PATCH] configure: don't enable ASLR for --enable-debug Windows builds

[Mark Cave-Ayland]

Unlike other OSs it is not possible for gdb to temporarily disable ASLR when
debugging executables on Windows which causes gdb to fail with memory access
errors when trying to debug QEMU.

Keep ASLR enabled by default on Windows via the --dynamicbase compiler flag
except for --enable-debug builds when there is a clear expectation that a
functioning gdb is expected at the cost of slightly less security.

Signed-off-by: Mark Cave-Ayland 
---
 configure | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index f46f433649..a3de75b9f8 100755
--- a/configure
+++ b/configure
@@ -6144,7 +6144,14 @@ fi
 
 # Use ASLR, no-SEH and DEP if available
 if test "$mingw32" = "yes" ; then
-for flag in --dynamicbase --no-seh --nxcompat; do
+flags="--no-seh --nxcompat"
+
+# Disable ASLR for debug builds to allow debugging with gdb
+if test "$debug" = "no" ; then
+flags="--dynamicbase $flags"
+fi
+
+for flag in $flags; do
 if ld_has $flag ; then
 QEMU_LDFLAGS="-Wl,$flag $QEMU_LDFLAGS"
 fi
-- 
2.20.1

Re: [PATCH 2/2] hw/mips: Simplify code using ROUND_UP(INITRD_PAGE_SIZE)

[Richard Henderson]

On 9/27/20 11:39 AM, Philippe Mathieu-Daudé wrote:
> Instead of using a INITRD_PAGE_MASK definition, use the
> simpler INITRD_PAGE_SIZE one which allows us to simplify
> the code by using directly the self-explicit ROUND_UP()
> macro.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/mips/mips.h | 4 +++-
>  hw/mips/fuloong2e.c| 3 +--
>  hw/mips/malta.c| 6 +++---
>  hw/mips/mipssim.c  | 3 +--
>  hw/mips/r4k.c  | 3 +--
>  5 files changed, 9 insertions(+), 10 deletions(-)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH 1/2] hw/mips: Simplify loading 64-bit ELF kernels

[Richard Henderson]

On 9/27/20 11:39 AM, Philippe Mathieu-Daudé wrote:
> Since 82790064116 ("Cast ELF datatypes properly to host 64bit types")
> we don't need to sign-extend the entry_point address. Remove this
> unnecessary code.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/mips/mipssim.c | 6 +-
>  hw/mips/r4k.c | 6 +-
>  2 files changed, 2 insertions(+), 10 deletions(-)

Reviewed-by: Richard Henderson 

r~

Re: [RFC PATCH 08/21] contrib/gitdm: Add Mentor Graphics to the domain map

[Joseph Myers]

On Sun, 4 Oct 2020, Philippe Mathieu-Daudé wrote:

> There is a number of contributors from this domain,
> add its own entry to the gitdm domain map.

At some point the main branding will be Siemens; not sure how you want to 
handle that.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] configure: don't enable ASLR for --enable-debug Windows builds

[Richard Henderson]

On 10/5/20 8:34 AM, Mark Cave-Ayland wrote:
> Unlike other OSs it is not possible for gdb to temporarily disable ASLR when
> debugging executables on Windows which causes gdb to fail with memory access
> errors when trying to debug QEMU.
> 
> Keep ASLR enabled by default on Windows via the --dynamicbase compiler flag
> except for --enable-debug builds when there is a clear expectation that a
> functioning gdb is expected at the cost of slightly less security.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  configure | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v7 00/14] Reverse debugging

[Pavel Dovgalyuk]

On 05.10.2020 15:27, Paolo Bonzini wrote:

On 03/10/20 19:12, Pavel Dovgalyuk wrote:

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

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

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

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

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

v7 changes:
  - updated snapshot info output format
  - fixed qcow2 snapshot-related tests


Sorry, I'm still seeing a failure

timeout 15  /home/travis/build/bonzini/qemu/build/qemu-system-aarch64 -monitor 
none -display none -chardev file,path=memory-replay.out,id=output -icount 
shift=5,rr=replay,rrfile=record.bin  -M virt -cpu max -display none 
-semihosting-config enable=on,target=native,chardev=output -kernel memory

qemu-system-aarch64: terminating on signal 15 from pid 38312 (timeout)


That's very strange.
None of the patches affect RR for AArch64. Is this the real failure or 
just a coincidence?
I also tried running this test on my local machine and got normal 
execution time for replay:

real0m0,968s
user0m0,657s
sys 0m0,625s

By the way, this is an early RR test. Now we have more complex (and 
easier to reproduce) avocado-based RR tests (for aarch64 too).

I.e. record and replay in this test are divided into two "tests",
and can cause races if running in parallel for some reason.

Shouldn't we just drop this one?



https://travis-ci.com/gitlab/bonzini/qemu/jobs/395029273

Paolo