Re: [PATCH 0/15] KVM: MIPS: Add Loongson-3 support (Host Side)

2020-04-13 Thread Jiaxun Yang
On Tue, 14 Apr 2020 09:40:26 +0800
maobibo  wrote:

> On 04/13/2020 04:18 PM, Jiaxun Yang wrote:
> > On Mon, 13 Apr 2020 15:30:09 +0800
> > Huacai Chen  wrote:
> >   
> >> We are preparing to add KVM support for Loongson-3. VZ extension is
> >> fully supported in Loongson-3A R4+, and we will not care about old
> >> CPUs (at least now). We already have a full functional Linux kernel
> >> (based on Linux-5.4.x LTS) and QEMU (based on 5.0.0-rc2) and their
> >> git repositories are here:
> >>
> >> QEMU: https://github.com/chenhuacai/qemu
> >> Kernel: https://github.com/chenhuacai/linux
> >>
> >> Of course these two repositories need to be rework and not suitable
> >> for upstream (especially the commits need to be splitted). We show
> >> them here is just to tell others what we have done, and how
> >> KVM/Loongson will look like.
> >>
> >> Our plan is make the KVM host side be upstream first, and after
> >> that, we will make the KVM guest side and QEMU emulator be
> >> upstream.  
> > 
> > + Aleksandar as QEMU/MIPS mainatiner
> > 
> > I was involved in KVM/Loongson development a bit and also intend to
> > help with mainline these works.
> > 
> > After dealing with basic LS7A PCH kernel support, I'm going to
> > cooperate with Huacai and anyone who interested in to deal with
> > following stuff:
> > 
> > - Basic QEMU/TCG support for Loongson64 instructions.
> > Well, it seems unrelated with KVM, but that would make
> > development easier with cross ISA emulation. I'm not going
> > to implement all the features like Loongson's page table fast walk
> > extension and binary translation extension but I'll ensure
> > any binary compiled with march=loongson3a can run flawlessly on
> > TCG.
> > 
> > - Design of Loongson-VIRT QEMU machine
> > It is nearly impossible to bring a real Loongson system into
> > QEMU. Both RS780E and LS7A PCH have tons of unreasonable
> > design that would make the emulation extremely complex, Loongson
> > company's KVM implementation[1] has already proofed that,
> > thay're now in the hell. So we all agreed that we should
> > build a machine from draft. I think we should reuse existing infra
> > as far as possible to reduce our work load. I'm planing to use
> > pci-host-cam-generic together with VIRTIO PCI devices and a
> > a strip down version of loongson,liointc-1.0a to build a
> > pure PCI based system. But if any one have better idea please just
> > tell us, I'm still considering how to implement SMP-IPI and
> > ACPI stuff.  

Hi Bibo,
Thanks for your response.

+ Xing Li as I heard he is in charge of KVM from Loongson's news post.

> It is a good job to add kvm virtualization support on loongson64
> platform. I agree that we should define common virt machine hardware
> system, however the compiled kernel binary should be the same with
> host system, else it will bring out trouble for customers to
> differentiate them between guest system and host system.

I'm planing to use DeviceTree to pass device information between QEMU
and guest kernel. So we can upgrade VM design at any moment without
breaking Host Guest kernel compatibility.

 
> For pci host bridge emulation, I suggest that gpex pcie host bridge
> should be used, since it supports pcie hotplug and arm/riscv uses
> this pcie host bridge.


gpex is basically a pci-host-cam-generic at kernel point of view. I'm
planing to reuse it too.

> 
> For virtual interrupt controller, it should support MSI/MSIX
> interrupt, irqchip in kernel, IRQFD, vhost/vfio etc. I have no idea
> how to define virtual interrupt controller now.

Yes, APIC from x86 and GIC from Arm are all bonded closely with their
architecture so we can't reuse them. Probably what we need is a
modified version of EXTIOI from Loongson-3A4000.

Does Loongson have a plan to implement hardware virtual irqchip? If so
we must align with it's design.

My plan is we can firstly implement a very simple IRQCHIP instead of
complex one which only handle UART and PCI INTx. That is enough to make
the system work. After that we can sit and discuss how to implement a
complicated version to archive more features.

> 
> 
> regards
> bibo,mao
> 
[...]



Re: Boot flakiness with QEMU 3.1.0 and Clang built kernels

2020-04-13 Thread Nathan Chancellor
On Tue, Apr 14, 2020 at 12:05:53PM +1000, David Gibson wrote:
> On Sat, Apr 11, 2020 at 11:57:23PM +1000, Nicholas Piggin wrote:
> > Nicholas Piggin's on April 11, 2020 7:32 pm:
> > > Nathan Chancellor's on April 11, 2020 10:53 am:
> > >> The tt.config values are needed to reproduce but I did not verify that
> > >> ONLY tt.config was needed. Other than that, no, we are just building
> > >> either pseries_defconfig or powernv_defconfig with those configs and
> > >> letting it boot up with a simple initramfs, which prints the version
> > >> string then shuts the machine down.
> > >> 
> > >> Let me know if you need any more information, cheers!
> > > 
> > > Okay I can reproduce it. Sometimes it eventually recovers after a long
> > > pause, and some keyboard input often helps it along. So that seems like 
> > > it might be a lost interrupt.
> > > 
> > > POWER8 vs POWER9 might just be a timing thing if P9 is still hanging
> > > sometimes. I wasn't able to reproduce it with defconfig+tt.config, I
> > > needed your other config with various other debug options.
> > > 
> > > Thanks for the very good report. I'll let you know what I find.
> > 
> > It looks like a qemu bug. Booting with '-d int' shows the decrementer 
> > simply stops firing at the point of the hang, even though MSR[EE]=1 and 
> > the DEC register is wrapping. Linux appears to be doing the right thing 
> > as far as I can tell (not losing interrupts).
> > 
> > This qemu patch fixes the boot hang for me. I don't know that qemu 
> > really has the right idea of "context synchronizing" as defined in the
> > powerpc architecture -- mtmsrd L=1 is not context synchronizing but that
> > does not mean it can avoid looking at exceptions until the next such
> > event. It looks like the decrementer exception goes high but the
> > execution of mtmsrd L=1 is ignoring it.
> > 
> > Prior to the Linux patch 3282a3da25b you bisected to, interrupt replay
> > code would return with an 'rfi' instruction as part of interrupt return,
> > which probably helped to get things moving along a bit. However it would
> > not be foolproof, and Cedric did say he encountered some mysterious
> > lockups under load with qemu powernv before that patch was merged, so
> > maybe it's the same issue?
> > 
> > Thanks,
> > Nick
> > 
> > The patch is a bit of a hack, but if you can run it and verify it fixes
> > your boot hang would be good.
> 
> So a bug in this handling wouldn't surprise me at all.  However a
> report against QEMU 3.1 isn't particularly useful.
> 
>  * Does the problem occur with current upstream master qemu?

Yes, I can reproduce the hang on 5.0.0-rc2.

>  * Does the problem occur with qemu-2.12 (a pretty widely deployed
>"stable" qemu, e.g. in RHEL)?

No idea but I would assume so. I might have time later this week to test
but I assume it is kind of irrelevant if it is reproducible at ToT.

> > ---
> > 
> > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > index b207fb5386..1d997f5c32 100644
> > --- a/target/ppc/translate.c
> > +++ b/target/ppc/translate.c
> > @@ -4364,12 +4364,21 @@ static void gen_mtmsrd(DisasContext *ctx)
> >  if (ctx->opcode & 0x0001) {
> >  /* Special form that does not need any synchronisation */
> >  TCGv t0 = tcg_temp_new();
> > +TCGv t1 = tcg_temp_new();
> >  tcg_gen_andi_tl(t0, cpu_gpr[rS(ctx->opcode)],
> >  (1 << MSR_RI) | (1 << MSR_EE));
> > -tcg_gen_andi_tl(cpu_msr, cpu_msr,
> > +tcg_gen_andi_tl(t1, cpu_msr,
> >  ~(target_ulong)((1 << MSR_RI) | (1 << MSR_EE)));
> > -tcg_gen_or_tl(cpu_msr, cpu_msr, t0);
> > +tcg_gen_or_tl(t1, t1, t0);
> > +
> > +gen_update_nip(ctx, ctx->base.pc_next);
> > +gen_helper_store_msr(cpu_env, t1);
> >  tcg_temp_free(t0);
> > +tcg_temp_free(t1);
> > +/* Must stop the translation as machine state (may have) changed */
> > +/* Note that mtmsr is not always defined as context-synchronizing 
> > */
> > +gen_stop_exception(ctx);
> > +
> >  } else {
> >  /*
> >   * XXX: we need to update nip before the store if we enter
> > 
> 
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Cheers,
Nathan



Re: [PATCH] spapr_nvdimm.c: make 'label-size' mandatory

2020-04-13 Thread David Gibson
CCing Xiao, Michael and Igor for generic NVDIMM perspective.

On Mon, Apr 13, 2020 at 05:36:28PM -0300, Daniel Henrique Barboza wrote:
> The pseries machine does not support NVDIMM modules without label.
> Attempting to do so, even if the overall block size is aligned with
> 256MB, will seg fault the guest kernel during NVDIMM probe. This
> can be avoided by forcing 'label-size' to always be present for
> sPAPR NVDIMMs.
> 
> The verification was put before the alignment check because the
> presence of label-size affects the alignment calculation, so
> it's not optimal to warn the user about an alignment error,
> then about the lack of label-size, then about a new alignment
> error when the user sets a label-size.
> 
> Signed-off-by: Daniel Henrique Barboza 

So, this would get the job done, but it seems a bit inelegant compared
to having the device default to working settings.  I'm looking at how
this interacts with the generic constraints on label-size.

The generic nvdimm code has a MIN_NAMESPACE_LABEL_SIZE of 128 kiB, and
values of label-size less than that are rejected.  Except that if
label-size is not set at all, it is left as 0.

Is that intended behaviour?  Do x86 (or whatever) NVDIMMs have a label
of at least 128kiB, unless they have no label at all?  Or could we
make the default label-size 128kiB generically?

> ---
>  hw/ppc/spapr_nvdimm.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
> index 25be8082d7..9abcdcc26b 100644
> --- a/hw/ppc/spapr_nvdimm.c
> +++ b/hw/ppc/spapr_nvdimm.c
> @@ -37,6 +37,12 @@ void spapr_nvdimm_validate_opts(NVDIMMDevice *nvdimm, 
> uint64_t size,
>  QemuUUID uuid;
>  int ret;
>  
> +if (object_property_get_int(OBJECT(nvdimm), NVDIMM_LABEL_SIZE_PROP,
> +_abort) == 0) {
> +error_setg(errp, "NVDIMM device requires label-size to be set");
> +return;
> +}
> +
>  if (size % SPAPR_MINIMUM_SCM_BLOCK_SIZE) {
>  error_setg(errp, "NVDIMM memory size excluding the label area"
> " must be a multiple of %" PRIu64 "MB",

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


signature.asc
Description: PGP signature


Re: [PATCH RESEND v3 0/2] Makefile: libfdt: build only the strict necessary

2020-04-13 Thread David Gibson
On Sat, Apr 11, 2020 at 11:31:48AM +0200, Claudio Fontana wrote:
> v2 -> v3:
> 
> * changed into a 2 patch series; in the second patch we remove the old
>   compatibility gunks that were meant for removal some time after 4.1.
> 
> * renamed the libfdt PHONY rule to dtc/all, with the intent to make
>   existing working trees forward and backward compatible across the change.
> 
> v1 -> v2:
> 
> * fix error generated when running UNCHECKED_GOALS without prior configure,
>   for example during make docker-image-fedora. Without configure, DSOSUF is
>   empty, and the module pattern rule in rules.mak that uses this variable
>   can match too much; provide a default in the Makefile to avoid it.
> 
> * only attempt to build the archive when there is a non-empty list of objects.
>   This could be done in general for the %.a: pattern in rules.mak, but maybe
>   there are valid reasons to build an empty .a?
> 
> * removed some intermediate variables that did not add much value
>   (LIBFDT_srcdir, LIBFDT_archive)
> 
> Tested locally with 3 VPATH configurations (no-, VPATH, VPATH in src subdir),
> and with docker-image-fedora, docker-test-debug@fedora that failed
> before.

Seems reasonable to me.  It's a bit of a shame that we can't use the
dtc makefiles more simply for this.  But I don't quickly know how to
fix them upstream to allow that.

> 
> Claudio Fontana (2):
>   Makefile: libfdt: build only the strict necessary
>   Makefile: remove old compatibility gunks
> 
>  Makefile  | 32 
>  configure |  6 +-
>  rules.mak |  2 ++
>  3 files changed, 19 insertions(+), 21 deletions(-)
> 

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


signature.asc
Description: PGP signature


Re: [PATCH-for-5.1 v3 11/23] hw/pci-host/pnv_phb3: Add missing error-propagation code

2020-04-13 Thread David Gibson
On Mon, Apr 13, 2020 at 12:41:32AM +0200, Philippe Mathieu-Daudé wrote:
> Patch created mechanically by running:
> 
>   $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file scripts/coccinelle/use-error_propagate-in-realize.cocci \
> --keep-comments --smpl-spacing --in-place --dir hw
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Acked-by: David Gibson 

> ---
>  hw/pci-host/pnv_phb3.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
> index 57d717ed23..a9029f5a02 100644
> --- a/hw/pci-host/pnv_phb3.c
> +++ b/hw/pci-host/pnv_phb3.c
> @@ -1008,7 +1008,11 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
> **errp)
>  
>  /* LSI sources */
>  object_property_set_link(OBJECT(>lsis), OBJECT(pnv), "xics",
> -   _abort);
> +   _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>lsis), true, "realized", 
> _err);
>  if (local_err) {
>  error_propagate(errp, local_err);
> @@ -1023,9 +1027,17 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
> **errp)
>  
>  /* MSI sources */
>  object_property_set_link(OBJECT(>msis), OBJECT(phb), "phb",
> -   _abort);
> +   _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  object_property_set_link(OBJECT(>msis), OBJECT(pnv), "xics",
> -   _abort);
> +   _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>msis), true, "realized", 
> _err);
>  if (local_err) {
>  error_propagate(errp, local_err);
> @@ -1034,7 +1046,11 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
> **errp)
>  
>  /* Power Bus Common Queue */
>  object_property_set_link(OBJECT(>pbcq), OBJECT(phb), "phb",
> -   _abort);
> +   _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>pbcq), true, "realized", 
> _err);
>  if (local_err) {
>  error_propagate(errp, local_err);

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


signature.asc
Description: PGP signature


Re: [PATCH-for-5.1 1/3] target: Remove unnecessary CPU() cast

2020-04-13 Thread David Gibson
On Sun, Apr 12, 2020 at 11:09:52PM +0200, Philippe Mathieu-Daudé wrote:
> The CPU() macro is defined as:
> 
>   #define CPU(obj) ((CPUState *)(obj))
> 
> Remove an unnecessary CPU() cast.
> 
> Patch created mechanically using spatch with this script:
> 
>   @@
>   typedef CPUState;
>   CPUState *s;
>   @@
>   -   CPU(s)
>   +   s
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Acked-by: David Gibson 

> ---
>  target/ppc/mmu_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index 86c667b094..8972714775 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -1820,7 +1820,7 @@ static inline void do_invalidate_BAT(CPUPPCState *env, 
> target_ulong BATu,
>  if (((end - base) >> TARGET_PAGE_BITS) > 1024) {
>  /* Flushing 1024 4K pages is slower than a complete flush */
>  LOG_BATS("Flush all BATs\n");
> -tlb_flush(CPU(cs));
> +tlb_flush(cs);
>  LOG_BATS("Flush done\n");
>  return;
>  }

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


signature.asc
Description: PGP signature


Re: Boot flakiness with QEMU 3.1.0 and Clang built kernels

2020-04-13 Thread David Gibson
On Sat, Apr 11, 2020 at 11:57:23PM +1000, Nicholas Piggin wrote:
> Nicholas Piggin's on April 11, 2020 7:32 pm:
> > Nathan Chancellor's on April 11, 2020 10:53 am:
> >> The tt.config values are needed to reproduce but I did not verify that
> >> ONLY tt.config was needed. Other than that, no, we are just building
> >> either pseries_defconfig or powernv_defconfig with those configs and
> >> letting it boot up with a simple initramfs, which prints the version
> >> string then shuts the machine down.
> >> 
> >> Let me know if you need any more information, cheers!
> > 
> > Okay I can reproduce it. Sometimes it eventually recovers after a long
> > pause, and some keyboard input often helps it along. So that seems like 
> > it might be a lost interrupt.
> > 
> > POWER8 vs POWER9 might just be a timing thing if P9 is still hanging
> > sometimes. I wasn't able to reproduce it with defconfig+tt.config, I
> > needed your other config with various other debug options.
> > 
> > Thanks for the very good report. I'll let you know what I find.
> 
> It looks like a qemu bug. Booting with '-d int' shows the decrementer 
> simply stops firing at the point of the hang, even though MSR[EE]=1 and 
> the DEC register is wrapping. Linux appears to be doing the right thing 
> as far as I can tell (not losing interrupts).
> 
> This qemu patch fixes the boot hang for me. I don't know that qemu 
> really has the right idea of "context synchronizing" as defined in the
> powerpc architecture -- mtmsrd L=1 is not context synchronizing but that
> does not mean it can avoid looking at exceptions until the next such
> event. It looks like the decrementer exception goes high but the
> execution of mtmsrd L=1 is ignoring it.
> 
> Prior to the Linux patch 3282a3da25b you bisected to, interrupt replay
> code would return with an 'rfi' instruction as part of interrupt return,
> which probably helped to get things moving along a bit. However it would
> not be foolproof, and Cedric did say he encountered some mysterious
> lockups under load with qemu powernv before that patch was merged, so
> maybe it's the same issue?
> 
> Thanks,
> Nick
> 
> The patch is a bit of a hack, but if you can run it and verify it fixes
> your boot hang would be good.

So a bug in this handling wouldn't surprise me at all.  However a
report against QEMU 3.1 isn't particularly useful.

 * Does the problem occur with current upstream master qemu?
 * Does the problem occur with qemu-2.12 (a pretty widely deployed
   "stable" qemu, e.g. in RHEL)?

> ---
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index b207fb5386..1d997f5c32 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -4364,12 +4364,21 @@ static void gen_mtmsrd(DisasContext *ctx)
>  if (ctx->opcode & 0x0001) {
>  /* Special form that does not need any synchronisation */
>  TCGv t0 = tcg_temp_new();
> +TCGv t1 = tcg_temp_new();
>  tcg_gen_andi_tl(t0, cpu_gpr[rS(ctx->opcode)],
>  (1 << MSR_RI) | (1 << MSR_EE));
> -tcg_gen_andi_tl(cpu_msr, cpu_msr,
> +tcg_gen_andi_tl(t1, cpu_msr,
>  ~(target_ulong)((1 << MSR_RI) | (1 << MSR_EE)));
> -tcg_gen_or_tl(cpu_msr, cpu_msr, t0);
> +tcg_gen_or_tl(t1, t1, t0);
> +
> +gen_update_nip(ctx, ctx->base.pc_next);
> +gen_helper_store_msr(cpu_env, t1);
>  tcg_temp_free(t0);
> +tcg_temp_free(t1);
> +/* Must stop the translation as machine state (may have) changed */
> +/* Note that mtmsr is not always defined as context-synchronizing */
> +gen_stop_exception(ctx);
> +
>  } else {
>  /*
>   * XXX: we need to update nip before the store if we enter
> 

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


signature.asc
Description: PGP signature


Re: [PATCH-for-5.1 v3 18/24] hw/pci-host/pnv_phb3: Move some code from realize() to init()

2020-04-13 Thread David Gibson
On Mon, Apr 13, 2020 at 12:36:13AM +0200, Philippe Mathieu-Daudé wrote:
> Coccinelle reported:
> 
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/pci-host/pnv_phb3.c
>   >>> possible moves from pnv_phb3_instance_init() to pnv_phb3_realize() in 
> ./hw/pci-host/pnv_phb3.c:992
> 
> Move the calls using _abort which don't depend on input
> updated before realize() to init().
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Acked-by: David Gibson 

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/pci-host/pnv_phb3.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
> index 74618fadf0..57d717ed23 100644
> --- a/hw/pci-host/pnv_phb3.c
> +++ b/hw/pci-host/pnv_phb3.c
> @@ -970,6 +970,8 @@ static void pnv_phb3_instance_init(Object *obj)
>  /* LSI sources */
>  object_initialize_child(obj, "lsi", >lsis, sizeof(phb->lsis),
>   TYPE_ICS, _abort, NULL);
> +object_property_set_int(OBJECT(>lsis), PNV_PHB3_NUM_LSI, "nr-irqs",
> +_abort);
>  
>  /* Default init ... will be fixed by HW inits */
>  phb->lsis.offset = 0;
> @@ -977,6 +979,8 @@ static void pnv_phb3_instance_init(Object *obj)
>  /* MSI sources */
>  object_initialize_child(obj, "msi", >msis, sizeof(phb->msis),
>  TYPE_PHB3_MSI, _abort, NULL);
> +object_property_set_int(OBJECT(>msis), PHB3_MAX_MSI, "nr-irqs",
> +_abort);
>  
>  /* Power Bus Common Queue */
>  object_initialize_child(obj, "pbcq", >pbcq, sizeof(phb->pbcq),
> @@ -1005,8 +1009,6 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
> **errp)
>  /* LSI sources */
>  object_property_set_link(OBJECT(>lsis), OBJECT(pnv), "xics",
> _abort);
> -object_property_set_int(OBJECT(>lsis), PNV_PHB3_NUM_LSI, "nr-irqs",
> -_abort);
>  object_property_set_bool(OBJECT(>lsis), true, "realized", 
> _err);
>  if (local_err) {
>  error_propagate(errp, local_err);
> @@ -1024,8 +1026,6 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
> **errp)
> _abort);
>  object_property_set_link(OBJECT(>msis), OBJECT(pnv), "xics",
> _abort);
> -object_property_set_int(OBJECT(>msis), PHB3_MAX_MSI, "nr-irqs",
> -_abort);
>  object_property_set_bool(OBJECT(>msis), true, "realized", 
> _err);
>  if (local_err) {
>  error_propagate(errp, local_err);

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


signature.asc
Description: PGP signature


Re: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast

2020-04-13 Thread David Gibson
On Sun, Apr 12, 2020 at 11:09:54PM +0200, Philippe Mathieu-Daudé wrote:
> The DEVICE() macro is defined as:
> 
>   #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
> 
> Remove unnecessary DEVICE() casts.
> 
> Patch created mechanically using spatch with this script:
> 
>   @@
>   typedef DeviceState;
>   DeviceState *s;
>   @@
>   -   DEVICE(s)
>   +   s
> 
> Signed-off-by: Philippe Mathieu-Daudé 

ppc parts

Acked-by: David Gibson 

> ---
>  hw/display/artist.c | 2 +-
>  hw/display/cg3.c| 2 +-
>  hw/display/sm501.c  | 2 +-
>  hw/display/tcx.c| 4 ++--
>  hw/display/vga-isa.c| 2 +-
>  hw/i2c/imx_i2c.c| 2 +-
>  hw/i2c/mpc_i2c.c| 2 +-
>  hw/ide/piix.c   | 2 +-
>  hw/misc/macio/pmu.c | 2 +-
>  hw/net/ftgmac100.c  | 3 +--
>  hw/net/imx_fec.c| 2 +-
>  hw/nubus/nubus-device.c | 2 +-
>  hw/pci-host/bonito.c| 2 +-
>  hw/ppc/spapr.c  | 2 +-
>  hw/sh4/sh_pci.c | 2 +-
>  hw/xen/xen-legacy-backend.c | 2 +-
>  16 files changed, 17 insertions(+), 18 deletions(-)
> 
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 753dbb9a77..7e2a4556bd 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -1353,7 +1353,7 @@ static void artist_realizefn(DeviceState *dev, Error 
> **errp)
>  s->cursor_height = 32;
>  s->cursor_width = 32;
>  
> -s->con = graphic_console_init(DEVICE(dev), 0, _ops, s);
> +s->con = graphic_console_init(dev, 0, _ops, s);
>  qemu_console_resize(s->con, s->width, s->height);
>  }
>  
> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
> index a1ede10394..f7f1c199ce 100644
> --- a/hw/display/cg3.c
> +++ b/hw/display/cg3.c
> @@ -321,7 +321,7 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
>  
>  sysbus_init_irq(sbd, >irq);
>  
> -s->con = graphic_console_init(DEVICE(dev), 0, _ops, s);
> +s->con = graphic_console_init(dev, 0, _ops, s);
>  qemu_console_resize(s->con, s->width, s->height);
>  }
>  
> diff --git a/hw/display/sm501.c b/hw/display/sm501.c
> index de0ab9d977..2a564889bd 100644
> --- a/hw/display/sm501.c
> +++ b/hw/display/sm501.c
> @@ -1839,7 +1839,7 @@ static void sm501_init(SM501State *s, DeviceState *dev,
>  >twoD_engine_region);
>  
>  /* create qemu graphic console */
> -s->con = graphic_console_init(DEVICE(dev), 0, _ops, s);
> +s->con = graphic_console_init(dev, 0, _ops, s);
>  }
>  
>  static const VMStateDescription vmstate_sm501_state = {
> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
> index 76de16e8ea..1fb45b1aab 100644
> --- a/hw/display/tcx.c
> +++ b/hw/display/tcx.c
> @@ -868,9 +868,9 @@ static void tcx_realizefn(DeviceState *dev, Error **errp)
>  sysbus_init_irq(sbd, >irq);
>  
>  if (s->depth == 8) {
> -s->con = graphic_console_init(DEVICE(dev), 0, _ops, s);
> +s->con = graphic_console_init(dev, 0, _ops, s);
>  } else {
> -s->con = graphic_console_init(DEVICE(dev), 0, _ops, s);
> +s->con = graphic_console_init(dev, 0, _ops, s);
>  }
>  s->thcmisc = 0;
>  
> diff --git a/hw/display/vga-isa.c b/hw/display/vga-isa.c
> index 0633ed382c..3aaeeeca1e 100644
> --- a/hw/display/vga-isa.c
> +++ b/hw/display/vga-isa.c
> @@ -74,7 +74,7 @@ static void vga_isa_realizefn(DeviceState *dev, Error 
> **errp)
>  0x000a,
>  vga_io_memory, 1);
>  memory_region_set_coalescing(vga_io_memory);
> -s->con = graphic_console_init(DEVICE(dev), 0, s->hw_ops, s);
> +s->con = graphic_console_init(dev, 0, s->hw_ops, s);
>  
>  memory_region_add_subregion(isa_address_space(isadev),
>  VBE_DISPI_LFB_PHYSICAL_ADDRESS,
> diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
> index 30b9aea247..2e02e1c4fa 100644
> --- a/hw/i2c/imx_i2c.c
> +++ b/hw/i2c/imx_i2c.c
> @@ -305,7 +305,7 @@ static void imx_i2c_realize(DeviceState *dev, Error 
> **errp)
>IMX_I2C_MEM_SIZE);
>  sysbus_init_mmio(SYS_BUS_DEVICE(dev), >iomem);
>  sysbus_init_irq(SYS_BUS_DEVICE(dev), >irq);
> -s->bus = i2c_init_bus(DEVICE(dev), NULL);
> +s->bus = i2c_init_bus(dev, NULL);
>  }
>  
>  static void imx_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
> index 0aa1be3ce7..9a724f3a3e 100644
> --- a/hw/i2c/mpc_i2c.c
> +++ b/hw/i2c/mpc_i2c.c
> @@ -332,7 +332,7 @@ static void mpc_i2c_realize(DeviceState *dev, Error 
> **errp)
>  memory_region_init_io(>iomem, OBJECT(i2c), _ops, i2c,
>"mpc-i2c", 0x14);
>  sysbus_init_mmio(SYS_BUS_DEVICE(dev), >iomem);
> -i2c->bus = i2c_init_bus(DEVICE(dev), "i2c");
> +i2c->bus = i2c_init_bus(dev, "i2c");
>  }
>  
>  static void mpc_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 

Re: [PATCH-for-5.1 v3 01/24] various: Remove suspicious '\' character outside of #define in C code

2020-04-13 Thread David Gibson
On Mon, Apr 13, 2020 at 12:35:56AM +0200, Philippe Mathieu-Daudé wrote:
> Fixes the following coccinelle warnings:
> 
>   $ spatch --sp-file --verbose-parsing  ... \
>   scripts/coccinelle/remove_local_err.cocci
>   ...
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/ppc/translate_init.inc.c:5213
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/ppc/translate_init.inc.c:5261
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:166
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:167
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:169
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:170
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:171
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:172
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:173
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5787
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5789
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5800
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5801
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5802
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5804
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5805
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5806
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:6329
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/sd/sdhci.c:1133
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/scsi/scsi-disk.c:3081
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/net/virtio-net.c:1529
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/riscv/sifive_u.c:468
>   SUSPICIOUS: a \ character appears outside of a #define at ./dump/dump.c:1895
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2209
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2215
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2221
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/replication.c:172
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/replication.c:173
> 
> Reviewed-by: Marc-André Lureau 
> Signed-off-by: Philippe Mathieu-Daudé 

ppc parts

Acked-by: David Gibson 

> ---
>  block/replication.c |  4 ++--
>  block/vhdx.c|  8 
>  dump/dump.c |  2 +-
>  hw/net/virtio-net.c |  2 +-
>  hw/riscv/sifive_u.c |  2 +-
>  hw/scsi/scsi-disk.c |  2 +-
>  hw/sd/sdhci.c   |  2 +-
>  target/i386/cpu.c   | 18 +-
>  target/microblaze/cpu.c | 14 +++---
>  target/ppc/translate_init.inc.c |  4 ++--
>  10 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/block/replication.c b/block/replication.c
> index da013c2041..971f0fe266 100644
> --- a/block/replication.c
> +++ b/block/replication.c
> @@ -172,8 +172,8 @@ static void replication_child_perm(BlockDriverState *bs, 
> BdrvChild *c,
>  if ((bs->open_flags & (BDRV_O_INACTIVE | BDRV_O_RDWR)) == BDRV_O_RDWR) {
>  *nperm |= BLK_PERM_WRITE;
>  }
> -*nshared = BLK_PERM_CONSISTENT_READ \
> -   | BLK_PERM_WRITE \
> +*nshared = BLK_PERM_CONSISTENT_READ
> +   | BLK_PERM_WRITE
> | BLK_PERM_WRITE_UNCHANGED;
>  return;
>  }
> diff --git a/block/vhdx.c b/block/vhdx.c
> index 33e57cd656..e16fdc2f2d 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -2206,20 +2206,20 @@ static QemuOptsList vhdx_create_opts = {
> .name = VHDX_BLOCK_OPT_BLOCK_SIZE,
> .type = QEMU_OPT_SIZE,
> .def_value_str = stringify(0),
> -   .help = "Block Size; min 1MB, max 256MB. " \
> +   .help = "Block Size; min 1MB, max 256MB. "
> "0 means auto-calculate based on image size."
> },
> {
> .name = BLOCK_OPT_SUBFMT,
> .type = QEMU_OPT_STRING,
> -   .help = "VHDX format type, can be either 'dynamic' or 'fixed'. "\
> +   .help = "VHDX format type, can be either 'dynamic' or 'fixed'. "
> "Default is 'dynamic'."
> },
> {
> .name = VHDX_BLOCK_OPT_ZERO,

[PATCH RFC] target/arm: Implement SVE2 MATCH, NMATCH

2020-04-13 Thread Stephen Long
Signed-off-by: Stephen Long 
---
Submitting this for early review. I'm working with Richard on SVE2 support for
qemu. I'll be attempting to tackle the insns in the 'SVE2 integer add/subtract
narrow high part' category next [1].

[1] ISA manual: 
https://static.docs.arm.com/ddi0602/d/ISA_A64_xml_futureA-2019-12_OPT.pdf (page 
2950)

 target/arm/helper-sve.h| 10 +
 target/arm/sve.decode  |  5 +
 target/arm/sve_helper.c| 29 +
 target/arm/translate-sve.c | 43 ++
 4 files changed, 87 insertions(+)

diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 5dd880cf6d..2077df9a95 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -2516,6 +2516,16 @@ DEF_HELPER_FLAGS_3(sve2_uqrshrnt_h, TCG_CALL_NO_RWG, 
void, ptr, ptr, i32)
 DEF_HELPER_FLAGS_3(sve2_uqrshrnt_s, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
 DEF_HELPER_FLAGS_3(sve2_uqrshrnt_d, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
 
+DEF_HELPER_FLAGS_5(sve2_match_zpzz_b, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve2_match_zpzz_h, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(sve2_nmatch_zpzz_b, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve2_nmatch_zpzz_h, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+
 DEF_HELPER_FLAGS_6(sve2_faddp_zpzz_h, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, ptr, i32)
 DEF_HELPER_FLAGS_6(sve2_faddp_zpzz_s, TCG_CALL_NO_RWG,
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index 374e47fb05..652668df02 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -1305,6 +1305,11 @@ UQSHRNT 01000101 .. 1 . 00 1101 . .  
@rd_rn_tszimm_shr
 UQRSHRNB01000101 .. 1 . 00 1110 . .  @rd_rn_tszimm_shr
 UQRSHRNT01000101 .. 1 . 00  . .  @rd_rn_tszimm_shr
 
+### SVE2 Character Match
+
+MATCH   01000101 .. 1 . 100 ... . 0  @pd_pg_rn_rm
+NMATCH  01000101 .. 1 . 100 ... . 1  @pd_pg_rn_rm
+
 ## SVE2 floating-point pairwise operations
 
 FADDP   01100100 .. 010 00 0 100 ... . . @rdn_pg_rm
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index b68f62cd7f..c75258b56d 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -6890,3 +6890,32 @@ DO_ST1_ZPZ_D(dd_be, zd, MO_64)
 
 #undef DO_ST1_ZPZ_S
 #undef DO_ST1_ZPZ_D
+
+#define DO_ZPZZ_CHAR_MATCH(NAME, TYPE, H, EQUALS)\
+void HELPER(NAME)(void *vd, void *vn, void *vm, void *vg, uint32_t desc) \
+{\
+intptr_t i, opr_sz = simd_oprsz(desc);   \
+for (i = 0; i < opr_sz; i += sizeof(TYPE)) { \
+uint16_t pg = *(uint16_t *)(vg + H1_2(i >> 3));  \
+uint16_t *pd = (uint16_t *)(vd + H1_2(i >> 3));  \
+*pd = (*pd & ~1) | ((0 & EQUALS) | (1 & !EQUALS));   \
+if (pg & 1) {\
+TYPE nn = *(TYPE *)(vn + H(i));  \
+for (intptr_t j = 0; j < 16; j += sizeof(TYPE)) {\
+TYPE mm = *(TYPE *)(vm + H(i * 16 + j)); \
+bool eq = nn == mm;  \
+if ((eq && EQUALS) || (!eq && !EQUALS)) {\
+*pd = (*pd & ~1) | ((1 & EQUALS) | (0 & !EQUALS));   \
+}\
+}\
+}\
+}\
+}
+
+DO_ZPZZ_CHAR_MATCH(sve2_match_zpzz_b, uint8_t, H1, true)
+DO_ZPZZ_CHAR_MATCH(sve2_match_zpzz_h, uint16_t, H1_2, true)
+
+DO_ZPZZ_CHAR_MATCH(sve2_nmatch_zpzz_b, uint8_t, H1, false)
+DO_ZPZZ_CHAR_MATCH(sve2_nmatch_zpzz_h, uint16_t, H1_2, false)
+
+#undef DO_ZPZZ_CHAR_MATCH
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 07a2040208..7175148bfd 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -7246,6 +7246,49 @@ static bool trans_UQRSHRNT(DisasContext *s, arg_rri_esz 
*a)
 return do_sve2_shr_narrow(s, a, ops);
 }
 
+static bool do_sve2_zpzz_char_match(DisasContext *s, arg_rprr_esz *a,
+gen_helper_gvec_4 *fn)
+{
+if (!dc_isar_feature(aa64_sve2, s)) {
+return false;
+}
+if (fn == NULL) {
+return false;
+}
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+

Re: [PATCH 0/15] KVM: MIPS: Add Loongson-3 support (Host Side)

2020-04-13 Thread maobibo



On 04/13/2020 04:18 PM, Jiaxun Yang wrote:
> On Mon, 13 Apr 2020 15:30:09 +0800
> Huacai Chen  wrote:
> 
>> We are preparing to add KVM support for Loongson-3. VZ extension is
>> fully supported in Loongson-3A R4+, and we will not care about old
>> CPUs (at least now). We already have a full functional Linux kernel
>> (based on Linux-5.4.x LTS) and QEMU (based on 5.0.0-rc2) and their git
>> repositories are here:
>>
>> QEMU: https://github.com/chenhuacai/qemu
>> Kernel: https://github.com/chenhuacai/linux
>>
>> Of course these two repositories need to be rework and not suitable
>> for upstream (especially the commits need to be splitted). We show
>> them here is just to tell others what we have done, and how
>> KVM/Loongson will look like.
>>
>> Our plan is make the KVM host side be upstream first, and after that,
>> we will make the KVM guest side and QEMU emulator be upstream.
> 
> + Aleksandar as QEMU/MIPS mainatiner
> 
> I was involved in KVM/Loongson development a bit and also intend to
> help with mainline these works.
> 
> After dealing with basic LS7A PCH kernel support, I'm going to
> cooperate with Huacai and anyone who interested in to deal with
> following stuff:
> 
> - Basic QEMU/TCG support for Loongson64 instructions.
>   Well, it seems unrelated with KVM, but that would make
>   development easier with cross ISA emulation. I'm not going to
>   implement all the features like Loongson's page table fast walk
>   extension and binary translation extension but I'll ensure any
>   binary compiled with march=loongson3a can run flawlessly on
>   TCG.
> 
> - Design of Loongson-VIRT QEMU machine
>   It is nearly impossible to bring a real Loongson system into
>   QEMU. Both RS780E and LS7A PCH have tons of unreasonable design
>   that would make the emulation extremely complex, Loongson
>   company's KVM implementation[1] has already proofed that,
>   thay're now in the hell. So we all agreed that we should build
>   a machine from draft. I think we should reuse existing infra as
>   far as possible to reduce our work load. I'm planing to use
>   pci-host-cam-generic together with VIRTIO PCI devices and a
>   a strip down version of loongson,liointc-1.0a to build a pure
>   PCI based system. But if any one have better idea please just
>   tell us, I'm still considering how to implement SMP-IPI and ACPI
>   stuff.
It is a good job to add kvm virtualization support on loongson64 platform. I 
agree that we should define common virt machine hardware system, however the 
compiled kernel binary should be the same with host system, else it will bring 
out trouble for customers to differentiate them between guest system and host 
system.

For pci host bridge emulation, I suggest that gpex pcie host bridge should be 
used, since it supports pcie hotplug and arm/riscv uses this pcie host bridge.

For virtual interrupt controller, it should support MSI/MSIX interrupt, irqchip 
in kernel, IRQFD, vhost/vfio etc. I have no idea how to define virtual 
interrupt controller now.


regards
bibo,mao

> 
> - BIOS in VM
>   This has a lower priority. But BIOS is required to make a
>   emulated machine looks like a real machine. Loongson have their
>   open-sourced PMON and close-sourced UEFI(Based on tianocore).
>   I'd really with Loongson or Lemote will open-source their UEFI
>   but PMON is also a option.
> 
> Any kind of feedback is appreciated.
> 
> Thanks.
> 
> Wish you good health :-)
> 
> 
> [1]: http://cgit.loongnix.org/cgit/linux-3.10/ &
> http://cgit.loongnix.org/cgit/qemu-2.7.0/
> 
> Btw: I think Cc qemu-devel for the whole series is a little bit
> disturb, probably we should only Cc qemu-devel for the cover letter.
> 
>>
>> Mike Rapoport(1):
>>  mips: define pud_index() regardless of page table folding
>>
>> Xing Li(2):
>>  KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(_cpu_data)
>>  KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits
>>
>> Huacai Chen(12):
>>  KVM: MIPS: Increase KVM_MAX_VCPUS and KVM_USER_MEM_SLOTS to 16
>>  KVM: MIPS: Add EVENTFD support which is needed by VHOST
>>  KVM: MIPS: Use lddir/ldpte instructions to lookup gpa_mm.pgd
>>  KVM: MIPS: Introduce and use cpu_guest_has_ldpte
>>  KVM: MIPS: Use root tlb to control guest's CCA for Loongson-3
>>  KVM: MIPS: Let indexed cacheops cause guest exit on Loongson-3
>>  KVM: MIPS: Add more types of virtual interrupts
>>  KVM: MIPS: Add Loongson-3 Virtual IPI interrupt support
>>  KVM: MIPS: Add CPUCFG emulation for Loongson-3
>>  KVM: MIPS: Add CONFIG6 and DIAG registers emulation
>>  KVM: MIPS: Add more MMIO load/store instructions emulation
>>  KVM: MIPS: Enable KVM support for Loongson-3
>>
>> Signed-off-by: Huacai Chen 
>> ---
>>  arch/mips/Kconfig|   1 +
>>  arch/mips/include/asm/cpu-features.h |   3 +
>>  arch/mips/include/asm/kvm_host.h |  50 +++-
>>  arch/mips/include/asm/mipsregs.h |   7 +
>>  

Re: [PATCH 21/31] target/arm: Implement SVE2 integer absolute difference and accumulate long

2020-04-13 Thread Richard Henderson
On 4/13/20 9:15 AM, Laurent Desnogues wrote:
> On Fri, Mar 27, 2020 at 12:18 AM Richard Henderson
>  wrote:
> [...]
>> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
>> index a3653007ac..a0995d95c7 100644
>> --- a/target/arm/sve_helper.c
>> +++ b/target/arm/sve_helper.c
>> @@ -1216,6 +1216,30 @@ DO_ZZZ_NTB(sve2_eoril_d, uint64_t, , DO_EOR)
>>
>>  #undef DO_ZZZ_NTB
>>
>> +#define DO_ABAL(NAME, TYPE, TYPEN) \
>> +void HELPER(NAME)(void *vd, void *va, void *vn, void *vm, uint32_t desc) \
>> +{  \
>> +intptr_t i, opr_sz = simd_oprsz(desc); \
>> +int sel1 = (simd_data(desc) & 1) * sizeof(TYPE);   \
>> +int sel2 = (simd_data(desc) & 2) * (sizeof(TYPE) / 2); \
>> +for (i = 0; i < opr_sz; i += sizeof(TYPE)) {   \
>> +TYPE nn = (TYPEN)(*(TYPE *)(vn + i) >> sel1);  \
>> +TYPE mm = (TYPEN)(*(TYPE *)(vm + i) >> sel2);  \
>> +TYPE aa = *(TYPE *)(va + i);   \
>> +*(TYPE *)(vd + i) = DO_ABD(nn, mm) + aa;   \
>> +}  \
>> +}
> 
> ABAL is either top or bottom not a mix of two.  So only sel1 is needed
> and its multiplicand should be the number of bits of TYPEN.

Yep.

> vd is both a source and a destination so a temporary should be used.

In what way am I not?  Both sources are read before the write.  The operands
are all in columns of the wide type (unlike the addp case you pointed out).


r~



Re: [PATCH v19 QEMU 4/4] memory: Do not allow direct write access to rom_device regions

2020-04-13 Thread Alexander Duyck
On Fri, Apr 10, 2020 at 3:50 AM Paolo Bonzini  wrote:
>
> On 10/04/20 05:41, Alexander Duyck wrote:
> > From: Alexander Duyck 
> >
> > According to the documentation in memory.h a ROM memory region will be
> > backed by RAM for reads, but is supposed to go through a callback for
> > writes. Currently we were not checking for the existence of the rom_device
> > flag when determining if we could perform a direct write or not.
> >
> > To correct that add a check to memory_region_is_direct so that if the
> > memory region has the rom_device flag set we will return false for all
> > checks where is_write is set.
> >
> > Signed-off-by: Alexander Duyck 
> > ---
> >  include/exec/memory.h |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/exec/memory.h b/include/exec/memory.h
> > index 1614d9a02c0c..e000bd2f97b2 100644
> > --- a/include/exec/memory.h
> > +++ b/include/exec/memory.h
> > @@ -2351,8 +2351,8 @@ void 
> > address_space_write_cached_slow(MemoryRegionCache *cache,
> >  static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write)
> >  {
> >  if (is_write) {
> > -return memory_region_is_ram(mr) &&
> > -   !mr->readonly && !memory_region_is_ram_device(mr);
> > +return memory_region_is_ram(mr) && !mr->readonly &&
> > +   !mr->rom_device && !memory_region_is_ram_device(mr);
> >  } else {
> >  return (memory_region_is_ram(mr) && 
> > !memory_region_is_ram_device(mr)) ||
> > memory_region_is_romd(mr);
> >
>
> Good catch.  I queued this up for 5.0.
>
> Thanks,
>
> Paolo

Thanks Paolo,

It looks like you only pulled this patch correct?

If so, David & Michael, do I need to resubmit the first 3 in this
series or can those be pulled separately?

Thanks.

Alex



Re: [PATCH-for-5.1 v3 19/24] hw/riscv/sifive_e: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:45 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/riscv/sifive_e.c
>   >>> possible moves from riscv_sifive_e_soc_init() to 
> riscv_sifive_e_soc_realize() in ./hw/riscv/sifive_e.c:135
>
> Move the calls using _fatal which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/riscv/sifive_e.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index 646553a7c3..0be8b52147 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -118,7 +118,9 @@ static void riscv_sifive_e_init(MachineState *machine)
>  static void riscv_sifive_e_soc_init(Object *obj)
>  {
>  MachineState *ms = MACHINE(qdev_get_machine());
> +const struct MemmapEntry *memmap = sifive_e_memmap;
>  SiFiveESoCState *s = RISCV_E_SOC(obj);
> +MemoryRegion *sys_mem = get_system_memory();
>
>  object_initialize_child(obj, "cpus", >cpus,
>  sizeof(s->cpus), TYPE_RISCV_HART_ARRAY,
> @@ -130,6 +132,18 @@ static void riscv_sifive_e_soc_init(Object *obj)
>  sysbus_init_child_obj(obj, "riscv.sifive.e.gpio0",
>>gpio, sizeof(s->gpio),
>TYPE_SIFIVE_GPIO);
> +
> +/* Mask ROM */
> +memory_region_init_rom(>mask_rom, obj, "riscv.sifive.e.mrom",
> +   memmap[SIFIVE_E_MROM].size, _fatal);
> +memory_region_add_subregion(sys_mem,
> +memmap[SIFIVE_E_MROM].base, >mask_rom);
> +
> +/* Flash memory */
> +memory_region_init_rom(>xip_mem, obj, "riscv.sifive.e.xip",
> +   memmap[SIFIVE_E_XIP].size, _fatal);
> +memory_region_add_subregion(sys_mem, memmap[SIFIVE_E_XIP].base,
> +>xip_mem);
>  }
>
>  static void riscv_sifive_e_soc_realize(DeviceState *dev, Error **errp)
> @@ -144,12 +158,6 @@ static void riscv_sifive_e_soc_realize(DeviceState *dev, 
> Error **errp)
>  object_property_set_bool(OBJECT(>cpus), true, "realized",
>  _abort);
>
> -/* Mask ROM */
> -memory_region_init_rom(>mask_rom, OBJECT(dev), "riscv.sifive.e.mrom",
> -   memmap[SIFIVE_E_MROM].size, _fatal);
> -memory_region_add_subregion(sys_mem,
> -memmap[SIFIVE_E_MROM].base, >mask_rom);
> -
>  /* MMIO */
>  s->plic = sifive_plic_create(memmap[SIFIVE_E_PLIC].base,
>  (char *)SIFIVE_E_PLIC_HART_CONFIG,
> @@ -206,12 +214,6 @@ static void riscv_sifive_e_soc_realize(DeviceState *dev, 
> Error **errp)
>  memmap[SIFIVE_E_QSPI2].base, memmap[SIFIVE_E_QSPI2].size);
>  create_unimplemented_device("riscv.sifive.e.pwm2",
>  memmap[SIFIVE_E_PWM2].base, memmap[SIFIVE_E_PWM2].size);
> -
> -/* Flash memory */
> -memory_region_init_rom(>xip_mem, OBJECT(dev), "riscv.sifive.e.xip",
> -   memmap[SIFIVE_E_XIP].size, _fatal);
> -memory_region_add_subregion(sys_mem, memmap[SIFIVE_E_XIP].base,
> ->xip_mem);
>  }
>
>  static void riscv_sifive_e_machine_init(MachineClass *mc)
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 17/24] hw/microblaze/xlnx-zynqmp-pmu: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:44 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/microblaze/xlnx-zynqmp-pmu.c
>   >>> possible moves from xlnx_zynqmp_pmu_soc_init() to 
> xlnx_zynqmp_pmu_soc_realize() in ./hw/microblaze/xlnx-zynqmp-pmu.c:79
>
> Move the calls using _abort which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/microblaze/xlnx-zynqmp-pmu.c | 46 -
>  1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
> index 028f31894d..2aa602cf85 100644
> --- a/hw/microblaze/xlnx-zynqmp-pmu.c
> +++ b/hw/microblaze/xlnx-zynqmp-pmu.c
> @@ -63,24 +63,6 @@ static void xlnx_zynqmp_pmu_soc_init(Object *obj)
>
>  object_initialize_child(obj, "pmu-cpu", >cpu, sizeof(s->cpu),
>  TYPE_MICROBLAZE_CPU, _abort, NULL);
> -
> -sysbus_init_child_obj(obj, "intc", >intc, sizeof(s->intc),
> -  TYPE_XLNX_PMU_IO_INTC);
> -
> -/* Create the IPI device */
> -for (int i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) {
> -char *name = g_strdup_printf("ipi%d", i);
> -sysbus_init_child_obj(obj, name, >ipi[i],
> -  sizeof(XlnxZynqMPIPI), TYPE_XLNX_ZYNQMP_IPI);
> -g_free(name);
> -}
> -}
> -
> -static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, Error **errp)
> -{
> -XlnxZynqMPPMUSoCState *s = XLNX_ZYNQMP_PMU_SOC(dev);
> -Error *err = NULL;
> -
>  object_property_set_uint(OBJECT(>cpu), XLNX_ZYNQMP_PMU_ROM_ADDR,
>   "base-vectors", _abort);
>  object_property_set_bool(OBJECT(>cpu), true, "use-stack-protection",
> @@ -99,18 +81,36 @@ static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, 
> Error **errp)
>  object_property_set_str(OBJECT(>cpu), "8.40.b", "version",
>  _abort);
>  object_property_set_uint(OBJECT(>cpu), 0, "pvr", _abort);
> -object_property_set_bool(OBJECT(>cpu), true, "realized", );
> -if (err) {
> -error_propagate(errp, err);
> -return;
> -}
>
> +sysbus_init_child_obj(obj, "intc", >intc, sizeof(s->intc),
> +  TYPE_XLNX_PMU_IO_INTC);
>  object_property_set_uint(OBJECT(>intc), 0x10, "intc-intr-size",
>   _abort);
>  object_property_set_uint(OBJECT(>intc), 0x0, "intc-level-edge",
>   _abort);
>  object_property_set_uint(OBJECT(>intc), 0x, "intc-positive",
>   _abort);
> +
> +/* Create the IPI device */
> +for (int i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) {
> +char *name = g_strdup_printf("ipi%d", i);
> +sysbus_init_child_obj(obj, name, >ipi[i],
> +  sizeof(XlnxZynqMPIPI), TYPE_XLNX_ZYNQMP_IPI);
> +g_free(name);
> +}
> +}
> +
> +static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, Error **errp)
> +{
> +XlnxZynqMPPMUSoCState *s = XLNX_ZYNQMP_PMU_SOC(dev);
> +Error *err = NULL;
> +
> +object_property_set_bool(OBJECT(>cpu), true, "realized", );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
>  object_property_set_bool(OBJECT(>intc), true, "realized", );
>  if (err) {
>  error_propagate(errp, err);
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 21/24] hw/riscv/sifive_u: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:49 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/riscv/sifive_u.c
>   >>> possible moves from riscv_sifive_u_soc_init() to 
> riscv_sifive_u_soc_realize() in ./hw/riscv/sifive_u.c:473
>
> Move the calls using _abort which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/riscv/sifive_u.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 9c90c94c33..754af19eef 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -441,6 +441,8 @@ static void riscv_sifive_u_soc_init(Object *obj)
>  qdev_prop_set_uint32(DEVICE(>otp), "serial", OTP_SERIAL);
>  sysbus_init_child_obj(obj, "gem", >gem, sizeof(s->gem),
>TYPE_CADENCE_GEM);
> +object_property_set_int(OBJECT(>gem), GEM_REVISION, "revision",
> +_abort);
>  }
>
>  static bool sifive_u_get_start_in_flash(Object *obj, Error **errp)
> @@ -569,8 +571,6 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, 
> Error **errp)
>  qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
>  qdev_set_nic_properties(DEVICE(>gem), nd);
>  }
> -object_property_set_int(OBJECT(>gem), GEM_REVISION, "revision",
> -_abort);
>  object_property_set_bool(OBJECT(>gem), true, "realized", );
>  if (err) {
>  error_propagate(errp, err);
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 23/24] hw/riscv/sifive_u: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:48 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/riscv/sifive_u.c
>   >>> possible moves from riscv_sifive_u_soc_init() to 
> riscv_sifive_u_soc_realize() in ./hw/riscv/sifive_u.c:473
>
> Move the calls using _abort which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/riscv/sifive_u.c | 42 ++
>  1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 96177c1977..7bf1f30a35 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -406,6 +406,8 @@ static void riscv_sifive_u_init(MachineState *machine)
>  static void riscv_sifive_u_soc_init(Object *obj)
>  {
>  MachineState *ms = MACHINE(qdev_get_machine());
> +const struct MemmapEntry *memmap = sifive_u_memmap;
> +MemoryRegion *system_memory = get_system_memory();
>  SiFiveUSoCState *s = RISCV_U_SOC(obj);
>
>  object_initialize_child(obj, "e-cluster", >e_cluster,
> @@ -443,6 +445,26 @@ static void riscv_sifive_u_soc_init(Object *obj)
>TYPE_CADENCE_GEM);
>  object_property_set_int(OBJECT(>gem), GEM_REVISION, "revision",
>  _abort);
> +
> +/* boot rom */
> +memory_region_init_rom(>mask_rom, obj, "riscv.sifive.u.mrom",
> +   memmap[SIFIVE_U_MROM].size, _fatal);
> +memory_region_add_subregion(system_memory, memmap[SIFIVE_U_MROM].base,
> +>mask_rom);
> +
> +/*
> + * Add L2-LIM at reset size.
> + * This should be reduced in size as the L2 Cache Controller WayEnable
> + * register is incremented. Unfortunately I don't see a nice (or any) way
> + * to handle reducing or blocking out the L2 LIM while still allowing it
> + * be re returned to all enabled after a reset. For the time being, just
> + * leave it enabled all the time. This won't break anything, but will be
> + * too generous to misbehaving guests.
> + */
> +memory_region_init_ram(>l2lim_mem, NULL, "riscv.sifive.u.l2lim",
> +   memmap[SIFIVE_U_L2LIM].size, _fatal);
> +memory_region_add_subregion(system_memory, memmap[SIFIVE_U_L2LIM].base,
> +>l2lim_mem);
>  }
>
>  static bool sifive_u_get_start_in_flash(Object *obj, Error **errp)
> @@ -500,26 +522,6 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, 
> Error **errp)
>  object_property_set_bool(OBJECT(>u_cluster), true, "realized",
>   _abort);
>
> -/* boot rom */
> -memory_region_init_rom(>mask_rom, OBJECT(dev), "riscv.sifive.u.mrom",
> -   memmap[SIFIVE_U_MROM].size, _fatal);
> -memory_region_add_subregion(system_memory, memmap[SIFIVE_U_MROM].base,
> ->mask_rom);
> -
> -/*
> - * Add L2-LIM at reset size.
> - * This should be reduced in size as the L2 Cache Controller WayEnable
> - * register is incremented. Unfortunately I don't see a nice (or any) way
> - * to handle reducing or blocking out the L2 LIM while still allowing it
> - * be re returned to all enabled after a reset. For the time being, just
> - * leave it enabled all the time. This won't break anything, but will be
> - * too generous to misbehaving guests.
> - */
> -memory_region_init_ram(>l2lim_mem, NULL, "riscv.sifive.u.l2lim",
> -   memmap[SIFIVE_U_L2LIM].size, _fatal);
> -memory_region_add_subregion(system_memory, memmap[SIFIVE_U_L2LIM].base,
> ->l2lim_mem);
> -
>  /* create PLIC hart topology configuration string */
>  plic_hart_config_len = (strlen(SIFIVE_U_PLIC_HART_CONFIG) + 1) *
> ms->smp.cpus;
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 22/24] hw/riscv/sifive_u: Store MemoryRegion in SiFiveUSoCState

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:52 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/riscv/sifive_u.c
>   >>> possible moves from riscv_sifive_u_soc_init() to 
> riscv_sifive_u_soc_realize() in ./hw/riscv/sifive_u.c:473
>
> While reviewing we notice storing the MemoryRegion in the device
> state, we'll be able to later automatically simplify the error
> propagation calls.
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  include/hw/riscv/sifive_u.h |  2 ++
>  hw/riscv/sifive_u.c | 10 --
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/hw/riscv/sifive_u.h b/include/hw/riscv/sifive_u.h
> index 82667b5746..254c6a64f8 100644
> --- a/include/hw/riscv/sifive_u.h
> +++ b/include/hw/riscv/sifive_u.h
> @@ -42,6 +42,8 @@ typedef struct SiFiveUSoCState {
>  SiFiveUPRCIState prci;
>  SiFiveUOTPState otp;
>  CadenceGEMState gem;
> +MemoryRegion mask_rom;
> +MemoryRegion l2lim_mem;
>  } SiFiveUSoCState;
>
>  #define TYPE_RISCV_U_MACHINE MACHINE_TYPE_NAME("sifive_u")
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 754af19eef..96177c1977 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -478,8 +478,6 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, 
> Error **errp)
>  SiFiveUSoCState *s = RISCV_U_SOC(dev);
>  const struct MemmapEntry *memmap = sifive_u_memmap;
>  MemoryRegion *system_memory = get_system_memory();
> -MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
> -MemoryRegion *l2lim_mem = g_new(MemoryRegion, 1);
>  qemu_irq plic_gpios[SIFIVE_U_PLIC_NUM_SOURCES];
>  char *plic_hart_config;
>  size_t plic_hart_config_len;
> @@ -503,10 +501,10 @@ static void riscv_sifive_u_soc_realize(DeviceState 
> *dev, Error **errp)
>   _abort);
>
>  /* boot rom */
> -memory_region_init_rom(mask_rom, OBJECT(dev), "riscv.sifive.u.mrom",
> +memory_region_init_rom(>mask_rom, OBJECT(dev), "riscv.sifive.u.mrom",
> memmap[SIFIVE_U_MROM].size, _fatal);
>  memory_region_add_subregion(system_memory, memmap[SIFIVE_U_MROM].base,
> -mask_rom);
> +>mask_rom);
>
>  /*
>   * Add L2-LIM at reset size.
> @@ -517,10 +515,10 @@ static void riscv_sifive_u_soc_realize(DeviceState 
> *dev, Error **errp)
>   * leave it enabled all the time. This won't break anything, but will be
>   * too generous to misbehaving guests.
>   */
> -memory_region_init_ram(l2lim_mem, NULL, "riscv.sifive.u.l2lim",
> +memory_region_init_ram(>l2lim_mem, NULL, "riscv.sifive.u.l2lim",
> memmap[SIFIVE_U_L2LIM].size, _fatal);
>  memory_region_add_subregion(system_memory, memmap[SIFIVE_U_L2LIM].base,
> -l2lim_mem);
> +>l2lim_mem);
>
>  /* create PLIC hart topology configuration string */
>  plic_hart_config_len = (strlen(SIFIVE_U_PLIC_HART_CONFIG) + 1) *
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 10/23] hw/microblaze/xlnx-zynqmp-pmu: Add missing error-propagation code

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:58 PM Philippe Mathieu-Daudé  wrote:
>
> Patch created mechanically by running:
>
>   $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file scripts/coccinelle/use-error_propagate-in-realize.cocci \
> --keep-comments --smpl-spacing --in-place --dir hw
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/microblaze/xlnx-zynqmp-pmu.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
> index 2aa602cf85..4ecbea7fdc 100644
> --- a/hw/microblaze/xlnx-zynqmp-pmu.c
> +++ b/hw/microblaze/xlnx-zynqmp-pmu.c
> @@ -123,7 +123,11 @@ static void xlnx_zynqmp_pmu_soc_realize(DeviceState 
> *dev, Error **errp)
>  /* Connect the IPI device */
>  for (int i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) {
>  object_property_set_bool(OBJECT(>ipi[i]), true, "realized",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  sysbus_mmio_map(SYS_BUS_DEVICE(>ipi[i]), 0, ipi_addr[i]);
>  sysbus_connect_irq(SYS_BUS_DEVICE(>ipi[i]), 0,
> qdev_get_gpio_in(DEVICE(>intc), ipi_irq[i]));
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 24/24] hw/riscv/sifive_u: Rename MachineClass::init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:54 PM Philippe Mathieu-Daudé  wrote:
>
> As there already is the riscv_sifive_u_soc_init() method,
> rename riscv_sifive_u_init() as riscv_sifive_u_machine_init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/sifive_u.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 7bf1f30a35..e13ab34de4 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -312,7 +312,7 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  g_free(nodename);
>  }
>
> -static void riscv_sifive_u_init(MachineState *machine)
> +static void riscv_sifive_u_machine_init(MachineState *machine)
>  {
>  const struct MemmapEntry *memmap = sifive_u_memmap;
>  SiFiveUState *s = RISCV_U_MACHINE(machine);
> @@ -606,7 +606,7 @@ static void riscv_sifive_u_machine_class_init(ObjectClass 
> *oc, void *data)
>  MachineClass *mc = MACHINE_CLASS(oc);
>
>  mc->desc = "RISC-V Board compatible with SiFive U SDK";
> -mc->init = riscv_sifive_u_init;
> +mc->init = riscv_sifive_u_machine_init;
>  mc->max_cpus = SIFIVE_U_MANAGEMENT_CPU_COUNT + 
> SIFIVE_U_COMPUTE_CPU_COUNT;
>  mc->min_cpus = SIFIVE_U_MANAGEMENT_CPU_COUNT + 1;
>  mc->default_cpus = mc->min_cpus;
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 1/3] hw/ide/ahci: Use qdev gpio rather than qemu_allocate_irqs()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 2:29 PM Philippe Mathieu-Daudé  wrote:
>
> Switch to using the qdev gpio API which is preferred over
> qemu_allocate_irqs(). One step to eventually deprecate and
> remove qemu_allocate_irqs() one day.
>
> Patch created mechanically using spatch with this script
> inspired from commit d6ef883d9d7:
>
>   @@
>   typedef qemu_irq;
>   identifier irqs, handler;
>   expression opaque, count, i;
>   @@
>   -   qemu_irq *irqs;
>   ...
>   -   irqs = qemu_allocate_irqs(handler, opaque, count);
>   +   qdev_init_gpio_in(DEVICE(opaque), handler, count);
>   <+...
>   -   irqs[i]
>   +   qdev_get_gpio_in(DEVICE(opaque), i)
>   ...+>
>   ?-  g_free(irqs);
>
> Inspired-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/ide/ahci.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 13d91e109a..ef0a0a22ee 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1534,19 +1534,18 @@ void ahci_init(AHCIState *s, DeviceState *qdev)
>
>  void ahci_realize(AHCIState *s, DeviceState *qdev, AddressSpace *as, int 
> ports)
>  {
> -qemu_irq *irqs;
>  int i;
>
>  s->as = as;
>  s->ports = ports;
>  s->dev = g_new0(AHCIDevice, ports);
>  ahci_reg_init(s);
> -irqs = qemu_allocate_irqs(ahci_irq_set, s, s->ports);
> +qdev_init_gpio_in(DEVICE(s), ahci_irq_set, s->ports);
>  for (i = 0; i < s->ports; i++) {
>  AHCIDevice *ad = >dev[i];
>
>  ide_bus_new(>port, sizeof(ad->port), qdev, i, 1);
> -ide_init2(>port, irqs[i]);
> +ide_init2(>port, qdev_get_gpio_in(DEVICE(s), i));
>
>  ad->hba = s;
>  ad->port_no = i;
> @@ -1554,7 +1553,6 @@ void ahci_realize(AHCIState *s, DeviceState *qdev, 
> AddressSpace *as, int ports)
>  ad->port.dma->ops = _dma_ops;
>  ide_register_restart_cb(>port);
>  }
> -g_free(irqs);
>  }
>
>  void ahci_uninit(AHCIState *s)
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 07/23] hw/riscv/sifive: Add missing error-propagation code

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 4:00 PM Philippe Mathieu-Daudé  wrote:
>
> Patch created mechanically by running:
>
>   $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file scripts/coccinelle/use-error_propagate-in-realize.cocci \
> --keep-comments --smpl-spacing --in-place --dir hw
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/sifive_e.c |  6 +-
>  hw/riscv/sifive_u.c | 24 
>  2 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index 0be8b52147..6d4e141ff7 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -156,7 +156,11 @@ static void riscv_sifive_e_soc_realize(DeviceState *dev, 
> Error **errp)
>  MemoryRegion *sys_mem = get_system_memory();
>
>  object_property_set_bool(OBJECT(>cpus), true, "realized",
> -_abort);
> +);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>
>  /* MMIO */
>  s->plic = sifive_plic_create(memmap[SIFIVE_E_PLIC].base,
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index e13ab34de4..b07526aba1 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -508,9 +508,17 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, 
> Error **errp)
>  NICInfo *nd = _table[0];
>
>  object_property_set_bool(OBJECT(>e_cpus), true, "realized",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>u_cpus), true, "realized",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  /*
>   * The cluster must be realized after the RISC-V hart array container,
>   * as the container's CPU object is only created on realize, and the
> @@ -518,9 +526,17 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, 
> Error **errp)
>   * cluster is realized.
>   */
>  object_property_set_bool(OBJECT(>e_cluster), true, "realized",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>u_cluster), true, "realized",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>
>  /* create PLIC hart topology configuration string */
>  plic_hart_config_len = (strlen(SIFIVE_U_PLIC_HART_CONFIG) + 1) *
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 08/23] hw/arm/armv7m: Add missing error-propagation code

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:54 PM Philippe Mathieu-Daudé  wrote:
>
> Patch created mechanically by running:
>
>   $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file scripts/coccinelle/use-error_propagate-in-realize.cocci \
> --keep-comments --smpl-spacing --in-place --dir hw
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/arm/armv7m.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
> index 7531b97ccd..249a7605f6 100644
> --- a/hw/arm/armv7m.c
> +++ b/hw/arm/armv7m.c
> @@ -168,7 +168,11 @@ static void armv7m_realize(DeviceState *dev, Error 
> **errp)
>  }
>
>  object_property_set_link(OBJECT(s->cpu), OBJECT(>container), "memory",
> - _abort);
> + );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  if (object_property_find(OBJECT(s->cpu), "idau", NULL)) {
>  object_property_set_link(OBJECT(s->cpu), s->idau, "idau", );
>  if (err != NULL) {
> @@ -256,7 +260,11 @@ static void armv7m_realize(DeviceState *dev, Error 
> **errp)
>  return;
>  }
>  object_property_set_link(obj, OBJECT(s->board_memory),
> - "source-memory", _abort);
> + "source-memory", );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  object_property_set_bool(obj, true, "realized", );
>  if (err != NULL) {
>  error_propagate(errp, err);
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 20/24] hw/riscv/sifive_u: Use single type_init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:48 PM Philippe Mathieu-Daudé  wrote:
>
> We can use a single type_init() to call multiple type_register*().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/sifive_u.c | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 998666c91f..9c90c94c33 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -601,13 +601,6 @@ static const TypeInfo riscv_sifive_u_soc_type_info = {
>  .class_init = riscv_sifive_u_soc_class_init,
>  };
>
> -static void riscv_sifive_u_soc_register_types(void)
> -{
> -type_register_static(_sifive_u_soc_type_info);
> -}
> -
> -type_init(riscv_sifive_u_soc_register_types)
> -
>  static void riscv_sifive_u_machine_class_init(ObjectClass *oc, void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
> @@ -627,9 +620,10 @@ static const TypeInfo riscv_sifive_u_machine_typeinfo = {
>  .instance_size = sizeof(SiFiveUState),
>  };
>
> -static void riscv_sifive_u_machine_init_register_types(void)
> +static void riscv_sifive_u_register_types(void)
>  {
> +type_register_static(_sifive_u_soc_type_info);
>  type_register_static(_sifive_u_machine_typeinfo);
>  }
>
> -type_init(riscv_sifive_u_machine_init_register_types)
> +type_init(riscv_sifive_u_register_types)
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 16/24] hw/arm/xlnx-zynqmp: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:41 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle failed at processing this file:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/xlnx-zynqmp.c
>   EXN: Coccinelle_modules.Common.Timeout
>
> Move the calls using _abort which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/arm/xlnx-zynqmp.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
> index 457057198a..5ec9c24ee7 100644
> --- a/hw/arm/xlnx-zynqmp.c
> +++ b/hw/arm/xlnx-zynqmp.c
> @@ -242,6 +242,11 @@ static void xlnx_zynqmp_init(Object *obj)
>  >apu_cpu[i], sizeof(s->apu_cpu[i]),
>  ARM_CPU_TYPE_NAME("cortex-a53"),
>  _abort, NULL);
> +
> +object_property_set_int(OBJECT(>apu_cpu[i]), 
> QEMU_PSCI_CONDUIT_SMC,
> +"psci-conduit", _abort);
> +object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
> +"reset-cbar", _abort);
>  }
>
>  sysbus_init_child_obj(obj, "gic", >gic, sizeof(s->gic),
> @@ -250,6 +255,10 @@ static void xlnx_zynqmp_init(Object *obj)
>  for (i = 0; i < XLNX_ZYNQMP_NUM_GEMS; i++) {
>  sysbus_init_child_obj(obj, "gem[*]", >gem[i], sizeof(s->gem[i]),
>TYPE_CADENCE_GEM);
> +object_property_set_int(OBJECT(>gem[i]), GEM_REVISION, "revision",
> +_abort);
> +object_property_set_int(OBJECT(>gem[i]), 2, "num-priority-queues",
> +_abort);
>  }
>
>  for (i = 0; i < XLNX_ZYNQMP_NUM_UARTS; i++) {
> @@ -259,6 +268,8 @@ static void xlnx_zynqmp_init(Object *obj)
>
>  sysbus_init_child_obj(obj, "sata", >sata, sizeof(s->sata),
>TYPE_SYSBUS_AHCI);
> +object_property_set_int(OBJECT(>sata), SATA_NUM_PORTS, "num-ports",
> +_abort);
>
>  for (i = 0; i < XLNX_ZYNQMP_NUM_SDHCI; i++) {
>  sysbus_init_child_obj(obj, "sdhci[*]", >sdhci[i],
> @@ -370,9 +381,6 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  for (i = 0; i < num_apus; i++) {
>  char *name;
>
> -object_property_set_int(OBJECT(>apu_cpu[i]), 
> QEMU_PSCI_CONDUIT_SMC,
> -"psci-conduit", _abort);
> -
>  name = object_get_canonical_path_component(OBJECT(>apu_cpu[i]));
>  if (strcmp(name, boot_cpu)) {
>  /* Secondary CPUs start in PSCI powered-down state */
> @@ -387,8 +395,6 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>   s->secure, "has_el3", NULL);
>  object_property_set_bool(OBJECT(>apu_cpu[i]),
>   s->virt, "has_el2", NULL);
> -object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
> -"reset-cbar", _abort);
>  object_property_set_int(OBJECT(>apu_cpu[i]), num_apus,
>  "core-count", _abort);
>  object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
> @@ -490,10 +496,6 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
>  qdev_set_nic_properties(DEVICE(>gem[i]), nd);
>  }
> -object_property_set_int(OBJECT(>gem[i]), GEM_REVISION, "revision",
> -_abort);
> -object_property_set_int(OBJECT(>gem[i]), 2, "num-priority-queues",
> -_abort);
>  object_property_set_bool(OBJECT(>gem[i]), true, "realized", );
>  if (err) {
>  goto out_propagate_error;
> @@ -514,8 +516,6 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
> gic_spi[uart_intr[i]]);
>  }
>
> -object_property_set_int(OBJECT(>sata), SATA_NUM_PORTS, "num-ports",
> -_abort);
>  object_property_set_bool(OBJECT(>sata), true, "realized", );
>  if (err) {
>  goto out_propagate_error;
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 14/24] hw/arm/xlnx-zynqmp: Use single propagate_error() call

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:45 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle failed at processing this file:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/xlnx-zynqmp.c
>   EXN: Coccinelle_modules.Common.Timeout
>
> We are going to manually add the missing propagate_error() calls.
> As there are many Error* calls used, simplify by using an unique
> call to propagate_error().

I'm not a huge fan of goto's so I'm not sure this is simpler.

Alistair

>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/arm/xlnx-zynqmp.c | 61 +---
>  1 file changed, 23 insertions(+), 38 deletions(-)
>
> diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
> index b84d153d56..43d57fa7de 100644
> --- a/hw/arm/xlnx-zynqmp.c
> +++ b/hw/arm/xlnx-zynqmp.c
> @@ -385,15 +385,13 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
>   );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  }
>
>  object_property_set_bool(OBJECT(>gic), true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>
>  assert(ARRAY_SIZE(xlnx_zynqmp_gic_regions) == XLNX_ZYNQMP_GIC_REGIONS);
> @@ -462,8 +460,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>
>  xlnx_zynqmp_create_rpu(ms, s, boot_cpu, );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>
>  if (!s->boot_cpu_ptr) {
> @@ -488,8 +485,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  _abort);
>  object_property_set_bool(OBJECT(>gem[i]), true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  sysbus_mmio_map(SYS_BUS_DEVICE(>gem[i]), 0, gem_addr[i]);
>  sysbus_connect_irq(SYS_BUS_DEVICE(>gem[i]), 0,
> @@ -500,8 +496,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  qdev_prop_set_chr(DEVICE(>uart[i]), "chardev", serial_hd(i));
>  object_property_set_bool(OBJECT(>uart[i]), true, "realized", 
> );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  sysbus_mmio_map(SYS_BUS_DEVICE(>uart[i]), 0, uart_addr[i]);
>  sysbus_connect_irq(SYS_BUS_DEVICE(>uart[i]), 0,
> @@ -512,8 +507,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>  _abort);
>  object_property_set_bool(OBJECT(>sata), true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>
>  sysbus_mmio_map(SYS_BUS_DEVICE(>sata), 0, SATA_ADDR);
> @@ -531,23 +525,19 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>   */
>  object_property_set_uint(sdhci, 3, "sd-spec-version", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  object_property_set_uint(sdhci, SDHCI_CAPABILITIES, "capareg", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  object_property_set_uint(sdhci, UHS_I, "uhs", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  object_property_set_bool(sdhci, true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  sysbus_mmio_map(sbd, 0, sdhci_addr[i]);
>  sysbus_connect_irq(sbd, 0, gic_spi[sdhci_intr[i]]);
> @@ -564,8 +554,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>
>  object_property_set_bool(OBJECT(>spi[i]), true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>
>  sysbus_mmio_map(SYS_BUS_DEVICE(>spi[i]), 0, spi_addr[i]);
> @@ -582,8 +571,7 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>
>  object_property_set_bool(OBJECT(>qspi), true, "realized", );
>  if (err) {
> -error_propagate(errp, err);
> -return;
> +goto out_propagate_error;
>  }
>  sysbus_mmio_map(SYS_BUS_DEVICE(>qspi), 0, QSPI_ADDR);
>  sysbus_mmio_map(SYS_BUS_DEVICE(>qspi), 1, 

Re: [PATCH-for-5.1 v3 13/24] hw/arm/stm32f205_soc: Move some code from realize() to init()

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:42 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/stm32f205_soc.c
>   >>> possible moves from stm32f205_soc_initfn() to stm32f205_soc_realize() 
> in ./hw/arm/stm32f205_soc.c:83
>
> Move the calls using _fatal which don't depend on input
> updated before realize() to init().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/arm/stm32f205_soc.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> index 42f4e44134..76b0b0e9be 100644
> --- a/hw/arm/stm32f205_soc.c
> +++ b/hw/arm/stm32f205_soc.c
> @@ -49,6 +49,7 @@ static const int spi_irq[STM_NUM_SPIS] = {35, 36, 51};
>  static void stm32f205_soc_initfn(Object *obj)
>  {
>  STM32F205State *s = STM32F205_SOC(obj);
> +MemoryRegion *system_memory = get_system_memory();
>  int i;
>
>  sysbus_init_child_obj(obj, "armv7m", >armv7m, sizeof(s->armv7m),
> @@ -78,6 +79,14 @@ static void stm32f205_soc_initfn(Object *obj)
>  sysbus_init_child_obj(obj, "spi[*]", >spi[i], sizeof(s->spi[i]),
>TYPE_STM32F2XX_SPI);
>  }
> +
> +memory_region_init_ram(>sram, NULL, "STM32F205.sram", SRAM_SIZE,
> +   _fatal);
> +memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
> +
> +memory_region_init_rom(>flash, obj, "STM32F205.flash",
> +   FLASH_SIZE, _fatal);
> +memory_region_add_subregion(system_memory, FLASH_BASE_ADDRESS, 
> >flash);
>  }
>
>  static void stm32f205_soc_realize(DeviceState *dev_soc, Error **errp)
> @@ -87,19 +96,10 @@ static void stm32f205_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>  SysBusDevice *busdev;
>  Error *err = NULL;
>  int i;
> -MemoryRegion *system_memory = get_system_memory();
>
> -memory_region_init_rom(>flash, OBJECT(dev_soc), "STM32F205.flash",
> -   FLASH_SIZE, _fatal);
>  memory_region_init_alias(>flash_alias, OBJECT(dev_soc),
>   "STM32F205.flash.alias", >flash, 0, 
> FLASH_SIZE);
> -
> -memory_region_add_subregion(system_memory, FLASH_BASE_ADDRESS, 
> >flash);
> -memory_region_add_subregion(system_memory, 0, >flash_alias);
> -
> -memory_region_init_ram(>sram, NULL, "STM32F205.sram", SRAM_SIZE,
> -   _fatal);
> -memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
> +memory_region_add_subregion(get_system_memory(), 0, >flash_alias);
>
>  armv7m = DEVICE(>armv7m);
>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> --
> 2.21.1
>
>



Re: [PATCH] MAINTAINERS: Add myself as vhost-user-blk maintainer

2020-04-13 Thread Philippe Mathieu-Daudé
On 4/10/20 2:28 AM, Raphael Norwitz wrote:
> Ping

FYI this patch has been recently merged as commit
b372d79b236a4e07eaa3ce65ee0543569b712326.

> 
> On Thu, Mar 26, 2020 at 04:47:35AM -0400, Raphael Norwitz wrote:
>> As suggested by Michael, let's add me as a maintainer of
>> vhost-user-blk and vhost-user-scsi.
>>
>> CC: Michael S. Tsirkin 
>> CC Peter Maydell 
>> Signed-off-by: Raphael Norwitz 
>> ---
>>  MAINTAINERS | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e580276..239ecc1 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1845,6 +1845,18 @@ F: hw/display/virtio-gpu*
>>  F: hw/display/virtio-vga.*
>>  F: include/hw/virtio/virtio-gpu.h
>>  
>> +vhost-user-blk
>> +M: Raphael Norwitz 
>> +S: Maintained
>> +F: contrib/vhost-user-blk/
>> +F: contrib/vhost-user-scsi/
>> +F: hw/block/vhost-user-blk.c
>> +F: hw/scsi/vhost-user-scsi.c
>> +F: hw/virtio/vhost-user-blk-pci.c
>> +F: hw/virtio/vhost-user-scsi-pci.c
>> +F: include/hw/virtio/vhost-user-blk.h
>> +F: include/hw/virtio/vhost-user-scsi.h
>> +
>>  vhost-user-gpu
>>  M: Marc-André Lureau 
>>  M: Gerd Hoffmann 
>> -- 
>> 1.8.3.1
> 



Re: [PATCH-for-5.1 v3 12/24] hw/arm/stm32f205_soc: Store MemoryRegion in STM32F205State

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:41 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/stm32f205_soc.c
>   >>> possible moves from stm32f205_soc_initfn() to stm32f205_soc_realize() 
> in ./hw/arm/stm32f205_soc.c:83
>
> While reviewing we notice storing the MemoryRegion in the device
> state, we'll be able to later automatically simplify the error
> propagation calls.
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  include/hw/arm/stm32f205_soc.h |  4 
>  hw/arm/stm32f205_soc.c | 18 +++---
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/hw/arm/stm32f205_soc.h b/include/hw/arm/stm32f205_soc.h
> index 922a733f88..63e7e7c825 100644
> --- a/include/hw/arm/stm32f205_soc.h
> +++ b/include/hw/arm/stm32f205_soc.h
> @@ -56,6 +56,10 @@ typedef struct STM32F205State {
>
>  ARMv7MState armv7m;
>
> +MemoryRegion sram;
> +MemoryRegion flash;
> +MemoryRegion flash_alias;
> +
>  STM32F2XXSyscfgState syscfg;
>  STM32F2XXUsartState usart[STM_NUM_USARTS];
>  STM32F2XXTimerState timer[STM_NUM_TIMERS];
> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> index 118c342559..42f4e44134 100644
> --- a/hw/arm/stm32f205_soc.c
> +++ b/hw/arm/stm32f205_soc.c
> @@ -87,23 +87,19 @@ static void stm32f205_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>  SysBusDevice *busdev;
>  Error *err = NULL;
>  int i;
> -
>  MemoryRegion *system_memory = get_system_memory();
> -MemoryRegion *sram = g_new(MemoryRegion, 1);
> -MemoryRegion *flash = g_new(MemoryRegion, 1);
> -MemoryRegion *flash_alias = g_new(MemoryRegion, 1);
>
> -memory_region_init_rom(flash, OBJECT(dev_soc), "STM32F205.flash",
> +memory_region_init_rom(>flash, OBJECT(dev_soc), "STM32F205.flash",
> FLASH_SIZE, _fatal);
> -memory_region_init_alias(flash_alias, OBJECT(dev_soc),
> - "STM32F205.flash.alias", flash, 0, FLASH_SIZE);
> +memory_region_init_alias(>flash_alias, OBJECT(dev_soc),
> + "STM32F205.flash.alias", >flash, 0, 
> FLASH_SIZE);
>
> -memory_region_add_subregion(system_memory, FLASH_BASE_ADDRESS, flash);
> -memory_region_add_subregion(system_memory, 0, flash_alias);
> +memory_region_add_subregion(system_memory, FLASH_BASE_ADDRESS, 
> >flash);
> +memory_region_add_subregion(system_memory, 0, >flash_alias);
>
> -memory_region_init_ram(sram, NULL, "STM32F205.sram", SRAM_SIZE,
> +memory_region_init_ram(>sram, NULL, "STM32F205.sram", SRAM_SIZE,
> _fatal);
> -memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, sram);
> +memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
>
>  armv7m = DEVICE(>armv7m);
>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 11/24] hw/arm/msf2-soc: Store MemoryRegion in MSF2State

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:40 PM Philippe Mathieu-Daudé  wrote:
>
> Coccinelle reported:
>
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/msf2-soc.c
>   >>> possible moves from m2sxxx_soc_initfn() to m2sxxx_soc_realize() in 
> ./hw/arm/msf2-soc.c:86
>
> While reviewing we notice storing the MemoryRegion in the device
> state, we'll be able to later automatically simplify the error
> propagation calls.
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  include/hw/arm/msf2-soc.h |  4 
>  hw/arm/msf2-soc.c | 18 +++---
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/hw/arm/msf2-soc.h b/include/hw/arm/msf2-soc.h
> index 3cfe5c76ee..e4c5110036 100644
> --- a/include/hw/arm/msf2-soc.h
> +++ b/include/hw/arm/msf2-soc.h
> @@ -50,6 +50,10 @@ typedef struct MSF2State {
>
>  ARMv7MState armv7m;
>
> +MemoryRegion sram;
> +MemoryRegion nvm;
> +MemoryRegion nvm_alias;
> +
>  char *cpu_type;
>  char *part_name;
>  uint64_t envm_size;
> diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
> index 588d643b8d..e448b0ab74 100644
> --- a/hw/arm/msf2-soc.c
> +++ b/hw/arm/msf2-soc.c
> @@ -90,13 +90,9 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, Error 
> **errp)
>  SysBusDevice *busdev;
>  Error *err = NULL;
>  int i;
> -
>  MemoryRegion *system_memory = get_system_memory();
> -MemoryRegion *nvm = g_new(MemoryRegion, 1);
> -MemoryRegion *nvm_alias = g_new(MemoryRegion, 1);
> -MemoryRegion *sram = g_new(MemoryRegion, 1);
>
> -memory_region_init_rom(nvm, OBJECT(dev_soc), "MSF2.eNVM", s->envm_size,
> +memory_region_init_rom(>nvm, OBJECT(dev_soc), "MSF2.eNVM", 
> s->envm_size,
> _fatal);
>  /*
>   * On power-on, the eNVM region 0x6000 is automatically
> @@ -104,15 +100,15 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>   * start address (0x0). We do not support remapping other eNVM,
>   * eSRAM and DDR regions by guest(via Sysreg) currently.
>   */
> -memory_region_init_alias(nvm_alias, OBJECT(dev_soc), "MSF2.eNVM", nvm, 0,
> - s->envm_size);
> +memory_region_init_alias(>nvm_alias, OBJECT(dev_soc), "MSF2.eNVM",
> + >nvm, 0, s->envm_size);
>
> -memory_region_add_subregion(system_memory, ENVM_BASE_ADDRESS, nvm);
> -memory_region_add_subregion(system_memory, 0, nvm_alias);
> +memory_region_add_subregion(system_memory, ENVM_BASE_ADDRESS, >nvm);
> +memory_region_add_subregion(system_memory, 0, >nvm_alias);
>
> -memory_region_init_ram(sram, NULL, "MSF2.eSRAM", s->esram_size,
> +memory_region_init_ram(>sram, NULL, "MSF2.eSRAM", s->esram_size,
> _fatal);
> -memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, sram);
> +memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
>
>  armv7m = DEVICE(>armv7m);
>  qdev_prop_set_uint32(armv7m, "num-irq", 81);
> --
> 2.21.1
>
>



Re: [PATCH 3/3] MAINTAINERS: Add myself as fulong2e co-maintainer

2020-04-13 Thread Philippe Mathieu-Daudé
On 4/10/20 4:37 PM, Aleksandar Markovic wrote:
> 04:39 Čet, 09.04.2020. Jiaxun Yang  > је написао/ла:
>>
>> On Thu, 9 Apr 2020 10:17:46 +0800
>> Huacai Chen mailto:che...@lemote.com>> wrote:
>>
>> > Hi, Aleksandar,
>> >
>> > On Wed, Apr 8, 2020 at 11:30 PM Aleksandar Markovic
>> >  > wrote:
>> > >
>> > > 11:08 Sre, 08.04.2020. Huacai Chen  > је
>> > > написао/ла: 
>> > > >
>> > > > I submitted the MIPS/fulong2e support about ten years ago, and
>> > > > after that I became a MIPS kernel developer. Last year, Philippe
>> > > > Mathieu- Daudé asked me that whether I can be a reviewer of
>> > > > MIPS/fulong2e, and I promised that I will do some QEMU work in
>> > > > the next year (i.e., 2020 and later). I think now (and also in
>> > > > future) I can have some spare time, so I can finally do some real
>> > > > work on QEMU/MIPS. And if possible, I hope I can be a
>> > > > co-maintainer of MIPS/fulong2e.
>> > > >
>> > > > Cc: Jiaxun Yang  >
>> > > > Signed-off-by: Huacai Chen  >
>> > > > ---
>> > > >  MAINTAINERS | 1 +
>> > > >  1 file changed, 1 insertion(+)
>> > > >
>> > > > diff --git a/MAINTAINERS b/MAINTAINERS
>> > > > index 642c8e0..3281ff2 100644
>> > > > --- a/MAINTAINERS
>> > > > +++ b/MAINTAINERS
>> > > > @@ -1073,6 +1073,7 @@ F: hw/mips/mips_r4k.c
>> > > >  Fulong 2E
>> > > >  M: Philippe Mathieu-Daudé  >
>> > > >  M: Aleksandar Markovic  >
>> > > > +M: Huacai Chen mailto:che...@lemote.com>>
>> > > >  S: Odd Fixes
>> > > >  F: hw/mips/mips_fulong2e.c
>> > > >  F: hw/isa/vt82c686.c
>> > > > --
>> > > > 2.7.0
>> > > > 
>> > >
>> > > First of all, I want to express great pleasure and delight seing
>> > > your series, and this patch in particular.
>> > >
>> > > A warm welcome to QEMU developers communities!
>> > >
>> > > We are currenyly very busy preparing QEMU 5.0 release, and
>> > > additionaly, Easter holidays are in next few days or week
>> > > (different parts od Christian world have different calendars), so,
>> > > fot thay and other reasons, don't expect promot replies from us.
>> > >
>> > > I would also like to see Jiaxng at least having official reviewer
>> > > status, but, of course, only if he wants that. 
>> > Thank you for your best wishes, I'm also very glad to see Jiaxun be
>> > an reviewer.
>>
>> Thanks, but I was a primary school student at Loongson-2E's era, so I
>> can do nothing with 2E.
>>
>> My experience with Loongson starts from 2F. And I'm more familiar with
>> 2K and 3A.

Thank you both of you, your help is very welcome :)

I have a simple series renaming "fulo[o]ng" I plan to send when the 5.1
development window opens, I'll include your patch.

>>
> 
> OK, it makes sense. But, if you ever become wanting to be a reviewer for
> Foolong 2e, just give me an email.
> 
>> I'm happy to contribute QEMU support for these platforms.
>>
> 
> I am happy as well.
> 
> Best wishes and best health to you, people from China, and the whole
> region!!
> 
> Yours,
> Aleksandar
> 
>> Thanks.
>>
>> >
>> > Regards,
>> > Huacai
>> > >
>> > > Yours,
>> > > and wishing you and all people from China best health!
>> > >
>> > > Aleksandar 
>>
>> --
>> Jiaxun Yang
> 



[PATCH-for-5.0 v2] hw/display/sm501: Avoid heap overflow in sm501_2d_operation()

2020-04-13 Thread Philippe Mathieu-Daudé
Zhang Zi Ming reported a heap overflow in the Drawing Engine of
the SM501 companion chip model, in particular in the COPY_AREA()
macro in sm501_2d_operation().

Add a simple check to avoid the heap overflow.

This fixes:

  =
  ==20518==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x7f6f4c3f at pc 0x55b1e1d358f0 bp 0x7ffce464dfb0 sp 0x7ffce464dfa8
  READ of size 1 at 0x7f6f4c3f thread T0
  #0 0x55b1e1d358ef in sm501_2d_operation hw/display/sm501.c:788:13
  #1 0x55b1e1d32c38 in sm501_2d_engine_write hw/display/sm501.c:1466:13
  #2 0x55b1e0cd19d8 in memory_region_write_accessor memory.c:483:5
  #3 0x55b1e0cd1404 in access_with_adjusted_size memory.c:544:18
  #4 0x55b1e0ccfb9d in memory_region_dispatch_write memory.c:1476:16
  #5 0x55b1e0ae55a8 in flatview_write_continue exec.c:3125:23
  #6 0x55b1e0ad3e87 in flatview_write exec.c:3165:14
  #7 0x55b1e0ad3a24 in address_space_write exec.c:3256:18

  0x7f6f4c3f is located 4194303 bytes to the right of 4194304-byte region 
[0x7f6f4bc0,0x7f6f4c00)
  allocated by thread T0 here:
  #0 0x55b1e0a6e715 in __interceptor_posix_memalign 
(ppc64-softmmu/qemu-system-ppc64+0x19c0715)
  #1 0x55b1e31c1482 in qemu_try_memalign util/oslib-posix.c:189:11
  #2 0x55b1e31c168c in qemu_memalign util/oslib-posix.c:205:27
  #3 0x55b1e11a00b3 in spapr_reallocate_hpt hw/ppc/spapr.c:1560:23
  #4 0x55b1e11a0ce4 in spapr_setup_hpt hw/ppc/spapr.c:1593:5
  #5 0x55b1e11c2fba in spapr_machine_reset hw/ppc/spapr.c:1644:9
  #6 0x55b1e1368b01 in qemu_system_reset softmmu/vl.c:1391:9
  #7 0x55b1e1375af3 in qemu_init softmmu/vl.c:4436:5
  #8 0x55b1e2fc8a59 in main softmmu/main.c:48:5
  #9 0x7f6f8150bf42 in __libc_start_main (/lib64/libc.so.6+0x23f42)

  SUMMARY: AddressSanitizer: heap-buffer-overflow hw/display/sm501.c:788:13 in 
sm501_2d_operation
  Shadow bytes around the buggy address:
0x0fee69877fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fee69877fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fee69877fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fee69877fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fee69877fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  =>0x0fee69877ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
0x0fee69878000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee69878010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee69878020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee69878030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee69878040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable:   00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone:   fa
Freed heap region:   fd
Poisoned by user:f7
ASan internal:   fe
  ==20518==ABORTING

Cc: qemu-sta...@nongnu.org
Fixes: 07d8a50cb0e ("sm501: add 2D engine copyrect support")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1786026
Reported-by: Zhang Zi Ming <1015138...@qq.com>
Acked-by: BALATON Zoltan 
Signed-off-by: Philippe Mathieu-Daudé 
---
Since v1: Reword description & add Zoltan's A-b.

Test to verify this bug:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg695421.html

Per the links on
https://bugzilla.redhat.com/show_bug.cgi?id=1808510 there is probably
a CVE assigned to this, but I don't have access to the information,
https://bugzilla.redhat.com/show_bug.cgi?id=1786593 only show:

  You are not authorized to access bug #1786593.
  Most likely the bug has been restricted for internal development processes 
and we cannot grant access.

Anyway as this code is not used in conjunction with a hypervisor,
it is not a 'security bug' as described in
https://www.qemu.org/contribute/security-process/ and
https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
---
 hw/display/sm501.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index de0ab9d977..902acb3875 100644
--- a/hw/display/sm501.c
+++ b/hw/display/sm501.c
@@ -726,6 +726,12 @@ static void sm501_2d_operation(SM501State *s)
 int crt = (s->dc_crt_control & SM501_DC_CRT_CONTROL_SEL) ? 1 : 0;
 int fb_len = get_width(s, crt) * get_height(s, crt) * get_bpp(s, crt);
 
+if (rtl && (src_x < operation_width || src_y < operation_height)) {
+qemu_log_mask(LOG_GUEST_ERROR, "sm501: Illegal RTL address (%i, %i)\n",
+  src_x, src_y);
+return;
+}
+
 if (addressing != 0x0) {
 printf("%s: only XY addressing is supported.\n", __func__);
 abort();
-- 
2.21.1




Re: [PATCH] .gitignore: include common build sub-directories

2020-04-13 Thread Philippe Mathieu-Daudé
On 4/13/20 11:42 PM, Eric Blake wrote:
> On 4/13/20 4:32 PM, Alex Bennée wrote:
>>
>> Eric Blake  writes:
>>
>>> On 4/13/20 11:29 AM, Alex Bennée wrote:
 As out-of-tree builds become more common (or rather building in a
 subdir) we can add a lot of load to "git ls-files" as it hunts down
 sub-directories that are irrelevant to the source tree. This is
 especially annoying if you have a prompt that attempts to summarise
 the current git status on command completion.
 Signed-off-by: Alex Bennée 
 ---
    .gitignore | 2 ++
    1 file changed, 2 insertions(+)
 diff --git a/.gitignore b/.gitignore
 index 0c5af83aa74..7757dc08a08 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -141,6 +141,8 @@ cscope.*
    tags
    TAGS
    docker-src.*
 +build
 +builds
>>>
>>> Would 'build-*' be worth adding as well?
>>
>> Sure - I'll add it to v2.
> 
> Or even consolidate it into a single pattern: build* (which would allow
> 'build', 'builds', 'build1', 'build23', 'build-fedora', 'build-bug1234',
> ...)

Using 'build*':
Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH] .gitignore: include common build sub-directories

2020-04-13 Thread Eric Blake

On 4/13/20 4:32 PM, Alex Bennée wrote:


Eric Blake  writes:


On 4/13/20 11:29 AM, Alex Bennée wrote:

As out-of-tree builds become more common (or rather building in a
subdir) we can add a lot of load to "git ls-files" as it hunts down
sub-directories that are irrelevant to the source tree. This is
especially annoying if you have a prompt that attempts to summarise
the current git status on command completion.
Signed-off-by: Alex Bennée 
---
   .gitignore | 2 ++
   1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index 0c5af83aa74..7757dc08a08 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,6 +141,8 @@ cscope.*
   tags
   TAGS
   docker-src.*
+build
+builds


Would 'build-*' be worth adding as well?


Sure - I'll add it to v2.


Or even consolidate it into a single pattern: build* (which would allow 
'build', 'builds', 'build1', 'build23', 'build-fedora', 'build-bug1234', 
...)


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




[PATCH-for-5.1 v3 2/7] various: Use _abort in instance_init()

2020-04-13 Thread Philippe Mathieu-Daudé
Patch created mechanically by running:

  $ spatch \
--macro-file scripts/cocci-macro-file.h \
--include-headers --keep-comments --in-place \
--sp-file \
  scripts/coccinelle/use-error_abort-in-instance_init.cocci

Reviewed-by: Cédric Le Goater 
Acked-by: Cornelia Huck 
Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Include "qapi/error.h" in spapr_llan.c and test-qdev-global-props.c
---
 backends/cryptodev-vhost-user.c |  2 +-
 backends/rng-egd.c  |  2 +-
 backends/rng-random.c   |  2 +-
 backends/vhost-user.c   |  3 ++-
 hw/arm/bcm2835_peripherals.c|  6 --
 hw/arm/vexpress.c   |  8 
 hw/arm/xlnx-zcu102.c|  8 
 hw/block/fdc.c  |  4 ++--
 hw/block/vhost-user-blk.c   |  2 +-
 hw/block/virtio-blk.c   |  2 +-
 hw/core/machine.c   |  6 +++---
 hw/cpu/core.c   |  4 ++--
 hw/display/vga-pci.c|  7 +--
 hw/display/xlnx_dp.c|  4 ++--
 hw/dma/sparc32_dma.c|  2 +-
 hw/gpio/aspeed_gpio.c   |  2 +-
 hw/ide/macio.c  |  4 +++-
 hw/ide/qdev.c   |  4 ++--
 hw/intc/apic_common.c   |  2 +-
 hw/mem/nvdimm.c |  4 ++--
 hw/misc/aspeed_sdmc.c   |  2 +-
 hw/misc/edu.c   |  3 ++-
 hw/misc/macio/macio.c   |  4 ++--
 hw/misc/macio/pmu.c |  3 ++-
 hw/misc/pca9552.c   |  2 +-
 hw/misc/tmp105.c|  2 +-
 hw/misc/tmp421.c|  8 
 hw/net/e1000.c  |  3 ++-
 hw/net/lance.c  |  3 ++-
 hw/net/lasi_i82596.c|  3 ++-
 hw/net/ne2000-isa.c |  4 ++--
 hw/net/spapr_llan.c |  3 ++-
 hw/net/virtio-net.c |  2 +-
 hw/pci-host/grackle.c   |  2 +-
 hw/pci-host/i440fx.c|  8 
 hw/pci-host/prep.c  |  2 +-
 hw/pci-host/q35.c   | 23 ++-
 hw/pci-host/sabre.c |  3 ++-
 hw/pci-host/uninorth.c  |  9 +
 hw/pcmcia/pxa2xx.c  |  3 ++-
 hw/ppc/spapr_drc.c  |  6 +++---
 hw/ppc/spapr_rng.c  |  2 +-
 hw/riscv/sifive_u.c |  4 ++--
 hw/s390x/event-facility.c   |  6 +++---
 hw/s390x/s390-ccw.c |  2 +-
 hw/s390x/s390-skeys.c   |  4 ++--
 hw/s390x/s390-stattrib.c|  4 ++--
 hw/s390x/sclp.c |  2 +-
 hw/scsi/scsi-bus.c  |  2 +-
 hw/ssi/xilinx_spips.c   |  2 +-
 hw/usb/bus.c|  4 ++--
 hw/usb/dev-network.c|  2 +-
 hw/usb/dev-storage.c|  4 ++--
 hw/usb/host-libusb.c|  2 +-
 hw/usb/redirect.c   |  2 +-
 hw/virtio/virtio-balloon.c  |  4 ++--
 net/dump.c  |  4 ++--
 net/filter-buffer.c |  2 +-
 net/filter-mirror.c | 10 +-
 net/filter-rewriter.c   |  3 ++-
 target/arm/cpu64.c  |  4 ++--
 target/i386/cpu.c   | 23 ++-
 target/s390x/cpu.c  |  3 ++-
 tests/check-qom-proplist.c  |  7 ---
 tests/test-qdev-global-props.c  |  5 +++--
 65 files changed, 157 insertions(+), 126 deletions(-)

diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
index 6edada8e9e..2fb28c13ac 100644
--- a/backends/cryptodev-vhost-user.c
+++ b/backends/cryptodev-vhost-user.c
@@ -341,7 +341,7 @@ static void cryptodev_vhost_user_instance_int(Object *obj)
 object_property_add_str(obj, "chardev",
 cryptodev_vhost_user_get_chardev,
 cryptodev_vhost_user_set_chardev,
-NULL);
+_abort);
 }
 
 static void cryptodev_vhost_user_finalize(Object *obj)
diff --git a/backends/rng-egd.c b/backends/rng-egd.c
index e380519408..58fb73f03a 100644
--- a/backends/rng-egd.c
+++ b/backends/rng-egd.c
@@ -139,7 +139,7 @@ static void rng_egd_init(Object *obj)
 {
 object_property_add_str(obj, "chardev",
 rng_egd_get_chardev, rng_egd_set_chardev,
-NULL);
+_abort);
 }
 
 static void rng_egd_finalize(Object *obj)
diff --git a/backends/rng-random.c b/backends/rng-random.c
index a810581393..6429276a95 100644
--- a/backends/rng-random.c
+++ b/backends/rng-random.c
@@ -111,7 +111,7 @@ static void rng_random_init(Object *obj)
 object_property_add_str(obj, "filename",
 rng_random_get_filename,
 rng_random_set_filename,
-NULL);
+_abort);
 
 s->filename = g_strdup("/dev/urandom");
 s->fd = -1;
diff --git a/backends/vhost-user.c b/backends/vhost-user.c
index 2bf3406525..491da81653 100644
--- a/backends/vhost-user.c
+++ b/backends/vhost-user.c
@@ -177,7 +177,8 @@ static char 

Re: [PATCH] .gitignore: include common build sub-directories

2020-04-13 Thread Alex Bennée


Eric Blake  writes:

> On 4/13/20 11:29 AM, Alex Bennée wrote:
>> As out-of-tree builds become more common (or rather building in a
>> subdir) we can add a lot of load to "git ls-files" as it hunts down
>> sub-directories that are irrelevant to the source tree. This is
>> especially annoying if you have a prompt that attempts to summarise
>> the current git status on command completion.
>> Signed-off-by: Alex Bennée 
>> ---
>>   .gitignore | 2 ++
>>   1 file changed, 2 insertions(+)
>> diff --git a/.gitignore b/.gitignore
>> index 0c5af83aa74..7757dc08a08 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -141,6 +141,8 @@ cscope.*
>>   tags
>>   TAGS
>>   docker-src.*
>> +build
>> +builds
>
> Would 'build-*' be worth adding as well?

Sure - I'll add it to v2.

>
> The idea makes sense to me (as I've already done the same in my
> ./git/info/exclude locally),
> Reviewed-by: Eric Blake 


-- 
Alex Bennée



Re: [PATCH-for-5.0? 3/3] hw/openrisc/pic_cpu: Use qdev gpio rather than qemu_allocate_irqs()

2020-04-13 Thread Philippe Mathieu-Daudé
Hi Stafford,

On 4/13/20 1:33 AM, Stafford Horne wrote:
> On Sun, Apr 12, 2020 at 11:29:43PM +0200, Philippe Mathieu-Daudé wrote:
>> Switch to using the qdev gpio API which is preferred over
>> qemu_allocate_irqs(). Doing so we also stop leaking the
>> allocated memory. One step to eventually deprecate and
>> remove qemu_allocate_irqs() one day.
>>
>> Patch created mechanically using spatch with this script
>> inspired from commit d6ef883d9d7:
>>
>>   @@
>>   typedef qemu_irq;
>>   identifier irqs, handler;
>>   expression opaque, count, i;
>>   @@
>>   -   qemu_irq *irqs;
>>   ...
>>   -   irqs = qemu_allocate_irqs(handler, opaque, count);
>>   +   qdev_init_gpio_in(DEVICE(opaque), handler, count);
>>   <+...
>>   -   irqs[i]
>>   +   qdev_get_gpio_in(DEVICE(opaque), i)
>>   ...+>
>>   ?-  g_free(irqs);
>>
>> Inspired-by: Peter Maydell 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/openrisc/pic_cpu.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/openrisc/pic_cpu.c b/hw/openrisc/pic_cpu.c
>> index 36f9350830..4b0c92f842 100644
>> --- a/hw/openrisc/pic_cpu.c
>> +++ b/hw/openrisc/pic_cpu.c
>> @@ -52,10 +52,9 @@ static void openrisc_pic_cpu_handler(void *opaque, int 
>> irq, int level)
>>  void cpu_openrisc_pic_init(OpenRISCCPU *cpu)
>>  {
>>  int i;
>> -qemu_irq *qi;
>> -qi = qemu_allocate_irqs(openrisc_pic_cpu_handler, cpu, NR_IRQS);
>> +qdev_init_gpio_in(DEVICE(cpu), openrisc_pic_cpu_handler, NR_IRQS);
>>  
>>  for (i = 0; i < NR_IRQS; i++) {
>> -cpu->env.irq[i] = qi[i];
>> +cpu->env.irq[i] = qdev_get_gpio_in(DEVICE(cpu), i);
>>  }
>>  }
> 
> This looks fine to me.
> 
> Why do you have the '5.0?' in the subject?

Simply because similar commit d6ef883d9d7 was merged in 5.0-rc1 (and it
fixes a bug reported by Coverity, I'm not sure why Coverity didn't
reported this too).

> 
> -Stafford
> 



Re: [PATCH-for-5.1 1/3] hw/ide/ahci: Use qdev gpio rather than qemu_allocate_irqs()

2020-04-13 Thread Philippe Mathieu-Daudé
[sending again as my previous mail was rejected, sorry if you get this
twice]

On 4/12/20 11:29 PM, Philippe Mathieu-Daudé wrote:
> Switch to using the qdev gpio API which is preferred over
> qemu_allocate_irqs(). One step to eventually deprecate and
> remove qemu_allocate_irqs() one day.
> 
> Patch created mechanically using spatch with this script
> inspired from commit d6ef883d9d7:
> 
>   @@
>   typedef qemu_irq;
>   identifier irqs, handler;
>   expression opaque, count, i;
>   @@
>   -   qemu_irq *irqs;
>   ...
>   -   irqs = qemu_allocate_irqs(handler, opaque, count);
>   +   qdev_init_gpio_in(DEVICE(opaque), handler, count);
>   <+...
>   -   irqs[i]
>   +   qdev_get_gpio_in(DEVICE(opaque), i)
>   ...+>
>   ?-  g_free(irqs);
> 
> Inspired-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/ide/ahci.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 13d91e109a..ef0a0a22ee 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1534,19 +1534,18 @@ void ahci_init(AHCIState *s, DeviceState *qdev)
>  
>  void ahci_realize(AHCIState *s, DeviceState *qdev, AddressSpace *as, int 
> ports)
>  {
> -qemu_irq *irqs;
>  int i;
>  
>  s->as = as;
>  s->ports = ports;
>  s->dev = g_new0(AHCIDevice, ports);
>  ahci_reg_init(s);
> -irqs = qemu_allocate_irqs(ahci_irq_set, s, s->ports);
> +qdev_init_gpio_in(DEVICE(s), ahci_irq_set, s->ports);

This is wrong as AHCIState is not a QOM DEVICE... see commit bb639f829f1:

---
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index c055d6ba6b..c9b3805415 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -287,6 +287,8 @@ struct AHCIDevice {
 };

 typedef struct AHCIState {
+DeviceState *container;
+
 AHCIDevice *dev;
 AHCIControlRegs control_regs;
 MemoryRegion mem;
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 02d85fa0e9..d83efa47a4 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -121,9 +121,9 @@ static uint32_t  ahci_port_read(AHCIState *s, int
port, int offset)

 static void ahci_irq_raise(AHCIState *s, AHCIDevice *dev)
 {
-AHCIPCIState *d = container_of(s, AHCIPCIState, ahci);
-PCIDevice *pci_dev =
-(PCIDevice *)object_dynamic_cast(OBJECT(d), TYPE_PCI_DEVICE);
+DeviceState *dev_state = s->container;
+PCIDevice *pci_dev = (PCIDevice *)
object_dynamic_cast(OBJECT(dev_state),
+
TYPE_PCI_DEVICE);

 DPRINTF(0, "raise irq\n");

@@ -136,9 +136,9 @@ static void ahci_irq_raise(AHCIState *s, AHCIDevice
*dev)

 static void ahci_irq_lower(AHCIState *s, AHCIDevice *dev)
 {
-AHCIPCIState *d = container_of(s, AHCIPCIState, ahci);
-PCIDevice *pci_dev =
-(PCIDevice *)object_dynamic_cast(OBJECT(d), TYPE_PCI_DEVICE);
+DeviceState *dev_state = s->container;
+PCIDevice *pci_dev = (PCIDevice *)
object_dynamic_cast(OBJECT(dev_state),
+
TYPE_PCI_DEVICE);

 DPRINTF(0, "lower irq\n");

@@ -1436,6 +1436,7 @@ void ahci_init(AHCIState *s, DeviceState *qdev,
AddressSpace *as, int ports)
 s->as = as;
 s->ports = ports;
 s->dev = g_new0(AHCIDevice, ports);
+s->container = qdev;
 ahci_reg_init(s);
 /* XXX BAR size should be 1k, but that breaks, so bump it to 4k for
now */
 memory_region_init_io(>mem, OBJECT(qdev), _mem_ops, s,
---

Using s/DEVICE(s)/qdev/ works although.

>  for (i = 0; i < s->ports; i++) {
>  AHCIDevice *ad = >dev[i];
>  
>  ide_bus_new(>port, sizeof(ad->port), qdev, i, 1);
> -ide_init2(>port, irqs[i]);
> +ide_init2(>port, qdev_get_gpio_in(DEVICE(s), i));
>  
>  ad->hba = s;
>  ad->port_no = i;
> @@ -1554,7 +1553,6 @@ void ahci_realize(AHCIState *s, DeviceState *qdev, 
> AddressSpace *as, int ports)
>  ad->port.dma->ops = _dma_ops;
>  ide_register_restart_cb(>port);
>  }
> -g_free(irqs);
>  }
>  
>  void ahci_uninit(AHCIState *s)
> 



Re: [PATCH 0/7] hw/sparc/leon3: Few fixes and disable HelenOS test

2020-04-13 Thread Philippe Mathieu-Daudé
[Cc'ing Peter]

On 4/13/20 12:12 PM, KONRAD Frederic wrote:
> Le 4/11/20 à 7:30 PM, Philippe Mathieu-Daudé a écrit :
>> On 3/31/20 12:50 PM, Philippe Mathieu-Daudé wrote:
>>> Philippe Mathieu-Daudé (7):
>>>    hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to AHB PnP
>>>  registers
>>>    hw/misc/grlib_ahb_apb_pnp: Fix AHB PnP 8-bit accesses
>>
>> Ping ^^^ for 5.0?
> 
> Hi Philippe,
> 
> You already have my rb tag for those one, and IMHO they should be good
> candidate
> for 5.0 (if it's not too late).

Yes, thanks for the reviews. I see Mark Cave-Ayland merged this file
first, but you are listed as maintainer :) I was hoping you could send a
pull request.

$ scripts/get_maintainer.pl -f hw/misc/grlib_ahb_apb_pnp.c
Fabien Chouteau  (maintainer:Leon3)
KONRAD Frederic  (maintainer:Leon3)
qemu-devel@nongnu.org (open list:All patches CC here)

This is a bug but not 'security critical', so it might wait 5.1 and go
via qemu-trivial tree.

Regards,

Phil.

> 
> Cheers,
> Fred
> 
>>
>>>    hw/misc/grlib_ahb_apb_pnp: Add trace events on read accesses
>>>    hw/timer/grlib_gptimer: Display frequency in decimal
>>>    target/sparc/int32_helper: Remove DEBUG_PCALL definition
>>>    target/sparc/int32_helper: Extract and use excp_name_str()
>>>
>>>   hw/misc/grlib_ahb_apb_pnp.c | 24 ++--
>>>   target/sparc/int32_helper.c | 23 ---
>>>   hw/misc/trace-events    |  4 
>>>   hw/timer/trace-events   |  2 +-
>>>   tests/acceptance/machine_sparc_leon3.py |  4 
>>>   5 files changed, 43 insertions(+), 14 deletions(-)
>>>
> 



Re: [PATCH-for-5.1 v3 03/24] hw/arm/allwinner-a10: Move some code from realize() to init()

2020-04-13 Thread Philippe Mathieu-Daudé
On 4/13/20 12:35 AM, Philippe Mathieu-Daudé wrote:
> Coccinelle reported:
> 
>   $ spatch ... --timeout 60 --sp-file \
> scripts/coccinelle/simplify-init-realize-error_propagate.cocci
>   HANDLING: ./hw/arm/allwinner-a10.c
>   >>> possible moves from aw_a10_init() to aw_a10_realize() in 
> ./hw/arm/allwinner-a10.c:77
> 
> Move the calls using _fatal which don't depend on input
> updated before realize() to init().
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v3: Typo 'depend of' -> 'depend on' (eblake)
> ---
>  hw/arm/allwinner-a10.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
> index 62a67a3e1a..f41395734a 100644
> --- a/hw/arm/allwinner-a10.c
> +++ b/hw/arm/allwinner-a10.c
> @@ -60,10 +60,18 @@ static void aw_a10_init(Object *obj)
>  int i;
>  
>  for (i = 0; i < AW_A10_NUM_USB; i++) {
> +char bus[16];
> +
>  sysbus_init_child_obj(obj, "ehci[*]", OBJECT(>ehci[i]),
>sizeof(s->ehci[i]), TYPE_PLATFORM_EHCI);
>  sysbus_init_child_obj(obj, "ohci[*]", OBJECT(>ohci[i]),
>sizeof(s->ohci[i]), TYPE_SYSBUS_OHCI);
> +object_property_set_bool(OBJECT(>ehci[i]), true,
> + "companion-enable", _fatal);
> +
> +sprintf(bus, "usb-bus.%d", i);
> +object_property_set_str(OBJECT(>ohci[i]), bus, "masterbus",
> +_fatal);
>  }
>  }
>  
> @@ -72,6 +80,11 @@ static void aw_a10_init(Object *obj)
>  
>  sysbus_init_child_obj(obj, "rtc", >rtc, sizeof(s->rtc),
>TYPE_AW_RTC_SUN4I);
> +
> +memory_region_init_ram(>sram_a, obj, "sram A", 48 * KiB,
> +   _fatal);
> +memory_region_add_subregion(get_system_memory(), 0x, >sram_a);

Unfortunately this makes qtest/device-introspect-test fail:

(qemu) device_add allwinner-a10,help
(qemu) device_add allwinner-a10,help
RAMBlock "sram A" already registered, abort!
Aborted (core dumped)

(gdb) bt
#1  0x75089895 in abort () at /lib64/libc.so.6
#2  0x57324445 in qemu_ram_set_idstr (new_block=0x61426a40,
name=0x602000231a50 "sram A", dev=0x63338800) at exec.c:2023
#3  0x595ed050 in vmstate_register_ram (mr=0x63349610,
dev=0x63338800) at migration/savevm.c:2921
#4  0x57569a85 in memory_region_init_ram (mr=0x63349610,
owner=0x63338800, name=0x5a4da6a0  "sram A", size=49152,
errp=0x5c908d00 )
at memory.c:3170
#5  0x57b7cadf in aw_a10_init (obj=0x63338800) at
hw/arm/allwinner-a10.c:84
#6  0x599b0c09 in object_init_with_type (obj=0x63338800,
ti=0x6131da80) at qom/object.c:376
#7  0x59994350 in object_initialize_with_type
(data=0x63338800, size=97024, type=0x6131da80) at qom/object.c:516
#8  0x59996756 in object_new_with_type (type=0x6131da80) at
qom/object.c:684
#9  0x59996832 in object_new (typename=0x60200022e8b0
"allwinner-a10") at qom/object.c:699
#10 0x5979e809 in qmp_device_list_properties
(typename=0x60200022e8b0 "allwinner-a10", errp=0x7fffafc0) at
qom/qom-qmp-cmds.c:153
#11 0x582b68cd in qdev_device_help (opts=0x607000120130) at
qdev-monitor.c:282


> +create_unimplemented_device("a10-sram-ctrl", 0x01c0, 4 * KiB);
>  }
>  
>  static void aw_a10_realize(DeviceState *dev, Error **errp)
> @@ -113,11 +126,6 @@ static void aw_a10_realize(DeviceState *dev, Error 
> **errp)
>  sysbus_connect_irq(sysbusdev, 4, qdev_get_gpio_in(dev, 67));
>  sysbus_connect_irq(sysbusdev, 5, qdev_get_gpio_in(dev, 68));
>  
> -memory_region_init_ram(>sram_a, OBJECT(dev), "sram A", 48 * KiB,
> -   _fatal);
> -memory_region_add_subregion(get_system_memory(), 0x, >sram_a);
> -create_unimplemented_device("a10-sram-ctrl", 0x01c0, 4 * KiB);
> -
>  /* FIXME use qdev NIC properties instead of nd_table[] */
>  if (nd_table[0].used) {
>  qemu_check_nic_model(_table[0], TYPE_AW_EMAC);
> @@ -149,12 +157,6 @@ static void aw_a10_realize(DeviceState *dev, Error 
> **errp)
>  int i;
>  
>  for (i = 0; i < AW_A10_NUM_USB; i++) {
> -char bus[16];
> -
> -sprintf(bus, "usb-bus.%d", i);
> -
> -object_property_set_bool(OBJECT(>ehci[i]), true,
> - "companion-enable", _fatal);
>  object_property_set_bool(OBJECT(>ehci[i]), true, "realized",
>   _fatal);
>  sysbus_mmio_map(SYS_BUS_DEVICE(>ehci[i]), 0,
> @@ -162,8 +164,6 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
>  sysbus_connect_irq(SYS_BUS_DEVICE(>ehci[i]), 0,
> qdev_get_gpio_in(dev, 39 + i));
>  
> -

[PATCH-for-5.1 v3 4/7] migration/colo: Add missing error-propagation code

2020-04-13 Thread Philippe Mathieu-Daudé
Running the coccinelle script produced:

  $ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/find-missing-error_propagate.cocci \
--keep-comments --smpl-spacing --dir .
  HANDLING: ./migration/colo.c
  [[manual check required: error_propagate() might be missing in 
migrate_set_block_enabled() ./migration/colo.c:439:4]]

Add the missing error_propagate() after review.

Reviewed-by: Juan Quintela 
Signed-off-by: Philippe Mathieu-Daudé 
---
 migration/colo.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/migration/colo.c b/migration/colo.c
index a54ac84f41..57b2adb0cc 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -437,6 +437,9 @@ static int colo_do_checkpoint_transaction(MigrationState *s,
 
 /* Disable block migration */
 migrate_set_block_enabled(false, _err);
+if (local_err) {
+goto out;
+}
 qemu_mutex_lock_iothread();
 
 #ifdef CONFIG_REPLICATION
-- 
2.21.1




[PATCH-for-5.1 v3 5/7] hw/mips/boston: Add missing error-propagation code

2020-04-13 Thread Philippe Mathieu-Daudé
Running the coccinelle script produced:

  $ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/find-missing-error_propagate.cocci \
--keep-comments --smpl-spacing --dir .
  HANDLING: ./hw/mips/boston.c
  [[manual check required: error_propagate() might be missing in 
object_property_set_int() ./hw/mips/boston.c:462:4]]
  [[manual check required: error_propagate() might be missing in 
object_property_set_str() ./hw/mips/boston.c:460:4]]

Since the uses are inside a MachineClass::init() function,
directly use _fatal instead of error_propagate().

Reviewed-by: Peter Maydell 
Reviewed-by: Aleksandar Markovic 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/mips/boston.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/hw/mips/boston.c b/hw/mips/boston.c
index 98ecd25e8e..2e821ca7d6 100644
--- a/hw/mips/boston.c
+++ b/hw/mips/boston.c
@@ -426,7 +426,6 @@ static void boston_mach_init(MachineState *machine)
 {
 DeviceState *dev;
 BostonState *s;
-Error *err = NULL;
 MemoryRegion *flash, *ddr_low_alias, *lcd, *platreg;
 MemoryRegion *sys_mem = get_system_memory();
 XilinxPCIEHost *pcie2;
@@ -458,19 +457,15 @@ static void boston_mach_init(MachineState *machine)
 sysbus_init_child_obj(OBJECT(machine), "cps", OBJECT(>cps),
   sizeof(s->cps), TYPE_MIPS_CPS);
 object_property_set_str(OBJECT(>cps), machine->cpu_type, "cpu-type",
-);
-object_property_set_int(OBJECT(>cps), machine->smp.cpus, "num-vp", 
);
-object_property_set_bool(OBJECT(>cps), true, "realized", );
-
-if (err != NULL) {
-error_report("%s", error_get_pretty(err));
-exit(1);
-}
-
+_fatal);
+object_property_set_int(OBJECT(>cps), machine->smp.cpus, "num-vp",
+_fatal);
+object_property_set_bool(OBJECT(>cps), true, "realized", _fatal);
 sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>cps), 0, 0, 1);
 
 flash =  g_new(MemoryRegion, 1);
-memory_region_init_rom(flash, NULL, "boston.flash", 128 * MiB, );
+memory_region_init_rom(flash, NULL, "boston.flash", 128 * MiB,
+   _fatal);
 memory_region_add_subregion_overlap(sys_mem, 0x1800, flash, 0);
 
 memory_region_add_subregion_overlap(sys_mem, 0x8000, machine->ram, 0);
-- 
2.21.1




[PATCH-for-5.1 v3 3/7] scripts/coccinelle: Find eventually missing error_propagate() calls

2020-04-13 Thread Philippe Mathieu-Daudé
In some places in we put an error into a local Error*, but
forget to use it. Add a Coccinelle patch to find such cases
and report them.

Inspired-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 .../find-missing-error_propagate.cocci| 53 +++
 MAINTAINERS   |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 scripts/coccinelle/find-missing-error_propagate.cocci

diff --git a/scripts/coccinelle/find-missing-error_propagate.cocci 
b/scripts/coccinelle/find-missing-error_propagate.cocci
new file mode 100644
index 00..8b75b37b64
--- /dev/null
+++ b/scripts/coccinelle/find-missing-error_propagate.cocci
@@ -0,0 +1,53 @@
+// Find places likely missing error-propagation code, but code is too
+// complex for automatic transformation, so manual analysis is required.
+//
+// Copyright: (C) 2020 Philippe Mathieu-Daudé
+// This work is licensed under the terms of the GNU GPLv2 or later.
+//
+// spatch \
+//  --macro-file scripts/cocci-macro-file.h --include-headers \
+//  --sp-file scripts/coccinelle/find-missing-error_propagate.cocci
+//
+// Inspired by 
https://www.mail-archive.com/qemu-devel@nongnu.org/msg691638.html
+
+
+// First match two subsequent calls using local Error*
+// in function provided a Error** argument
+//
+@discard_func_with_errp_argument@
+typedef Error;
+Error *local_err;
+identifier func, errp, errfunc1, errfunc2;
+@@
+void func(..., Error **errp)
+{
+ <+...
+ errfunc1(..., _err);
+ ... when != local_err  // local_err is not used between the calls
+ errfunc2(..., _err);
+ ...+>
+}
+
+
+// Again, match two subsequent calls using local Error*
+// but ignoring within functions provided a Error** argument
+//
+@manual depends on never discard_func_with_errp_argument@
+Error *local_err;
+identifier errfunc1, errfunc2;
+position p;
+@@
+ errfunc1@p(..., _err);
+ ... when != local_err
+ errfunc2(..., _err);
+
+
+// As it is likely too complex to transform, report the hit
+//
+@script:python@
+f << manual.errfunc1;
+p << manual.p;
+@@
+print("[[manual check required: "
+  "error_propagate() might be missing in {}() {}:{}:{}]]".format(
+f, p[0].file, p[0].line, p[0].column))
diff --git a/MAINTAINERS b/MAINTAINERS
index 77b93612bc..1150ec95a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2058,6 +2058,7 @@ F: scripts/coccinelle/add-missing-error_propagate.cocci
 F: scripts/coccinelle/err-bad-newline.cocci
 F: scripts/coccinelle/error-use-after-free.cocci
 F: scripts/coccinelle/error_propagate_null.cocci
+F: scripts/coccinelle/find-missing-error_propagate.cocci
 F: scripts/coccinelle/remove_local_err.cocci
 F: scripts/coccinelle/simplify-init-realize-error_propagate.cocci
 F: scripts/coccinelle/use-error_abort-in-instance_init.cocci
-- 
2.21.1




[PATCH-for-5.1 v3 1/7] scripts/coccinelle: Use _abort in TypeInfo::instance_init()

2020-04-13 Thread Philippe Mathieu-Daudé
The instance_init() calls are not suppose to fail. Add a
Coccinelle script to use _abort instead of ignoring
errors by using a NULL Error*.

Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Improved script (Vladimir Sementsov-Ogievskiy suggestions)

 .../use-error_abort-in-instance_init.cocci| 45 +++
 MAINTAINERS   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 scripts/coccinelle/use-error_abort-in-instance_init.cocci

diff --git a/scripts/coccinelle/use-error_abort-in-instance_init.cocci 
b/scripts/coccinelle/use-error_abort-in-instance_init.cocci
new file mode 100644
index 00..706c60163c
--- /dev/null
+++ b/scripts/coccinelle/use-error_abort-in-instance_init.cocci
@@ -0,0 +1,45 @@
+// Use _abort in TypeInfo::instance_init()
+//
+// Copyright: (C) 2020 Philippe Mathieu-Daudé
+// This work is licensed under the terms of the GNU GPLv2 or later.
+//
+// spatch \
+//  --macro-file scripts/cocci-macro-file.h --include-headers \
+//  --sp-file scripts/coccinelle/use-error_abort-in-instance_init.cocci \
+//  --keep-comments --in-place
+//
+// Inspired by 
https://www.mail-archive.com/qemu-devel@nongnu.org/msg692500.html
+// and https://www.mail-archive.com/qemu-devel@nongnu.org/msg693637.html
+
+
+@ has_qapi_error @
+@@
+#include "qapi/error.h"
+
+
+@ match_instance_init @
+TypeInfo info;
+identifier instance_initfn;
+@@
+info.instance_init = instance_initfn;
+
+
+@ use_error_abort_in_instance_init @
+identifier match_instance_init.instance_initfn;
+identifier func_with_error != {qbus_create_inplace, object_initialize_child};
+position pos;
+@@
+void instance_initfn(...)
+{
+   <+...
+   func_with_error@pos(...,
+-   NULL);
++   _abort);
+   ...+>
+}
+
+
+@ depends on use_error_abort_in_instance_init && !has_qapi_error @
+@@
+#include ...
++   #include "qapi/error.h"
diff --git a/MAINTAINERS b/MAINTAINERS
index f996e72780..77b93612bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2060,6 +2060,7 @@ F: scripts/coccinelle/error-use-after-free.cocci
 F: scripts/coccinelle/error_propagate_null.cocci
 F: scripts/coccinelle/remove_local_err.cocci
 F: scripts/coccinelle/simplify-init-realize-error_propagate.cocci
+F: scripts/coccinelle/use-error_abort-in-instance_init.cocci
 F: scripts/coccinelle/use-error_fatal.cocci
 F: scripts/coccinelle/use-error_propagate-in-realize.cocci
 
-- 
2.21.1




[PATCH-for-5.1 v3 7/7] qga/commands-win32: Add missing error-propagation code

2020-04-13 Thread Philippe Mathieu-Daudé
Running the coccinelle script produced:

  $ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/find-missing-error_propagate.cocci \
--keep-comments --smpl-spacing --dir .
  HANDLING: ./qga/commands-win32.c
  [[manual check required: error_propagate() might be missing in 
acquire_privilege() ./qga/commands-win32.c:1344:4]]
  [[manual check required: error_propagate() might be missing in 
acquire_privilege() ./qga/commands-win32.c:1360:4]]
  [[manual check required: error_propagate() might be missing in 
check_suspend_mode() ./qga/commands-win32.c:1343:4]]
  [[manual check required: error_propagate() might be missing in 
check_suspend_mode() ./qga/commands-win32.c:1359:4]]

Add the missing error_propagate() after review.

Signed-off-by: Philippe Mathieu-Daudé 
---
 .../use-error_abort-in-instance_init.cocci| 17 
 qga/commands-win32.c  | 26 +--
 2 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/scripts/coccinelle/use-error_abort-in-instance_init.cocci 
b/scripts/coccinelle/use-error_abort-in-instance_init.cocci
index 8302d74a0c..706c60163c 100644
--- a/scripts/coccinelle/use-error_abort-in-instance_init.cocci
+++ b/scripts/coccinelle/use-error_abort-in-instance_init.cocci
@@ -24,29 +24,22 @@ identifier instance_initfn;
 info.instance_init = instance_initfn;
 
 
-@ use_error_abort @
+@ use_error_abort_in_instance_init @
 identifier match_instance_init.instance_initfn;
-identifier func_with_error;
-expression parentobj, propname, childobj, size, type, errp;
+identifier func_with_error != {qbus_create_inplace, object_initialize_child};
 position pos;
 @@
 void instance_initfn(...)
 {
<+...
-(
-   object_initialize_child(parentobj, propname,
-   childobj, size, type,
-   errp, NULL);
-|
func_with_error@pos(...,
 -   NULL);
 +   _abort);
-)
...+>
 }
 
 
-@script:python depends on use_error_abort && !has_qapi_error@
-p << use_error_abort.pos;
+@ depends on use_error_abort_in_instance_init && !has_qapi_error @
 @@
-print('[[manual edit required, %s misses #include "qapi/error.h"]]' % 
p[0].file)
+#include ...
++   #include "qapi/error.h"
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index b49920e201..8b66098056 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -1341,13 +1341,18 @@ void qmp_guest_suspend_disk(Error **errp)
 
 *mode = GUEST_SUSPEND_MODE_DISK;
 check_suspend_mode(*mode, _err);
+if (local_err) {
+goto out;
+}
 acquire_privilege(SE_SHUTDOWN_NAME, _err);
+if (local_err) {
+goto out;
+}
 execute_async(do_suspend, mode, _err);
 
-if (local_err) {
-error_propagate(errp, local_err);
-g_free(mode);
-}
+out:
+error_propagate(errp, local_err);
+g_free(mode);
 }
 
 void qmp_guest_suspend_ram(Error **errp)
@@ -1357,13 +1362,18 @@ void qmp_guest_suspend_ram(Error **errp)
 
 *mode = GUEST_SUSPEND_MODE_RAM;
 check_suspend_mode(*mode, _err);
+if (local_err) {
+goto out;
+}
 acquire_privilege(SE_SHUTDOWN_NAME, _err);
+if (local_err) {
+goto out;
+}
 execute_async(do_suspend, mode, _err);
 
-if (local_err) {
-error_propagate(errp, local_err);
-g_free(mode);
-}
+out:
+error_propagate(errp, local_err);
+g_free(mode);
 }
 
 void qmp_guest_suspend_hybrid(Error **errp)
-- 
2.21.1




[PATCH] spapr_nvdimm.c: make 'label-size' mandatory

2020-04-13 Thread Daniel Henrique Barboza
The pseries machine does not support NVDIMM modules without label.
Attempting to do so, even if the overall block size is aligned with
256MB, will seg fault the guest kernel during NVDIMM probe. This
can be avoided by forcing 'label-size' to always be present for
sPAPR NVDIMMs.

The verification was put before the alignment check because the
presence of label-size affects the alignment calculation, so
it's not optimal to warn the user about an alignment error,
then about the lack of label-size, then about a new alignment
error when the user sets a label-size.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr_nvdimm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index 25be8082d7..9abcdcc26b 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -37,6 +37,12 @@ void spapr_nvdimm_validate_opts(NVDIMMDevice *nvdimm, 
uint64_t size,
 QemuUUID uuid;
 int ret;
 
+if (object_property_get_int(OBJECT(nvdimm), NVDIMM_LABEL_SIZE_PROP,
+_abort) == 0) {
+error_setg(errp, "NVDIMM device requires label-size to be set");
+return;
+}
+
 if (size % SPAPR_MINIMUM_SCM_BLOCK_SIZE) {
 error_setg(errp, "NVDIMM memory size excluding the label area"
" must be a multiple of %" PRIu64 "MB",
-- 
2.25.2




[PATCH-for-5.1 v3 6/7] hw/mips/mips_malta: Use _abort in MachineClass::init -> create_cps

2020-04-13 Thread Philippe Mathieu-Daudé
Running the coccinelle script produced:

  $ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/find-missing-error_propagate.cocci \
--keep-comments --smpl-spacing --dir .
  HANDLING: ./hw/mips/mips_malta.c
  [[manual check required: error_propagate() might be missing in 
object_property_set_int() ./hw/mips/mips_malta.c:1193:4]]
  [[manual check required: error_propagate() might be missing in 
object_property_set_str() ./hw/mips/mips_malta.c:1192:4]]

Since create_cps() is called from a MachineClass::init(),
replace local Error* by _abort.

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Use _fatal (rth)
---
 hw/mips/mips_malta.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index e4c4de1b4e..477ee6cc5b 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -51,7 +51,6 @@
 #include "sysemu/reset.h"
 #include "sysemu/runstate.h"
 #include "qapi/error.h"
-#include "qemu/error-report.h"
 #include "hw/empty_slot.h"
 #include "sysemu/kvm.h"
 #include "hw/semihosting/semihost.h"
@@ -1185,17 +1184,13 @@ static void create_cpu_without_cps(MachineState *ms,
 static void create_cps(MachineState *ms, MaltaState *s,
qemu_irq *cbus_irq, qemu_irq *i8259_irq)
 {
-Error *err = NULL;
-
 sysbus_init_child_obj(OBJECT(s), "cps", OBJECT(>cps), sizeof(s->cps),
   TYPE_MIPS_CPS);
-object_property_set_str(OBJECT(>cps), ms->cpu_type, "cpu-type", );
-object_property_set_int(OBJECT(>cps), ms->smp.cpus, "num-vp", );
-object_property_set_bool(OBJECT(>cps), true, "realized", );
-if (err != NULL) {
-error_report("%s", error_get_pretty(err));
-exit(1);
-}
+object_property_set_str(OBJECT(>cps), ms->cpu_type, "cpu-type",
+_fatal);
+object_property_set_int(OBJECT(>cps), ms->smp.cpus, "num-vp",
+_fatal);
+object_property_set_bool(OBJECT(>cps), true, "realized", _fatal);
 
 sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>cps), 0, 0, 1);
 
-- 
2.21.1




Re: [PULL 0/4] pc: bugfixes, maintainers

2020-04-13 Thread Peter Maydell
On Mon, 13 Apr 2020 at 12:09, Michael S. Tsirkin  wrote:
>
> The following changes since commit f3bac27cc1e303e1860cc55b9b6889ba39dee587:
>
>   Update version for v5.0.0-rc2 release (2020-04-07 23:13:37 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to ce4adc0b6e6167091373389ef8befd379c61fddb:
>
>   exec: Fix for qemu_ram_resize() callback (2020-04-13 06:55:54 -0400)
>
> 
> pc: bugfixes, maintainers
>
> A couple of bugfixes.
> Add a new vhost-user-blk maintainer.
>
> Signed-off-by: Michael S. Tsirkin 


Applied, thanks.

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

-- PMM



Re: Supported Sphinx Versions (was: Re: [PATCH for-5.0? 0/3] Make docs build work with Sphinx 3)

2020-04-13 Thread John Snow



On 4/13/20 2:22 PM, Peter Maydell wrote:
> On Mon, 13 Apr 2020 at 19:08, John Snow  wrote:
>> I was curious about our actual version compatibility, so I did some testing.
> 
> Thanks for doing the testing.
> 
>> 1.6.1 through 2.2.2 all appear to work just fine, but produce a lot of
>> warnings about a coming incompatibility with Docutils > 0.16.
> 
> FWIW, I don't get this warning with the stock Ubuntu
> 1.6.7. The only time I did see it was when I'd managed
> to accidentally install half of Sphinx 3 to my ~/.local
> directory and I think it was the system Sphinx and an
> upgraded docutils or some other weird combo.
> 

Yeah, it depends on what versions you pull in. I am using `pip` to
install sphinx straight from PyPI, and the version dependency resolution
opts for "the latest that isn't prohibited by the repository", which
means that I am using (very likely) some cutting edge dependencies for
an older version of sphinx.

That's OK, it works just fine -- just a note, is all. It likely works
completely quietly if you scoot back down to Docutils 0.15.

(The requirements specify only Docutils >= 0.12. Eventually, older
sphinx installations may break when Docutils 0.17 comes out unless you
start pinning versions manually.)

>> Conclusion:
>>
>> Required: >= 1.6.1
>> Recommended: >= 2.3.0
> 
> I think that what we actually care about is the usual thing:
> do we build OK with the version of sphinx-build shipped by
> every distro on our support list?

Sure; if any distro ships a version that's outside of what I laid out
above it would be good to fix and check.

We can also tighten and document the versions so if we do fall outside
of that by accident, we'll catch it during RC testing phase.

I'm using this to make a quick assessment:
https://repology.org/project/python:sphinx/versions

Fedora:
30: 1.8.4
31: 2.1.2

OpenSUSE:
15.1: 1.7.6

Ubuntu:
19.10: 1.8.5
20.04/LTS: 1.8.5

Debian:
8/Jessie: We don't support this anymore AFAIUI.
9/Stretch: 1.4.8 -- Broken at present!
10/Buster: 1.8.3

Ubuntu LTS:
16.04: Dropped
18.04: 1.6.7
20.04: 1.8.5

RHEL:
EPEL7: 1.2.3 -- way, way too old!
RHEL8: 1.7.6 [via CentOS8]



We *might* need to do some surgery to support Stretch, and EPEL7 fell
off the wagon entirely if repology is to believe -- it doesn't support
our stated minimum of simply having the "Alabaster" theme, which comes
in 1.3.

For RHEL7 we *could* start using a virtual environment, which would help
alleviate the wide version spread.

...are we opposed to this kind of thing? Has there been a discussion before?

Targeting the native repo versions is nice (and we should continue to
make a best effort there), but we *could* start offering a virtual
python environment for the builds that grabs very precise versions.

--js




Re: [PATCH] .gitignore: include common build sub-directories

2020-04-13 Thread Eric Blake

On 4/13/20 11:29 AM, Alex Bennée wrote:

As out-of-tree builds become more common (or rather building in a
subdir) we can add a lot of load to "git ls-files" as it hunts down
sub-directories that are irrelevant to the source tree. This is
especially annoying if you have a prompt that attempts to summarise
the current git status on command completion.

Signed-off-by: Alex Bennée 
---
  .gitignore | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 0c5af83aa74..7757dc08a08 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,6 +141,8 @@ cscope.*
  tags
  TAGS
  docker-src.*
+build
+builds


Would 'build-*' be worth adding as well?

The idea makes sense to me (as I've already done the same in my 
./git/info/exclude locally),

Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: Supported Sphinx Versions (was: Re: [PATCH for-5.0? 0/3] Make docs build work with Sphinx 3)

2020-04-13 Thread Peter Maydell
On Mon, 13 Apr 2020 at 19:08, John Snow  wrote:
> I was curious about our actual version compatibility, so I did some testing.

Thanks for doing the testing.

> 1.6.1 through 2.2.2 all appear to work just fine, but produce a lot of
> warnings about a coming incompatibility with Docutils > 0.16.

FWIW, I don't get this warning with the stock Ubuntu
1.6.7. The only time I did see it was when I'd managed
to accidentally install half of Sphinx 3 to my ~/.local
directory and I think it was the system Sphinx and an
upgraded docutils or some other weird combo.

> Conclusion:
>
> Required: >= 1.6.1
> Recommended: >= 2.3.0

I think that what we actually care about is the usual thing:
do we build OK with the version of sphinx-build shipped by
every distro on our support list?

thanks
-- PMM



[Bug 1872237] Re: SysTick reload behavior emulated incorrectly

2020-04-13 Thread Peter Maydell
Other than the systick issue, I think the core M-profile emulation
should be pretty solid (bugs are always possible, of course). We have
support for v6M (cortex-m0), v7M (cortex-m3, m4) and v8M (cortex-m33,
including the security extension) and at least some board models for all
of those. No v8.1M yet (that is next on my todo list). Board and device
support in QEMU is in general more likely to have missing features than
the core cpu emulation, but I can't think of anything specifically
annoyingly missing offhand. Of the upstream board models, the various
MPS2 boards are I think fairly solid, as are the Musca board models. We
also have a Netduino 2 and a Netduino Plus 2 model which I think ought
to be OK. The Stellaris boards (lm3s6965evb and lm3s811evb) are rather
older and I dunno that I'd recommend them unless you have no other
choice.

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

Title:
  SysTick reload behavior emulated incorrectly

Status in QEMU:
  New

Bug description:
  QEMU's emuation of SysTick on ARM is incorrect with respect to reload
  behavior.  This issue is described here, and also in a repository
  dedicated to the issue:

https://github.com/oxidecomputer/qemu-systick-bug

  
  (What follows is in Markdown, which I understand that Launchpad does
  not support; see the repository linked above for a rendering of it.)

  Take this Rust program:

  ```rust
  #![no_std]
  #![no_main]

  extern crate panic_semihosting;

  use cortex_m_rt::entry;
  use cortex_m_semihosting::hprintln;
  use cortex_m::peripheral::syst::SystClkSource;
  use cortex_m::peripheral::SYST;

  fn delay(syst:  cortex_m::peripheral::SYST, ms: u32)
  {
  /*
   * Configured for the LM3S6965, which has a default CPU clock of 12 Mhz
   */
  let reload = 12_000 * ms;

  syst.set_reload(reload);
  syst.clear_current();
  syst.enable_counter();

  hprintln!("waiting for {} ms (SYST_CVR={}) ...",
  ms, SYST::get_current()
  ).unwrap();

  while !syst.has_wrapped() {}

  hprintln!("  ... done (SYST_CVR={})\n",
  SYST::get_current()).unwrap();

  syst.disable_counter();
  }

  #[entry]
  fn main() -> ! {
  let p = cortex_m::Peripherals::take().unwrap();
  let mut syst = p.SYST;

  syst.set_clock_source(SystClkSource::Core);

  loop {
  delay( syst, 1000);
  delay( syst, 100);
  }
  }
  ```

  This program should oscillate between waiting for one second and waiting
  for 100 milliseconds.  Under hardware, this is more or less what it does
  (depending on core clock frequency); e.g., from an STM32F4107 (connected via
  OCD and with semi-hosting enabled):

  ```
  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=1102)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  ```

  Under QEMU, however, its behavior is quite different:

  ```
  $ cargo run
  Finished dev [unoptimized + debuginfo] target(s) in 0.03s
   Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic 
-semihosting-config enable=on,target=native -kernel 
target/thumbv7m-none-eabi/debug/qemu-systick-bug`
  waiting for 1000 ms (SYST_CVR=11999658) ...
... done (SYST_CVR=11986226)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186560)

  waiting for 1000 ms (SYST_CVR=1185996) ...
... done (SYST_CVR=11997350)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186581)
  ```

  In addition to the values being strangely wrong, the behavior is wrong:
  the first wait correctly waits for 1000 ms -- but the subsequent wait
  (which should be for 100 ms) is in fact 1000 ms, and the next wait (which
  should be for 1000 ms) is in fact 100 ms.  (That is, it appears as if
  the periods of the two delays have been switched.)

  The problems is that the QEMU ARM emulation code does not reload SYST_CVR from
  SYST_RVR if SYST_CSR.ENABLE is not set -- and moreover, that SYST_CVR is
  not reloaded from SYST_RVR even when SYST_CSR.ENABLE becomes set.  This is
  very explicit; from
  https://github.com/qemu/qemu/blob/8bac3ba57eecc466b7e73dabf7d19328a59f684e/hw/timer/armv7m_systick.c#L42-L60;>hw/timer/armv7m_systick.c:

  ```c
  static void systick_reload(SysTickState *s, int reset)
  {
  /* The Cortex-M3 Devices Generic User Guide says that "When the
   * ENABLE bit is set to 1, the counter loads the RELOAD value from the
   * SYST RVR register and then counts down". So, we need to check the
   * ENABLE bit before reloading the value.
   */
  trace_systick_reload();

  if ((s->control & SYSTICK_ENABLE) == 0) {
  

Re: [PATCH] hax: Windows doesn't like posix device names

2020-04-13 Thread Volker Rümelin
> On 22/03/20 22:02, Volker Rümelin wrote:
>> Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX
>> is enabled" replaced Windows device names with posix device
>> names. Revert this.
>>
>> Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled"

>> Queued, thanks.
>>
>> Paolo
>>

Hi Paolo,

I would like to remind you that without this patch qemu 5.0 on Windows will not 
work with HAX. There is already a bug report at

https://bugs.launchpad.net/bugs/1871250

With best regards,
Volker



Re: [PATCH for-5.0] qcow2: Add incompatibility note between backing files and raw external data files

2020-04-13 Thread Eric Blake

On 4/10/20 7:18 AM, Alberto Garcia wrote:

Backing files and raw external data files are mutually exclusive.
The documentation of the raw external data bit (in autoclear_features)
already indicates that, but we should also mention it on the other
side.

Suggested-by: Eric Blake 
Signed-off-by: Alberto Garcia 
---
  docs/interop/qcow2.txt | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index 640e0eca40..298a031310 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -25,6 +25,9 @@ The first cluster of a qcow2 image contains the file header:
  is stored (NB: The string is not null terminated). 0 if 
the
  image doesn't have a backing file.
  
+Note: backing files are incompatible with raw external data

+files (auto-clear feature bit 1).
+
   16 - 19:   backing_file_size
  Length of the backing file name in bytes. Must not be
  longer than 1023 bytes. Undefined if the image doesn't 
have



Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [Qemu-devel] [PATCH v3] net: cadence_gem: fix compilation error when debug is on

2020-04-13 Thread Ramon Fried
False alarm, exact same patch was merged by someone else.

On Mon, Apr 13, 2020 at 8:55 PM Ramon Fried  wrote:
>
> Hi.
> Just noticed that this patch didn't hit master.
> Got lost ?
>
> Thanks,
> Ramon.
>
> On Sat, Jun 15, 2019 at 9:16 AM Ramon Fried  wrote:
> >
> >
> >
> > On June 15, 2019 8:38:35 AM GMT+03:00, "Philippe Mathieu-Daudé" 
> >  wrote:
> > >Hi Ramon,
> > >
> > >On 6/15/19 7:15 AM, Ramon Fried wrote:
> > >> defining CADENCE_GEM_ERR_DEBUG causes compilation
> > >> errors, fix that.
> > >>
> > >> Signed-off-by: Ramon Fried 
> > >> ---
> > >> v2: change %lx to HWADDR_PRIx and %lx to %zdx
> > >> v3: change %zdx to %zx
> > >>
> > >>  hw/net/cadence_gem.c | 6 +++---
> > >>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > >> index 7f63411430..ecee22525c 100644
> > >> --- a/hw/net/cadence_gem.c
> > >> +++ b/hw/net/cadence_gem.c
> > >> @@ -982,8 +982,8 @@ static ssize_t gem_receive(NetClientState *nc,
> > >const uint8_t *buf, size_t size)
> > >>  return -1;
> > >>  }
> > >>
> > >> -DB_PRINT("copy %d bytes to 0x%x\n", MIN(bytes_to_copy,
> > >rxbufsize),
> > >> -rx_desc_get_buffer(s->rx_desc[q]));
> > >> +DB_PRINT("copy %d bytes to 0x%" HWADDR_PRIx "\n",
> > >MIN(bytes_to_copy, rxbufsize),
> > >> +rx_desc_get_buffer(s, s->rx_desc[q]));
> > >>
> > >>  /* Copy packet data to emulated DMA buffer */
> > >>  address_space_write(>dma_as, rx_desc_get_buffer(s,
> > >s->rx_desc[q]) +
> > >> @@ -1156,7 +1156,7 @@ static void gem_transmit(CadenceGEMState *s)
> > >>  if (tx_desc_get_length(desc) > sizeof(tx_packet) -
> > >> (p - tx_packet)) {
> > >>  DB_PRINT("TX descriptor @ 0x%x too large: size 0x%x
> > >space " \
> > >> - "0x%x\n", (unsigned)packet_desc_addr,
> > >> + "0x%zx\n", (unsigned)packet_desc_addr,
> > >>   (unsigned)tx_desc_get_length(desc),
> > >>   sizeof(tx_packet) - (p - tx_packet));
> > >>  break;
> > >>
> > >
> > >I still get an error when trying to build on 32bit host with
> > >CADENCE_GEM_ERR_DEBUG enabled (pre-existing to your patch):
> > >
> > >  CC  hw/net/cadence_gem.o
> > >./hw/net/cadence_gem.c: In function 'gem_receive':
> > >./hw/net/cadence_gem.c:973:14: error: format '%ld' expects argument of
> > >type 'long int', but argument 4 has type 'size_t {aka unsigned int}'
> > >[-Werror=format=]
> > >DB_PRINT("config bufsize: %d packet size: %ld\n", rxbufsize, size);
> > >  ^
> > >./hw/net/cadence_gem.c:38:24: note: in definition of macro 'DB_PRINT'
> > > fprintf(stderr, ## __VA_ARGS__); \
> > >^
> > >cc1: all warnings being treated as errors
> > >./rules.mak:69: recipe for target 'hw/net/cadence_gem.o' failed
> > >make: *** [hw/net/cadence_gem.o] Error 1
> > >
> > >However the 64bit host is indeed fixed, so I'm fine with your patch:
> > >Reviewed-by: Philippe Mathieu-Daudé 
> > >Tested-by: Philippe Mathieu-Daudé 
> > >
> > >Regards,
> > >
> > >Phil.
> > Thanks!
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.



Supported Sphinx Versions (was: Re: [PATCH for-5.0? 0/3] Make docs build work with Sphinx 3)

2020-04-13 Thread John Snow



On 4/11/20 2:29 PM, Peter Maydell wrote:
> Our current docs don't build with Sphinx 3, as noted in
> https://bugs.launchpad.net/bugs/1872113 -- this is a combination of:
>  (1) we are using the sphinx-build -W option so warnings are treated
>  as errors
>  (3) a kernel-doc script bug meant it was omitting a close-paren
>  when a function parameter was a function pointer; older Sphinx
>  ignored this but Sphinx 3 parses the function declaration and
>  warns about it; and because of (1) this is fatal to the QEMU build
>  (2) Sphinx 3 makes a breaking change in how it wants C structs
>  to be marked up (moving from 'c:type:: struct Foo' to
>  'c:struct:: Foo'); our use of the old syntax provokes a
>  warning, which again because of point (1) is fatal
> 
> Patch 1 extends configure's --disable-werror to cover Sphinx as
> well as the C compiler, so that at least there is a workaround
> (which will be automatic for release builds).
> 
> Patch 2 fixes the trivial kernel-doc bug.
> 
> Patch 3 adds and uses a new --sphinx-version option to kernel-doc,
> so that our Sphinx plugin can pass the Sphinx version down and
> the script can then choose the right syntax.
> 
> I've marked this up as 'for-5.0?' because I think it would be
> nice if at least patch 1 went in. Patch 2 seems uncontroversial
> (though I guess we should forward it up to the kernel folks
> since kernel-doc is from them originally). Patch 3 is the
> expedient change, but you could argue about whether this is
> the best way to tell kernel-doc what to do.
> 
> thanks
> -- PMM
> 

I was curious about our actual version compatibility, so I did some testing.

I modified configure to prefer 'sphinx-build' over 'sphinx-build-3' so
it would use my venv version, and then;

>From my qemu build directory (~/src/qemu/bin/git):

> python3 -m venv 200
> source ./200/bin/activate.fish
> pip install sphinx==2.0.0
> ../../configure --target-list='x86_64-softmmu' --enable-debug
--enable-docs; and cat config-host.mak | grep sphinx; and make html;


Repeat the process for the major versions we believe that we support in
the abstract (1.3.x through 2.4.x):

1.3: Can't even pass the configure check with a blank document.

Exception occurred:
  File
"/home/jhuston/src/qemu/bin/git/130/lib64/python3.7/site-packages/sphinx/environment.py",
line 146, in __init__
FileInput.__init__(self, *args, **kwds)
TypeError: __init__() got an unexpected keyword argument 'handle_io_errors'
The full traceback has been saved in /tmp/sphinx-err-owwisn63.log, if
you want to report the issue to the developers.

No idea.


1.4 - 1.4.9: Fails to build.

Warning, treated as error:
/home/jsnow/src/qemu/docs/system/images.rst:4: SEVERE: Duplicate ID:
"cmdoption-qcow2-arg-encrypt".

It doesn't seem to like the "encrypt.FOO" section names here and
considers them duplicates, cutting off at the '.'.

Not clear if there's a fix, or if it's worth caring about.


1.5 - 1.5.6: Fails to build.

Warning, treated as error:
/home/jsnow/src/qemu/docs/system/invocation.rst:544: WARNING: Malformed
option description '[enable=]PATTERN', should look like "opt", "-opt
args", "--opt args", "/opt args" or "+opt args"

... I actually don't know where this one goes wrong; that's not a valid
line number there. device-url-syntax.rst.inc isn't that long either, so
I don't know what this correlates to, unfortunately.

1.6.1 through 2.2.2 all appear to work just fine, but produce a lot of
warnings about a coming incompatibility with Docutils > 0.16.

2.3.0 - 2.4.4 work silently with Docutils 0.16.

3.0.0: Notably fails, as is the subject of this patch. :)




Conclusion:

Required: >= 1.6.1
Recommended: >= 2.3.0



We can make this a little easier by using python virtual environments as
part of our build tree; we can freeze version dependencies if we want to
get more reproducible python builds.

We might also begin "installing" the QAPI generator module into such a
virtual environment such that the include statements are written in a
more formal manner, which will assist for pylint and mypy gating, but
that's another email.


I want to send patches to:

1. Change configure to try and prefer a virtualenv version of
sphinx-build, when found

2. Change sphinx conf.py to require >= 1.6.1 so that the requirement is
documented

3. Update documentation (somewhere?) explaining our sphinx dependency
and which versions are required and why ("Because 1.5.x does not work
with our tree.")

--js




Re: Domain backup file explodes on s3fs

2020-04-13 Thread Leo Luan
Hi Eric and all,


When invoking "virsh backup-begin" to do a full backup using qcow2
driver to a new backup

target file that does not have a backing chain, is it safe to not zero
the unallocated

parts of the virtual disk?  Do we still depend on SEEK_DATA support in
this case to avoid

forcing zeros?


It looks like backup_run() in block/backup.c unsets the unallocated
parts of a copy bitmap

before starting the backup loop if s->sync_mode ==
MIRROR_SYNC_MODE_TOP. In a virsh backup-begin

full backup scenario, we observe that the mode is
MIRROR_SYNC_MODE_FULL, and the backup_loop()

function subsequently copies zeros for the entire virtual size,
including the unallocated parts

in the source qcow2 file.  Would it be safe to also unset the
unallocated parts in the copy

map when the sync_mode is MIRROR_SYNC_MODE_FULL if we know there is no
need to force zeros

because the target file is a new empty qcow2 file without a backing
file?  If so, maybe a

knob can be added to effect this behavior?


I guess the related code is changing in 5.0 and this issue may already
be adddressed.

Any updates/insights would be appreciated!


Thanks,

Leo


*From*: Eric Blake
*Subject*: Re: Domain backup file explodes on s3fs
*Date*: Tue, 7 Apr 2020 14:37:26 -0500
*User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.6.0
--

[adding libvirt list]

On 4/7/20 2:13 PM, Tim Haley wrote:

Hi all,


Have been playing with `virsh backup-begin` of late and think it's an excellent
feature. I've noticed one behavior I'm not sure I understand.

It looks like https://bugzilla.redhat.com/show_bug.cgi?id=1814664 is a similar
description of the same problem: namely, if qemu is not able to determine
that the destination already reads as zero, then it forcefully zeroes the
destination of a backup job. We may want to copy the fact that qemu 5.0 is
adding 'qemu-img convert --target-is-zero' to add a similar knob to the QMP
commands that trigger disk copying (blockdev-backup, blockdev-mirror,
possibly others) as well as logic to avoid writing zeroes when the
destination is already treated as zero (whether by a probe, or by the knob
being set).

...


If my /backups directory is just XFS, I get a backup file that looks like
it is just the size of data blocks in use

-rw--- 1 root  root  2769551360 Mar 19 16:56
vda.2aa450cc-6d2e-11ea-8de0-52542e0d008a

For a local file, qemu is easily able to probe whether the destination starts
as all zeroes (thanks to lseek(SEEK_DATA));

but if I write to an s3fs (object storage backend) the file blows up to the
whole size of the disk

-rw--- 1 root  root  8591507456 Mar 18 19:03
vda.2aa450cc-6d2e-11ea-8de0-52542e0d008a

whereas for s3fs, it looks like qemu does not have access to a quick test
to learn if the image starts all zero (POSIX does not provide a quick way
for doing this on a generic block device, but if you are aware of an ioctl
or otherwise that qemu could use, that might be helpful). Or maybe the s3fs
really is random contents rather than all zero, in which case forcefully
writing zeroes is the only correct behavior.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


Re: [PATCH v2] net: cadence_gem: clear RX control descriptor

2020-04-13 Thread Ramon Fried
Hi.
Just noticed that this patch didn't hit master.
Got lost ?

Thanks,
Ramon.

On Tue, Jul 16, 2019 at 2:58 PM Jason Wang  wrote:
>
>
> On 2019/7/16 下午6:59, Ramon Fried wrote:
> > The RX ring descriptors control field is used for setting
> > SOF and EOF (start of frame and end of frame).
> > The SOF and EOF weren't cleared from the previous descriptors,
> > causing inconsistencies in ring buffer.
> > Fix that by clearing the control field of every descriptors we're
> > processing.
> >
> > Signed-off-by: Ramon Fried 
> > Reviewed-by: Philippe Mathieu-Daudé 
> >
> > ---
> > v2:
> >* change function name to rx_desc_clear_control as proposed by
> >  Jason Wang
> >* Move the function call above the comment, as proposed by
> >  Philippe Mathieu-Daudé
> >
> >   hw/net/cadence_gem.c | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > index ecee22525c..cca3ce7f56 100644
> > --- a/hw/net/cadence_gem.c
> > +++ b/hw/net/cadence_gem.c
> > @@ -406,6 +406,11 @@ static inline void rx_desc_set_sof(uint32_t *desc)
> >   desc[1] |= DESC_1_RX_SOF;
> >   }
> >
> > +static inline void rx_desc_clear_control(uint32_t *desc)
> > +{
> > +desc[1]  = 0;
> > +}
> > +
> >   static inline void rx_desc_set_eof(uint32_t *desc)
> >   {
> >   desc[1] |= DESC_1_RX_EOF;
> > @@ -993,6 +998,8 @@ static ssize_t gem_receive(NetClientState *nc, const 
> > uint8_t *buf, size_t size)
> >   rxbuf_ptr += MIN(bytes_to_copy, rxbufsize);
> >   bytes_to_copy -= MIN(bytes_to_copy, rxbufsize);
> >
> > +rx_desc_clear_control(s->rx_desc[q]);
> > +
> >   /* Update the descriptor.  */
> >   if (first_desc) {
> >   rx_desc_set_sof(s->rx_desc[q]);
>
>
> Applied.
>
> Thanks
>



Re: [Qemu-devel] [PATCH v3] net: cadence_gem: fix compilation error when debug is on

2020-04-13 Thread Ramon Fried
Hi.
Just noticed that this patch didn't hit master.
Got lost ?

Thanks,
Ramon.

On Sat, Jun 15, 2019 at 9:16 AM Ramon Fried  wrote:
>
>
>
> On June 15, 2019 8:38:35 AM GMT+03:00, "Philippe Mathieu-Daudé" 
>  wrote:
> >Hi Ramon,
> >
> >On 6/15/19 7:15 AM, Ramon Fried wrote:
> >> defining CADENCE_GEM_ERR_DEBUG causes compilation
> >> errors, fix that.
> >>
> >> Signed-off-by: Ramon Fried 
> >> ---
> >> v2: change %lx to HWADDR_PRIx and %lx to %zdx
> >> v3: change %zdx to %zx
> >>
> >>  hw/net/cadence_gem.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> >> index 7f63411430..ecee22525c 100644
> >> --- a/hw/net/cadence_gem.c
> >> +++ b/hw/net/cadence_gem.c
> >> @@ -982,8 +982,8 @@ static ssize_t gem_receive(NetClientState *nc,
> >const uint8_t *buf, size_t size)
> >>  return -1;
> >>  }
> >>
> >> -DB_PRINT("copy %d bytes to 0x%x\n", MIN(bytes_to_copy,
> >rxbufsize),
> >> -rx_desc_get_buffer(s->rx_desc[q]));
> >> +DB_PRINT("copy %d bytes to 0x%" HWADDR_PRIx "\n",
> >MIN(bytes_to_copy, rxbufsize),
> >> +rx_desc_get_buffer(s, s->rx_desc[q]));
> >>
> >>  /* Copy packet data to emulated DMA buffer */
> >>  address_space_write(>dma_as, rx_desc_get_buffer(s,
> >s->rx_desc[q]) +
> >> @@ -1156,7 +1156,7 @@ static void gem_transmit(CadenceGEMState *s)
> >>  if (tx_desc_get_length(desc) > sizeof(tx_packet) -
> >> (p - tx_packet)) {
> >>  DB_PRINT("TX descriptor @ 0x%x too large: size 0x%x
> >space " \
> >> - "0x%x\n", (unsigned)packet_desc_addr,
> >> + "0x%zx\n", (unsigned)packet_desc_addr,
> >>   (unsigned)tx_desc_get_length(desc),
> >>   sizeof(tx_packet) - (p - tx_packet));
> >>  break;
> >>
> >
> >I still get an error when trying to build on 32bit host with
> >CADENCE_GEM_ERR_DEBUG enabled (pre-existing to your patch):
> >
> >  CC  hw/net/cadence_gem.o
> >./hw/net/cadence_gem.c: In function 'gem_receive':
> >./hw/net/cadence_gem.c:973:14: error: format '%ld' expects argument of
> >type 'long int', but argument 4 has type 'size_t {aka unsigned int}'
> >[-Werror=format=]
> >DB_PRINT("config bufsize: %d packet size: %ld\n", rxbufsize, size);
> >  ^
> >./hw/net/cadence_gem.c:38:24: note: in definition of macro 'DB_PRINT'
> > fprintf(stderr, ## __VA_ARGS__); \
> >^
> >cc1: all warnings being treated as errors
> >./rules.mak:69: recipe for target 'hw/net/cadence_gem.o' failed
> >make: *** [hw/net/cadence_gem.o] Error 1
> >
> >However the 64bit host is indeed fixed, so I'm fine with your patch:
> >Reviewed-by: Philippe Mathieu-Daudé 
> >Tested-by: Philippe Mathieu-Daudé 
> >
> >Regards,
> >
> >Phil.
> Thanks!
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



[Bug 1872237] Re: SysTick reload behavior emulated incorrectly

2020-04-13 Thread Bryan Cantrill
@pmaydell: Thanks for the quick response!  For whatever it's worth, I think
that there's definitely a bunch of interest in the M-profile work:  in the
embedded Rust space (for example) Cortex-M is very much the reference 
platform.  Viz. the Embedded Rust Book:

  https://rust-embedded.github.io/book/

For this, we have been using an xPack QEMU fork:

  https://github.com/xpack-dev-tools/qemu-arm-xpack

Having a QEMU that had first-class support for a widely-available development
platform (e.g., the STM32F Discovery) would be of great interest to this
community -- and I'm sure many others!

To prevent filing of issues that are already known:  is there a list of
known issues with the M-profile with QEMU?

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

Title:
  SysTick reload behavior emulated incorrectly

Status in QEMU:
  New

Bug description:
  QEMU's emuation of SysTick on ARM is incorrect with respect to reload
  behavior.  This issue is described here, and also in a repository
  dedicated to the issue:

https://github.com/oxidecomputer/qemu-systick-bug

  
  (What follows is in Markdown, which I understand that Launchpad does
  not support; see the repository linked above for a rendering of it.)

  Take this Rust program:

  ```rust
  #![no_std]
  #![no_main]

  extern crate panic_semihosting;

  use cortex_m_rt::entry;
  use cortex_m_semihosting::hprintln;
  use cortex_m::peripheral::syst::SystClkSource;
  use cortex_m::peripheral::SYST;

  fn delay(syst:  cortex_m::peripheral::SYST, ms: u32)
  {
  /*
   * Configured for the LM3S6965, which has a default CPU clock of 12 Mhz
   */
  let reload = 12_000 * ms;

  syst.set_reload(reload);
  syst.clear_current();
  syst.enable_counter();

  hprintln!("waiting for {} ms (SYST_CVR={}) ...",
  ms, SYST::get_current()
  ).unwrap();

  while !syst.has_wrapped() {}

  hprintln!("  ... done (SYST_CVR={})\n",
  SYST::get_current()).unwrap();

  syst.disable_counter();
  }

  #[entry]
  fn main() -> ! {
  let p = cortex_m::Peripherals::take().unwrap();
  let mut syst = p.SYST;

  syst.set_clock_source(SystClkSource::Core);

  loop {
  delay( syst, 1000);
  delay( syst, 100);
  }
  }
  ```

  This program should oscillate between waiting for one second and waiting
  for 100 milliseconds.  Under hardware, this is more or less what it does
  (depending on core clock frequency); e.g., from an STM32F4107 (connected via
  OCD and with semi-hosting enabled):

  ```
  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=1102)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  ```

  Under QEMU, however, its behavior is quite different:

  ```
  $ cargo run
  Finished dev [unoptimized + debuginfo] target(s) in 0.03s
   Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic 
-semihosting-config enable=on,target=native -kernel 
target/thumbv7m-none-eabi/debug/qemu-systick-bug`
  waiting for 1000 ms (SYST_CVR=11999658) ...
... done (SYST_CVR=11986226)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186560)

  waiting for 1000 ms (SYST_CVR=1185996) ...
... done (SYST_CVR=11997350)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186581)
  ```

  In addition to the values being strangely wrong, the behavior is wrong:
  the first wait correctly waits for 1000 ms -- but the subsequent wait
  (which should be for 100 ms) is in fact 1000 ms, and the next wait (which
  should be for 1000 ms) is in fact 100 ms.  (That is, it appears as if
  the periods of the two delays have been switched.)

  The problems is that the QEMU ARM emulation code does not reload SYST_CVR from
  SYST_RVR if SYST_CSR.ENABLE is not set -- and moreover, that SYST_CVR is
  not reloaded from SYST_RVR even when SYST_CSR.ENABLE becomes set.  This is
  very explicit; from
  https://github.com/qemu/qemu/blob/8bac3ba57eecc466b7e73dabf7d19328a59f684e/hw/timer/armv7m_systick.c#L42-L60;>hw/timer/armv7m_systick.c:

  ```c
  static void systick_reload(SysTickState *s, int reset)
  {
  /* The Cortex-M3 Devices Generic User Guide says that "When the
   * ENABLE bit is set to 1, the counter loads the RELOAD value from the
   * SYST RVR register and then counts down". So, we need to check the
   * ENABLE bit before reloading the value.
   */
  trace_systick_reload();

  if ((s->control & SYSTICK_ENABLE) == 0) {
  return;
  }

  if (reset) {
  s->tick = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
  }
  s->tick += (s->reload + 1) * 

Re: [PATCH v4 30/30] iotests: Add tests for qcow2 images with extended L2 entries

2020-04-13 Thread Alberto Garcia
On Thu 09 Apr 2020 02:22:37 PM CEST, Max Reitz wrote:
>> +### Write subcluster #31-#34 (cluster overlap) ###
>
> #31-#34, I think.

That's what I wrote :-?

>> +### Partially zeroize an unallocated cluster (#3)
>> +if [ "$use_backing_file" = "yes" ]; then
>> +alloc="`seq 0 15`"; zero=""
>
> Isn’t this a TODO?  (I.e., ideally we’d want the first 16 subclusters
> to be zero, and the last 16 subclusters to be unallocated, right?)
>
> (I’m asking because you did raise a TODO for the “Zero subcluster #1”
> test)

Maybe, but I just implemented zeroize at the subcluster level :-) Wait
for the next version of the series.

>> +echo
>> +echo "### Compressed cluster with subcluster bitmap != 0 - 
>> $corruption_test_cmd test ###"
>> +echo
>> +# We actually don't consider this a corrupted image.
>> +# The bitmap in compressed clusters is unused so QEMU should just 
>> ignore it.
>> +_make_test_img 1M
>> +$QEMU_IO -c 'write -q -P 11 -c 0 64k' "$TEST_IMG"
>> +poke_file "$TEST_IMG" $(($l2_offset+11)) "\x01\x01"
>> +alloc="24"; zero="0"
>> +_verify_l2_bitmap 0 "$alloc" "$zero"
>> +$QEMU_IO -c "$corruption_test_cmd -P 11 0 64k" "$TEST_IMG" | 
>> _filter_qemu_io
>
> It might be interesting to see the bitmap after the write, i.e., that
> it’s just been ignored.

Yeah, why not.

>> +echo "# 16K clusters, 64GB, extended_l2=off" # This needs one L1 table
>
> You mean one full L1 table cluster?
>
>> +$QEMU_IMG measure --size 64G -O qcow2 -o cluster_size=16k,extended_l2=off
>> +echo "# 16K clusters, 64GB, extended_l2=on"  # This needs two L2 tables
>
> And two full L1 table clusters?

You're right, I'll correct that.

Berto



[PATCH] .gitignore: include common build sub-directories

2020-04-13 Thread Alex Bennée
As out-of-tree builds become more common (or rather building in a
subdir) we can add a lot of load to "git ls-files" as it hunts down
sub-directories that are irrelevant to the source tree. This is
especially annoying if you have a prompt that attempts to summarise
the current git status on command completion.

Signed-off-by: Alex Bennée 
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 0c5af83aa74..7757dc08a08 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,6 +141,8 @@ cscope.*
 tags
 TAGS
 docker-src.*
+build
+builds
 *~
 *.ast_raw
 *.depend_raw
-- 
2.20.1




Re: [PATCH 20/31] target/arm: Implement SVE2 complex integer add

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:20 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index b5afa34efe..a3653007ac 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1289,6 +1289,48 @@ DO_BITPERM(sve2_bgrp_d, uint64_t, bitgroup)
>
>  #undef DO_BITPERM
>
> +#define DO_CADD(NAME, TYPE, H, ADD_OP, SUB_OP)  \
> +void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc)  \
> +{   \
> +intptr_t i, opr_sz = simd_oprsz(desc);  \
> +int sub_r = simd_data(desc);\
> +if (sub_r) {\
> +for (i = 0; i < opr_sz; i += 2 * sizeof(TYPE)) {\
> +TYPE acc_r = *(TYPE *)(vn + H(i));  \
> +TYPE acc_i = *(TYPE *)(vn + H(i + sizeof(TYPE)));   \
> +TYPE el2_r = *(TYPE *)(vm + H(i));  \
> +TYPE el2_i = *(TYPE *)(vm + H(i + sizeof(TYPE)));   \
> +acc_r = SUB_OP(acc_r, el2_i);   \
> +acc_i = ADD_OP(acc_i, el2_r);   \
> +*(TYPE *)(vd + H(i)) = acc_r;   \
> +*(TYPE *)(vd + H(i + sizeof(TYPE))) = acc_i;\
> +}   \
> +} else {\
> +for (i = 0; i < opr_sz; i += 2 * sizeof(TYPE)) {\
> +TYPE acc_r = *(TYPE *)(vn + H(i));  \
> +TYPE acc_i = *(TYPE *)(vn + H(i + sizeof(TYPE)));   \
> +TYPE el2_r = *(TYPE *)(vm + H(i));  \
> +TYPE el2_i = *(TYPE *)(vm + H(i + sizeof(TYPE)));   \
> +acc_r = ADD_OP(acc_r, el2_i);   \
> +acc_i = SUB_OP(acc_i, el2_r);   \
> +*(TYPE *)(vd + H(i)) = acc_r;   \
> +*(TYPE *)(vd + H(i + sizeof(TYPE))) = acc_i;\
> +}   \
> +}   \
> +}

The then/else branches of if (sub_r) are swapped.

Laurent



Re: [PATCH 22/31] target/arm: Implement SVE2 integer add/subtract long with carry

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:17 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index a0995d95c7..aa330f75c3 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
[...]
> +void HELPER(sve2_adcl_d)(void *vd, void *va, void *vn, void *vm, uint32_t 
> desc)
> +{
> +intptr_t i, opr_sz = simd_oprsz(desc);
> +int sel = extract32(desc, SIMD_DATA_SHIFT, 1) * 32;
> +uint64_t inv = -(uint64_t)extract32(desc, SIMD_DATA_SHIFT + 1, 1);
> +uint64_t *d = vd, *a = va, *n = vn, *m = vm;
> +
> +for (i = 0; i < opr_sz / 8; i += 2) {
> +Int128 e1 = int128_make64(a[i]);
> +Int128 e2 = int128_make64(n[i + sel] ^ inv);
> +Int128 c = int128_make64(m[i + 1] & 1);
> +Int128 r = int128_add(int128_add(e1, e2), c);
> +d[i + 0] = int128_getlo(r);
> +d[i + 1] = int128_gethi(r);
> +}
> +}

sel should not be multiplied by 32.

Laurent



Re: [PATCH 21/31] target/arm: Implement SVE2 integer absolute difference and accumulate long

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:18 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index a3653007ac..a0995d95c7 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1216,6 +1216,30 @@ DO_ZZZ_NTB(sve2_eoril_d, uint64_t, , DO_EOR)
>
>  #undef DO_ZZZ_NTB
>
> +#define DO_ABAL(NAME, TYPE, TYPEN) \
> +void HELPER(NAME)(void *vd, void *va, void *vn, void *vm, uint32_t desc) \
> +{  \
> +intptr_t i, opr_sz = simd_oprsz(desc); \
> +int sel1 = (simd_data(desc) & 1) * sizeof(TYPE);   \
> +int sel2 = (simd_data(desc) & 2) * (sizeof(TYPE) / 2); \
> +for (i = 0; i < opr_sz; i += sizeof(TYPE)) {   \
> +TYPE nn = (TYPEN)(*(TYPE *)(vn + i) >> sel1);  \
> +TYPE mm = (TYPEN)(*(TYPE *)(vm + i) >> sel2);  \
> +TYPE aa = *(TYPE *)(va + i);   \
> +*(TYPE *)(vd + i) = DO_ABD(nn, mm) + aa;   \
> +}  \
> +}

ABAL is either top or bottom not a mix of two.  So only sel1 is needed
and its multiplicand should be the number of bits of TYPEN.
vd is both a source and a destination so a temporary should be used.

Laurent



Re: [PATCH 13/31] target/arm: Implement SVE2 integer add/subtract wide

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:17 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 7d7a59f620..44503626e4 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1131,6 +1131,36 @@ DO_ZZZ_TB(sve2_uabdl_d, uint64_t, uint32_t, DO_ABD)
>
>  #undef DO_ZZZ_TB
>
> +#define DO_ZZZ_WTB(NAME, TYPE, TYPEN, OP) \
> +void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
> +{  \
> +intptr_t i, opr_sz = simd_oprsz(desc); \
> +int sel2 = (simd_data(desc) & 1) * sizeof(TYPE);   \
> +for (i = 0; i < opr_sz; i += sizeof(TYPE)) {   \
> +TYPE nn = *(TYPE *)(vn + i);   \
> +TYPE mm = (TYPEN)(*(TYPE *)(vm + i) >> sel2);  \
> +*(TYPE *)(vd + i) = OP(nn, mm);\
> +}  \
> +}

For sel2 the multiplicand should be the number of bits of TYPEN.

Laurent



Re: [PATCH 11/31] target/arm: Implement SVE2 integer add/subtract long

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:09 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index bee00eaa44..7d7a59f620 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1088,6 +1088,49 @@ DO_ZZW(sve_lsl_zzw_s, uint32_t, uint64_t, H1_4, DO_LSL)
>  #undef DO_ZPZ
>  #undef DO_ZPZ_D
>
> +/*
> + * Three-operand expander, unpredicated, in which the two inputs are
> + * selected from the top or bottom half of the wide column.
> + */
> +#define DO_ZZZ_TB(NAME, TYPE, TYPEN, OP) \
> +void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
> +{  \
> +intptr_t i, opr_sz = simd_oprsz(desc); \
> +int sel1 = (simd_data(desc) & 1) * sizeof(TYPE);   \
> +int sel2 = (simd_data(desc) & 2) * (sizeof(TYPE) / 2); \
> +for (i = 0; i < opr_sz; i += sizeof(TYPE)) {   \
> +TYPE nn = (TYPEN)(*(TYPE *)(vn + i) >> sel1);  \
> +TYPE mm = (TYPEN)(*(TYPE *)(vm + i) >> sel2);  \
> +*(TYPE *)(vd + i) = OP(nn, mm);\
> +}  \
> +}

For sel1/sel2 the multiplicand should be the number of bits in TYPEN.

Laurent



Re: [PATCH-for-5.1 v3 06/23] hw/arm/msf2-soc: Add missing error-propagation code

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:53 PM Philippe Mathieu-Daudé  wrote:
>
> Patch created mechanically by running:
>
>   $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file scripts/coccinelle/use-error_propagate-in-realize.cocci \
> --keep-comments --smpl-spacing --in-place --dir hw
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/arm/msf2-soc.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
> index e448b0ab74..7619e71cfa 100644
> --- a/hw/arm/msf2-soc.c
> +++ b/hw/arm/msf2-soc.c
> @@ -93,7 +93,11 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, Error 
> **errp)
>  MemoryRegion *system_memory = get_system_memory();
>
>  memory_region_init_rom(>nvm, OBJECT(dev_soc), "MSF2.eNVM", 
> s->envm_size,
> -   _fatal);
> +   );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  /*
>   * On power-on, the eNVM region 0x6000 is automatically
>   * remapped to the Cortex-M3 processor executable region
> @@ -107,7 +111,11 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>  memory_region_add_subregion(system_memory, 0, >nvm_alias);
>
>  memory_region_init_ram(>sram, NULL, "MSF2.eSRAM", s->esram_size,
> -   _fatal);
> +   );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
>
>  armv7m = DEVICE(>armv7m);
> @@ -115,7 +123,11 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>  qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
>  qdev_prop_set_bit(armv7m, "enable-bitband", true);
>  object_property_set_link(OBJECT(>armv7m), OBJECT(get_system_memory()),
> - "memory", _abort);
> + "memory", );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  object_property_set_bool(OBJECT(>armv7m), true, "realized", );
>  if (err != NULL) {
>  error_propagate(errp, err);
> @@ -184,8 +196,12 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, 
> Error **errp)
>  bus_name = g_strdup_printf("spi%d", i);
>  object_property_add_alias(OBJECT(s), bus_name,
>OBJECT(>spi[i]), "spi",
> -  _abort);
> +  );
>  g_free(bus_name);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  }
>
>  /* Below devices are not modelled yet. */
> --
> 2.21.1
>
>



Re: [PATCH-for-5.1 v3 01/24] various: Remove suspicious '\' character outside of #define in C code

2020-04-13 Thread Alistair Francis
On Sun, Apr 12, 2020 at 3:38 PM Philippe Mathieu-Daudé  wrote:
>
> Fixes the following coccinelle warnings:
>
>   $ spatch --sp-file --verbose-parsing  ... \
>   scripts/coccinelle/remove_local_err.cocci
>   ...
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/ppc/translate_init.inc.c:5213
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/ppc/translate_init.inc.c:5261
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:166
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:167
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:169
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:170
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:171
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:172
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/microblaze/cpu.c:173
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5787
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5789
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5800
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5801
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5802
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5804
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5805
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:5806
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./target/i386/cpu.c:6329
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/sd/sdhci.c:1133
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/scsi/scsi-disk.c:3081
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/net/virtio-net.c:1529
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./hw/riscv/sifive_u.c:468
>   SUSPICIOUS: a \ character appears outside of a #define at ./dump/dump.c:1895
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2209
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2215
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:2221
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/vhdx.c:
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/replication.c:172
>   SUSPICIOUS: a \ character appears outside of a #define at 
> ./block/replication.c:173
>
> Reviewed-by: Marc-André Lureau 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  block/replication.c |  4 ++--
>  block/vhdx.c|  8 
>  dump/dump.c |  2 +-
>  hw/net/virtio-net.c |  2 +-
>  hw/riscv/sifive_u.c |  2 +-
>  hw/scsi/scsi-disk.c |  2 +-
>  hw/sd/sdhci.c   |  2 +-
>  target/i386/cpu.c   | 18 +-
>  target/microblaze/cpu.c | 14 +++---
>  target/ppc/translate_init.inc.c |  4 ++--
>  10 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/block/replication.c b/block/replication.c
> index da013c2041..971f0fe266 100644
> --- a/block/replication.c
> +++ b/block/replication.c
> @@ -172,8 +172,8 @@ static void replication_child_perm(BlockDriverState *bs, 
> BdrvChild *c,
>  if ((bs->open_flags & (BDRV_O_INACTIVE | BDRV_O_RDWR)) == BDRV_O_RDWR) {
>  *nperm |= BLK_PERM_WRITE;
>  }
> -*nshared = BLK_PERM_CONSISTENT_READ \
> -   | BLK_PERM_WRITE \
> +*nshared = BLK_PERM_CONSISTENT_READ
> +   | BLK_PERM_WRITE
> | BLK_PERM_WRITE_UNCHANGED;
>  return;
>  }
> diff --git a/block/vhdx.c b/block/vhdx.c
> index 33e57cd656..e16fdc2f2d 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -2206,20 +2206,20 @@ static QemuOptsList vhdx_create_opts = {
> .name = VHDX_BLOCK_OPT_BLOCK_SIZE,
> .type = QEMU_OPT_SIZE,
> .def_value_str = stringify(0),
> -   .help = "Block Size; min 1MB, max 256MB. " \
> +   .help = "Block Size; min 1MB, max 256MB. "
> "0 means auto-calculate based on image size."
> },
> {
> .name = BLOCK_OPT_SUBFMT,
> .type = QEMU_OPT_STRING,
> -   .help = "VHDX format type, can be either 'dynamic' or 'fixed'. "\
> +   .help = "VHDX format type, can be either 'dynamic' or 'fixed'. "
> "Default is 'dynamic'."
> },
> {
> .name = VHDX_BLOCK_OPT_ZERO,
>   

Re: [PATCH 09/31] target/arm: Implement SVE2 integer pairwise arithmetic

2020-04-13 Thread Laurent Desnogues
On Fri, Mar 27, 2020 at 12:16 AM Richard Henderson
 wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 5d75aed7b7..d7c181ddb8 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -681,6 +681,73 @@ DO_ZPZZ_D(sve2_uhsub_zpzz_d, uint64_t, DO_HSUB_D)
>  #undef DO_ZPZZ
>  #undef DO_ZPZZ_D
>
> +/*
> + * Three operand expander, operating on element pairs.
> + * If the slot I is even, the elements from from VN {I, I+1}.
> + * If the slot I is odd, the elements from from VM {I-1, I}.
> + */
> +#define DO_ZPZZ_PAIR(NAME, TYPE, H, OP) \
> +void HELPER(NAME)(void *vd, void *vn, void *vm, void *vg, uint32_t desc) \
> +{   \
> +intptr_t i, opr_sz = simd_oprsz(desc);  \
> +for (i = 0; i < opr_sz; ) { \
> +uint16_t pg = *(uint16_t *)(vg + H1_2(i >> 3)); \
> +do {\
> +if (pg & 1) {   \
> +void *p = (i & 1 ? vm : vn);\
> +TYPE nn = *(TYPE *)(p + H(i & ~1)); \
> +TYPE mm = *(TYPE *)(p + H(i | 1));  \
> +*(TYPE *)(vd + H(i)) = OP(nn, mm);  \
> +}   \
> +i += sizeof(TYPE), pg >>= sizeof(TYPE); \
> +} while (i & 15);   \
> +}   \
> +}

You should not use 1 as mask but sizeof(TYPE).
A temporary should be used because vd also is a source.

> +/* Similarly, specialized for 64-bit operands.  */
> +#define DO_ZPZZ_PAIR_D(NAME, TYPE, OP)  \
> +void HELPER(NAME)(void *vd, void *vn, void *vm, void *vg, uint32_t desc) \
> +{   \
> +intptr_t i, opr_sz = simd_oprsz(desc) / 8;  \
> +TYPE *d = vd, *n = vn, *m = vm; \
> +uint8_t *pg = vg;   \
> +for (i = 0; i < opr_sz; i += 1) {   \
> +if (pg[H1(i)] & 1) {\
> +TYPE *p = (i & 1 ? m : n) + (i & ~1);   \
> +TYPE nn = p[0], mm = p[1];  \
> +d[i] = OP(nn, mm);  \
> +}   \
> +}   \
> +}

A temporary should be used because vd also is a source.

Laurent



Re: [PATCH v2] gdbstub: Fix segment fault for i386 target

2020-04-13 Thread Alex Bennée


Changbin Du  writes:

> With GByteArray, we should pass the object itself but not to plus an offset.
>
> gdb log:
> Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> __memmove_avx_unaligned_erms () at 
> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384
> 384   ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file 
> or directory.
>
> Fixes: a010bdbe71 ("gdbstub: extend GByteArray to read register helpers")
> Signed-off-by: Changbin Du 
>
> ---
> v2: remove m68k fix since it's already queued.

I also have Peter Xu's fix for i386:

  
https://patchew.org/QEMU/20200409211529.5269-1-alex.ben...@linaro.org/20200409211529.5269-10-alex.ben...@linaro.org/

But I'll happily add your Reported-by credit to that patch.

> ---
>  target/i386/gdbstub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
> index f3d23b614e..b98a99500a 100644
> --- a/target/i386/gdbstub.c
> +++ b/target/i386/gdbstub.c
> @@ -106,7 +106,7 @@ int x86_cpu_gdb_read_register(CPUState *cs, GByteArray 
> *mem_buf, int n)
>  } else if (n >= IDX_FP_REGS && n < IDX_FP_REGS + 8) {
>  floatx80 *fp = (floatx80 *) >fpregs[n - IDX_FP_REGS];
>  int len = gdb_get_reg64(mem_buf, cpu_to_le64(fp->low));
> -len += gdb_get_reg16(mem_buf + len, cpu_to_le16(fp->high));
> +len += gdb_get_reg16(mem_buf, cpu_to_le16(fp->high));
>  return len;
>  } else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
>  n -= IDX_XMM_REGS;


-- 
Alex Bennée



Re: [PULL v2 0/8] Misc patches for QEMU 5.0-rc3

2020-04-13 Thread Peter Maydell
On Mon, 13 Apr 2020 at 08:05, Paolo Bonzini  wrote:
>
> The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20200406' into staging (2020-04-06 
> 12:36:45 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 267514b33ffa3f315adc26fc14d89f92e90840f5:
>
>   module: increase dirs array size by one (2020-04-13 02:56:18 -0400)
>
> 
> Bugfixes, and reworking of the atomics documentation.
>
> 


Applied, thanks.

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

-- PMM



Re: [RFC patch v1 0/3] qemu-file writing performance improving

2020-04-13 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1586776334-641239-1-git-send-email-dplotni...@virtuozzo.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

/tmp/qemu-test/src/migration/qemu-file.c:415: undefined reference to 
`aio_task_pool_start_task'
/usr/bin/ld: migration/qemu-file.o: in function `qemu_file_switch_current_buf':
/tmp/qemu-test/src/migration/qemu-file.c:380: undefined reference to 
`aio_task_pool_wait_slot'
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)
make: *** [/tmp/qemu-test/src/rules.mak:124: tests/test-vmstate] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 664, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=305548e9be434ddeb3a06c706e9dab1a', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 
'TARGET_LIST=x86_64-softmmu', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 
'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', 
'-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-aounzkok/src/docker-src.2020-04-13-09.44.50.27035:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-debug']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=305548e9be434ddeb3a06c706e9dab1a
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-aounzkok/src'
make: *** [docker-run-test-debug@fedora] Error 2

real6m39.403s
user0m9.069s


The full log is available at
http://patchew.org/logs/1586776334-641239-1-git-send-email-dplotni...@virtuozzo.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: colo: qemu 4.2.0 vs. qemu 5.0.0-rc2 performance regression

2020-04-13 Thread Lukas Straub
On Sat, 11 Apr 2020 19:16:54 +0200
Lukas Straub  wrote:

> Hello Everyone,
> I did some Benchmarking with iperf3 and memtester (to dirty some guest memory)
> of colo performance in qemu 4.2.0 and in qemu 5.0.0-rc2
> with my bugfixes on top.( 
> https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg01432.html )
> 
> I have taken the average over 4 runs.
> Client-to-server tcp bandwidth rose slightly from ~83.98 Mbit/s to ~89.40 
> Mbits.
> Server-to-client tcp bandwidth fell from ~9.73 Mbit/s to ~1.79 Mbit/s.
> Client-to-server udp bandwidth stayed the same at 1.05 Mbit/s
> and jitter rose from ~5.12 ms to ~10.77 ms.
> Server-to-client udp bandwidth fell from ~380.5 Kbit/s to ~33.6 Kbit/s
> and jitter rose from ~41.74 ms to ~83976.15 ms (!).
> 
> I haven't looked closely into it, but i think
> 0393031a16735835a441b6d6e0495a1bd14adb90 "COLO: Optimize memory back-up 
> process"
> is the culprint as it reduces vm downtime for the checkpoints but increases
> the overall checkpoint time and we can only release miscompared primary 
> packets
> after the checkpoint is completely finished.
> 
> Another thing that I noticed: With 4.2.0, the secondary qemu uses thrice
> the amount of gest memory. With 5.0.0-rc2 it's just double the amount of
> guest memory. So maybe the ram cache isn't working properly?
> 
> Regards,
> Lukas Straub

Hmm,
I looked at my test again and saw that the results where very noisy, so qemu 
5.0.0-rc2
being slower was just a coincidence. I did increase the test time and the 
results are 
more meaningful now. Now qemu 5.0.0-rc2 is around the same speed and still 
faster
in the client-to-server tcp case.

Sorry for the noise.

Regards,
Lukas Straub


pgp6dUmlTa8z_.pgp
Description: OpenPGP digital signature


Re: [PATCH v2 0/6] Automation of Coverity Scan uploads (via Docker)

2020-04-13 Thread Paolo Bonzini
Yes, go ahead. I would like to add a docker-coverity Makefile target but I
can do that later.

Il lun 13 apr 2020, 14:13 Peter Maydell  ha
scritto:

> What's your view on this series, Paolo? Personally I'd like
> to put it into master, because at least then we have something
> that we can do Coverity runs on, whereas AIUI at the moment
> we don't. But I'd rather not put it in after rc3, which is
> tomorrow...
>
> thanks
> -- PMM
>
> On Thu, 19 Mar 2020 at 19:33, Peter Maydell 
> wrote:
> >
> > v1 of this series was over a year ago:
> > https://patchew.org/QEMU/20181113184641.4492-1-peter.mayd...@linaro.org/
> >
> > I dusted it off and fixed some stuff because Paolo reports that the
> > machine he was previously using for uploads can't run the Coverity
> > tools any more.
> >
> > The first four patches are fixes for problems that cause the Coverity
> > tool not to be able to scan everything.  The first one in particular
> > meant that every compilation unit failed, which would block uploads.
> > The other 3 would reduce the scan coverage but weren't fatal.  (The
> > only remaining warnings in the log are where Coverity complains about
> > asm intrinsics system headers.)
> >
> > With these scripts you can do an upload with
> > COVERITY_TOKEN=n ./scripts/coverity-scan/run-coverity-scan
> --docker
> > (where  is the project's secret token which admins can
> > get from the Coverity web UI).
> >
> > I did in fact do an upload to test it, so the currently visible
> > results on the website are the result of a scan on ce73691e258 plus
> > this series.
> >
> > The new upload has +112 defects, which is quite a lot, but I don't
> > think it's so many that it is "defects we rejected as false positives
> > coming back again"; my guess is a combination of the fixes in the
> > first 4 patches increasing coverage plus we haven't run a test in a
> > while plus maybe the script has some more config options enabled that
> > Paolo's box did not.  (In the web UI defects that were dismissed as
> > FPs seem still to be considered present-but-dismissed, so I think
> > that's OK.)
> >
> > Not much has changed since v1; I didn't get very much feedback
> > the first time around[*]. Docker still seems to do the "download
> > the Coverity tools" part more often than I expect. On the other
> > hand "actually automated with a script in the tree" beats "not
> > automated and currently broken" so maybe this patchset as it
> > stands is good enough, given that basically 1 or 2 people ever
> > will be running the script ?
> >
> > [*] Eric will note that yes, the script still uses set -e.
> >
> > (Like v1 this doesn't try to tie it into Travis, but we could
> > in theory do that some day, or have some other automated once
> > a week run of the script.)
> >
> > thanks
> > -- PMM
> >
> > Peter Maydell (6):
> >   osdep.h: Drop no-longer-needed Coverity workarounds
> >   thread.h: Fix Coverity version of qemu_cond_timedwait()
> >   thread.h: Remove trailing semicolons from Coverity qemu_mutex_lock()
> > etc
> >   linux-user/flatload.c: Use "" for include of QEMU header target_flat.h
> >   scripts/run-coverity-scan: Script to run Coverity Scan build
> >   scripts/coverity-scan: Add Docker support
> >
> >  include/qemu/osdep.h   |  14 -
> >  include/qemu/thread.h  |  12 +-
> >  linux-user/flatload.c  |   2 +-
> >  MAINTAINERS|   5 +
> >  scripts/coverity-scan/coverity-scan.docker | 131 +++
> >  scripts/coverity-scan/run-coverity-scan| 401 +
> >  6 files changed, 544 insertions(+), 21 deletions(-)
> >  create mode 100644 scripts/coverity-scan/coverity-scan.docker
> >  create mode 100755 scripts/coverity-scan/run-coverity-scan
> >
> > --
> > 2.20.1
>
>


Re: [PATCH v18 0/4] qcow2: Implement zstd cluster compression method

2020-04-13 Thread Denis Plotnikov

Ping! Is there something to be fixed in the series?

Thanks,
Denis

On 02.04.2020 09:36, Denis Plotnikov wrote:

v18:
* 04: add quotes to all file name variables [Vladimir]
* 04: add Vladimir's comment according to "qemu-io write -s"
  option issue.

v17:
* 03: remove incorrect comment in zstd decompress [Vladimir]
* 03: remove "paraniod" and rewrite the comment on decompress [Vladimir]
* 03: fix dead assignment [Vladimir]
* 04: add and remove quotes [Vladimir]
* 04: replace long offset form with the short one [Vladimir]

v16:
* 03: ssize_t for ret, size_t for zstd_ret [Vladimir]
* 04: small fixes according to the comments [Vladimir]

v15:
* 01: aiming qemu 5.1 [Eric]
* 03: change zstd_res definition place [Vladimir]
* 04: add two new test cases [Eric]
  1. test adjacent cluster compression with zstd
  2. test incompressible cluster processing
* 03, 04: many rewording and gramma fixing [Eric]

v14:
* fix bug on compression - looping until compress == 0 [Me]
* apply reworked Vladimir's suggestions:
   1. not mixing ssize_t with size_t
   2. safe check for ENOMEM in compression part - avoid overflow
   3. tolerate sanity check allow zstd to make progress only
  on one of the buffers
v13:
* 03: add progress sanity check to decompression loop [Vladimir]
  03: add successful decompression check [Me]

v12:
* 03: again, rework compression and decompression loops
  to make them more correct [Vladimir]
  03: move assert in compression to more appropriate place
  [Vladimir]
v11:
* 03: the loops don't need "do{}while" form anymore and
  the they were buggy (missed "do" in the beginning)
  replace them with usual "while(){}" loops [Vladimir]
v10:
* 03: fix zstd (de)compressed loops for multi-frame
  cases [Vladimir]
v9:
* 01: fix error checking and reporting in qcow2_amend compression type part 
[Vladimir]
* 03: replace asserts with -EIO in qcow2_zstd_decompression [Vladimir, 
Alberto]
* 03: reword/amend/add comments, fix typos [Vladimir]

v8:
* 03: switch zstd API from simple to stream [Eric]
  No need to state a special cluster layout for zstd
  compressed clusters.
v7:
* use qapi_enum_parse instead of the open-coding [Eric]
* fix wording, typos and spelling [Eric]

v6:
* "block/qcow2-threads: fix qcow2_decompress" is removed from the series
   since it has been accepted by Max already
* add compile time checking for Qcow2Header to be a multiple of 8 [Max, 
Alberto]
* report error on qcow2 amending when the compression type is actually 
chnged [Max]
* remove the extra space and the extra new line [Max]
* re-arrange acks and signed-off-s [Vladimir]

v5:
* replace -ENOTSUP with abort in qcow2_co_decompress [Vladimir]
* set cluster size for all test cases in the beginning of the 287 test

v4:
* the series is rebased on top of 01 "block/qcow2-threads: fix 
qcow2_decompress"
* 01 is just a no-change resend to avoid extra dependencies. Still, it may 
be merged in separate

v3:
* remove redundant max compression type value check [Vladimir, Eric]
  (the switch below checks everything)
* prevent compression type changing on "qemu-img amend" [Vladimir]
* remove zstd config setting, since it has been added already by
  "migration" patches [Vladimir]
* change the compression type error message [Vladimir]
* fix alignment and 80-chars exceeding [Vladimir]

v2:
* rework compression type setting [Vladimir]
* squash iotest changes to the compression type introduction patch 
[Vladimir, Eric]
* fix zstd availability checking in zstd iotest [Vladimir]
* remove unnecessry casting [Eric]
* remove rudundant checks [Eric]
* fix compressed cluster layout in qcow2 spec [Vladimir]
* fix wording [Eric, Vladimir]
* fix compression type filtering in iotests [Eric]

v1:
the initial series



Denis Plotnikov (4):
   qcow2: introduce compression type feature
   qcow2: rework the cluster compression routine
   qcow2: add zstd cluster compression
   iotests: 287: add qcow2 compression type test

  docs/interop/qcow2.txt   |   1 +
  configure|   2 +-
  qapi/block-core.json |  23 +++-
  block/qcow2.h|  20 ++-
  include/block/block_int.h|   1 +
  block/qcow2-threads.c| 228 +--
  block/qcow2.c| 120 
  tests/qemu-iotests/031.out   |  14 +-
  tests/qemu-iotests/036.out   |   4 +-
  tests/qemu-iotests/049.out   | 102 +++---
  tests/qemu-iotests/060.out   |   1 +
  tests/qemu-iotests/061.out   |  34 +++--
  tests/qemu-iotests/065   |  28 ++--
  tests/qemu-iotests/080   |   2 +-
  tests/qemu-iotests/144.out   |   4 +-
  tests/qemu-iotests/182.out   |  

Re: [PATCH v2 0/6] Automation of Coverity Scan uploads (via Docker)

2020-04-13 Thread Peter Maydell
What's your view on this series, Paolo? Personally I'd like
to put it into master, because at least then we have something
that we can do Coverity runs on, whereas AIUI at the moment
we don't. But I'd rather not put it in after rc3, which is
tomorrow...

thanks
-- PMM

On Thu, 19 Mar 2020 at 19:33, Peter Maydell  wrote:
>
> v1 of this series was over a year ago:
> https://patchew.org/QEMU/20181113184641.4492-1-peter.mayd...@linaro.org/
>
> I dusted it off and fixed some stuff because Paolo reports that the
> machine he was previously using for uploads can't run the Coverity
> tools any more.
>
> The first four patches are fixes for problems that cause the Coverity
> tool not to be able to scan everything.  The first one in particular
> meant that every compilation unit failed, which would block uploads.
> The other 3 would reduce the scan coverage but weren't fatal.  (The
> only remaining warnings in the log are where Coverity complains about
> asm intrinsics system headers.)
>
> With these scripts you can do an upload with
> COVERITY_TOKEN=n ./scripts/coverity-scan/run-coverity-scan --docker
> (where  is the project's secret token which admins can
> get from the Coverity web UI).
>
> I did in fact do an upload to test it, so the currently visible
> results on the website are the result of a scan on ce73691e258 plus
> this series.
>
> The new upload has +112 defects, which is quite a lot, but I don't
> think it's so many that it is "defects we rejected as false positives
> coming back again"; my guess is a combination of the fixes in the
> first 4 patches increasing coverage plus we haven't run a test in a
> while plus maybe the script has some more config options enabled that
> Paolo's box did not.  (In the web UI defects that were dismissed as
> FPs seem still to be considered present-but-dismissed, so I think
> that's OK.)
>
> Not much has changed since v1; I didn't get very much feedback
> the first time around[*]. Docker still seems to do the "download
> the Coverity tools" part more often than I expect. On the other
> hand "actually automated with a script in the tree" beats "not
> automated and currently broken" so maybe this patchset as it
> stands is good enough, given that basically 1 or 2 people ever
> will be running the script ?
>
> [*] Eric will note that yes, the script still uses set -e.
>
> (Like v1 this doesn't try to tie it into Travis, but we could
> in theory do that some day, or have some other automated once
> a week run of the script.)
>
> thanks
> -- PMM
>
> Peter Maydell (6):
>   osdep.h: Drop no-longer-needed Coverity workarounds
>   thread.h: Fix Coverity version of qemu_cond_timedwait()
>   thread.h: Remove trailing semicolons from Coverity qemu_mutex_lock()
> etc
>   linux-user/flatload.c: Use "" for include of QEMU header target_flat.h
>   scripts/run-coverity-scan: Script to run Coverity Scan build
>   scripts/coverity-scan: Add Docker support
>
>  include/qemu/osdep.h   |  14 -
>  include/qemu/thread.h  |  12 +-
>  linux-user/flatload.c  |   2 +-
>  MAINTAINERS|   5 +
>  scripts/coverity-scan/coverity-scan.docker | 131 +++
>  scripts/coverity-scan/run-coverity-scan| 401 +
>  6 files changed, 544 insertions(+), 21 deletions(-)
>  create mode 100644 scripts/coverity-scan/coverity-scan.docker
>  create mode 100755 scripts/coverity-scan/run-coverity-scan
>
> --
> 2.20.1



Re: [PULL for-5.0 0/1] tcg patch queue

2020-04-13 Thread Peter Maydell
On Sun, 12 Apr 2020 at 22:11, Richard Henderson
 wrote:
>
> The following changes since commit 17e1e49814096a3daaa8e5a73acd56a0f30bdc18:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2020-04-09 19:00:41 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/rth7680/qemu.git tags/pull-tcg-20200412
>
> for you to fetch changes up to a4e57084c16d5b0eff3651693fba04f26b30b551:
>
>   tcg/mips: mips sync* encode error (2020-04-12 14:07:07 -0700)
>
> 
> Fix tcg/mips barrier encoding
>
> 
> lixinyu (1):
>   tcg/mips: mips sync* encode error
>
>  tcg/mips/tcg-target.inc.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)



Applied, thanks.

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

-- PMM



Re: [RFC patch v1 0/3] qemu-file writing performance improving

2020-04-13 Thread Denis V. Lunev
On 4/13/20 2:12 PM, Denis Plotnikov wrote:
> Problem description: qcow2 internal snapshot saving time is too big on HDD ~ 
> 25 sec
>
> When a qcow2 image is placed on a regular HDD and the image is openned with
> O_DIRECT the snapshot saving time is around 26 sec.
> The snapshot saving time can be 4 times sorter.
> The patch series propose the way to achive that. 
>
> Why is the saving time = ~25 sec?
>
> There are three things:
> 1. qemu-file iov limit (currently 64)
> 2. direct qemu_fflush calls, inducing disk writings
in a non-aligned way, which results further in READ-MODIFY-WRITE
operations at the beginning and at the end of the writing data.
Within synchronous operations this slow-downs the process a lot!

> 3. ram data copying and synchronous disk wrtings
>
> When 1, 2 are quite clear, the 3rd needs some explaination:
>
> Internal snapshot uses qemu-file as an interface to store the data with
> stream semantics.
> qemu-file avoids data coping when possible (mostly for ram data)
> and use iovectors to propagate the data to an undelying block driver state.
> In the case when qcow2 openned with O_DIRECT it is suboptimal.
>
> This is what happens: on writing, when the iovectors query goes from qemu-file
> to bdrv (here and further by brdv I mean qcow2 with posix O_DIRECT openned 
> backend),
> the brdv checks all iovectors to be base and size aligned, if it's not the 
> case,
> the data copied to an internal buffer and synchronous pwrite is called.
> If the iovectors are aligned, io_submit is called.
>
> In our case, snapshot almost always induces pwrite, since we never have all
> the iovectors aligned in the query, because of frequent adding a short 
> iovector:
> 8 byte ram-page delimiters, after adding each ram page iovector.
>
> So the qemu-file code in this case:
> 1. doesn't aviod ram copying
> 2. works fully synchronously
>
> How to improve the snapshot time:
>
> 1. easy way: to increase iov limit to IOV_MAX (1024).
> This will reduce synchronous writing frequency.
> My test revealed that with iov limit = IOV_MAX the snapshot time *~12 sec*.
>
> 2. complex way: do writings asynchronously.
> Introduce both base- and size-aligned buffer, write the data only when
> the buffer is full, write the buffer asynchronously, meanwhile filling another
> buffer with snapshot data.
> My test revealed that this complex way provides the snapshot time *~6 sec*,
> 2 times better than just iov limit increasing.

We also align written data as flush operations over the disk
are not mandatory.

> The patch proposes how to improve the snapshot performance in the complex way,
> allowing to use the asyncronous writings when needed.
>
> This is an RFC series, as I didn't confident that I fully understand all
> qemu-file use cases. I tried to make the series in a safe way to not break
> anything related to qemu-file using in other places, like migration.
>
> All comments are *VERY* appriciated!
>
> Thanks,
> Denis
>
> Denis Plotnikov (3):
>   qemu-file: introduce current buffer
>   qemu-file: add buffered mode
>   migration/savevm: use qemu-file buffered mode for non-cached bdrv
>
>  include/qemu/typedefs.h |   2 +
>  migration/qemu-file.c   | 479 
> +---
>  migration/qemu-file.h   |   9 +
>  migration/savevm.c  |  38 +++-
>  4 files changed, 456 insertions(+), 72 deletions(-)
>




Re: [PATCH 13/15] KVM: MIPS: Add CONFIG6 and DIAG registers emulation

2020-04-13 Thread Jiaxun Yang
On Mon, 13 Apr 2020 15:30:22 +0800
Huacai Chen  wrote:

> Loongson-3 has CONFIG6 and DIAG registers which need to be emulate.
> CONFIG6 is mostly used to enable/disable FTLB and SFB, while DIAG is
> mostly used to flush BTB, ITLB, DTLB, VTLB and FTLB.
> 
> Signed-off-by: Huacai Chen 
> Co-developed-by: Jiaxun Yang 

It should be guarded by CONFIG_CPU_LOONGSON64 as well.

Thanks.

> ---
>  arch/mips/include/asm/kvm_host.h |  5 
>  arch/mips/include/asm/mipsregs.h |  7 +
>  arch/mips/kvm/tlb.c  | 39 +++
>  arch/mips/kvm/vz.c   | 58
> +++- 4 files changed, 108
> insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/include/asm/kvm_host.h
> b/arch/mips/include/asm/kvm_host.h index c291767..3ef6ca8 100644
> --- a/arch/mips/include/asm/kvm_host.h
> +++ b/arch/mips/include/asm/kvm_host.h
> @@ -68,9 +68,11 @@
>  #define KVM_REG_MIPS_CP0_CONFIG3 MIPS_CP0_32(16, 3)
>  #define KVM_REG_MIPS_CP0_CONFIG4 MIPS_CP0_32(16, 4)
>  #define KVM_REG_MIPS_CP0_CONFIG5 MIPS_CP0_32(16, 5)
> +#define KVM_REG_MIPS_CP0_CONFIG6 MIPS_CP0_32(16, 6)
>  #define KVM_REG_MIPS_CP0_CONFIG7 MIPS_CP0_32(16, 7)
>  #define KVM_REG_MIPS_CP0_MAARI   MIPS_CP0_64(17, 2)
>  #define KVM_REG_MIPS_CP0_XCONTEXTMIPS_CP0_64(20, 0)
> +#define KVM_REG_MIPS_CP0_DIAGMIPS_CP0_32(22, 0)
>  #define KVM_REG_MIPS_CP0_ERROREPCMIPS_CP0_64(30, 0)
>  #define KVM_REG_MIPS_CP0_KSCRATCH1   MIPS_CP0_64(31, 2)
>  #define KVM_REG_MIPS_CP0_KSCRATCH2   MIPS_CP0_64(31, 3)
> @@ -256,6 +258,7 @@ struct mips_coproc {
>  #define MIPS_CP0_WATCH_LO18
>  #define MIPS_CP0_WATCH_HI19
>  #define MIPS_CP0_TLB_XCONTEXT20
> +#define MIPS_CP0_DIAG22
>  #define MIPS_CP0_ECC 26
>  #define MIPS_CP0_CACHE_ERR   27
>  #define MIPS_CP0_TAG_LO  28
> @@ -927,6 +930,8 @@ void kvm_vz_save_guesttlb(struct kvm_mips_tlb
> *buf, unsigned int index, unsigned int count);
>  void kvm_vz_load_guesttlb(const struct kvm_mips_tlb *buf, unsigned
> int index, unsigned int count);
> +void kvm_loongson_clear_guest_vtlb(void);
> +void kvm_loongson_clear_guest_ftlb(void);
>  #endif
>  
>  void kvm_mips_suspend_mm(int cpu);
> diff --git a/arch/mips/include/asm/mipsregs.h
> b/arch/mips/include/asm/mipsregs.h index 796fe47..ce40fbf 100644
> --- a/arch/mips/include/asm/mipsregs.h
> +++ b/arch/mips/include/asm/mipsregs.h
> @@ -674,6 +674,9 @@
>  #define MIPS_CONF5_CV(_ULCAST_(1) << 29)
>  #define MIPS_CONF5_K (_ULCAST_(1) << 30)
>  
> +#define MIPS_CONF6_INTIMER   (_ULCAST_(1) << 6)
> +#define MIPS_CONF6_EXTIMER   (_ULCAST_(1) << 7)
> +#define MIPS_CONF6_SFBEN (_ULCAST_(1) << 8)
>  #define MIPS_CONF6_SYND  (_ULCAST_(1) << 13)
>  /* proAptiv FTLB on/off bit */
>  #define MIPS_CONF6_FTLBEN(_ULCAST_(1) << 15)
> @@ -993,6 +996,8 @@
>  /* Disable Branch Return Cache */
>  #define R10K_DIAG_D_BRC  (_ULCAST_(1) << 22)
>  
> +/* Flush BTB */
> +#define LOONGSON_DIAG_BTB(_ULCAST_(1) << 1)
>  /* Flush ITLB */
>  #define LOONGSON_DIAG_ITLB   (_ULCAST_(1) << 2)
>  /* Flush DTLB */
> @@ -2825,7 +2830,9 @@ __BUILD_SET_C0(status)
>  __BUILD_SET_C0(cause)
>  __BUILD_SET_C0(config)
>  __BUILD_SET_C0(config5)
> +__BUILD_SET_C0(config6)
>  __BUILD_SET_C0(config7)
> +__BUILD_SET_C0(diag)
>  __BUILD_SET_C0(intcontrol)
>  __BUILD_SET_C0(intctl)
>  __BUILD_SET_C0(srsmap)
> diff --git a/arch/mips/kvm/tlb.c b/arch/mips/kvm/tlb.c
> index 7cd9216..1efb9a0 100644
> --- a/arch/mips/kvm/tlb.c
> +++ b/arch/mips/kvm/tlb.c
> @@ -20,6 +20,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -622,6 +623,44 @@ void kvm_vz_load_guesttlb(const struct
> kvm_mips_tlb *buf, unsigned int index, }
>  EXPORT_SYMBOL_GPL(kvm_vz_load_guesttlb);
>  
> +void kvm_loongson_clear_guest_vtlb(void)
> +{
> + int idx = read_gc0_index();
> +
> + /* Set root GuestID for root probe and write of guest TLB
> entry */
> + set_root_gid_to_guest_gid();
> +
> + write_gc0_index(0);
> + guest_tlbinvf();
> + write_gc0_index(idx);
> +
> + clear_root_gid();
> + set_c0_diag(LOONGSON_DIAG_ITLB | LOONGSON_DIAG_DTLB);
> +}
> +EXPORT_SYMBOL_GPL(kvm_loongson_clear_guest_vtlb);
> +
> +void kvm_loongson_clear_guest_ftlb(void)
> +{
> + int i;
> + int idx = read_gc0_index();
> +
> + /* Set root GuestID for root probe and write of guest TLB
> entry */
> + set_root_gid_to_guest_gid();
> +
> + for (i = current_cpu_data.tlbsizevtlb;
> +  i < (current_cpu_data.tlbsizevtlb +
> +  current_cpu_data.tlbsizeftlbsets);
> +  i++) {
> + write_gc0_index(i);
> + guest_tlbinvf();
> + }
> + write_gc0_index(idx);
> +
> + clear_root_gid();
> + set_c0_diag(LOONGSON_DIAG_ITLB | LOONGSON_DIAG_DTLB);
> +}
> +EXPORT_SYMBOL_GPL(kvm_loongson_clear_guest_ftlb);
> +
>  #endif
>  
>  /**
> diff --git 

[RFC patch v1 2/3] qemu-file: add buffered mode

2020-04-13 Thread Denis Plotnikov
The patch adds ability to qemu-file to write the data
asynchronously to improve the performance on writing.
Before, only synchronous writing was supported.

Enabling of the asyncronous mode is managed by new
"enabled_buffered" callback.

Signed-off-by: Denis Plotnikov 
---
 include/qemu/typedefs.h |   1 +
 migration/qemu-file.c   | 351 +---
 migration/qemu-file.h   |   9 ++
 3 files changed, 339 insertions(+), 22 deletions(-)

diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 88dce54..9b388c8 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -98,6 +98,7 @@ typedef struct QEMUBH QEMUBH;
 typedef struct QemuConsole QemuConsole;
 typedef struct QEMUFile QEMUFile;
 typedef struct QEMUFileBuffer QEMUFileBuffer;
+typedef struct QEMUFileAioTask QEMUFileAioTask;
 typedef struct QemuLockable QemuLockable;
 typedef struct QemuMutex QemuMutex;
 typedef struct QemuOpt QemuOpt;
diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 285c6ef..f42f949 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -29,19 +29,25 @@
 #include "qemu-file.h"
 #include "trace.h"
 #include "qapi/error.h"
+#include "block/aio_task.h"
 
-#define IO_BUF_SIZE 32768
+#define IO_BUF_SIZE (1024 * 1024)
 #define MAX_IOV_SIZE MIN(IOV_MAX, 64)
+#define IO_BUF_NUM 2
+#define IO_BUF_ALIGNMENT 512
 
-QEMU_BUILD_BUG_ON(!QEMU_IS_ALIGNED(IO_BUF_SIZE, 512));
+QEMU_BUILD_BUG_ON(!QEMU_IS_ALIGNED(IO_BUF_SIZE, IO_BUF_ALIGNMENT));
+QEMU_BUILD_BUG_ON(IO_BUF_SIZE > INT_MAX);
+QEMU_BUILD_BUG_ON(IO_BUF_NUM <= 0);
 
 struct QEMUFileBuffer {
 int buf_index;
-int buf_size; /* 0 when writing */
+int buf_size; /* 0 when non-buffered writing */
 uint8_t *buf;
 unsigned long *may_free;
 struct iovec *iov;
 unsigned int iovcnt;
+QLIST_ENTRY(QEMUFileBuffer) link;
 };
 
 struct QEMUFile {
@@ -60,6 +66,22 @@ struct QEMUFile {
 bool shutdown;
 /* currently used buffer */
 QEMUFileBuffer *current_buf;
+/*
+ * with buffered_mode enabled all the data copied to 512 byte
+ * aligned buffer, including iov data. Then the buffer is passed
+ * to writev_buffer callback.
+ */
+bool buffered_mode;
+/* for async buffer writing */
+AioTaskPool *pool;
+/* the list of free buffers, currently used on is NOT there */
+QLIST_HEAD(, QEMUFileBuffer) free_buffers;
+};
+
+struct QEMUFileAioTask {
+AioTask task;
+QEMUFile *f;
+QEMUFileBuffer *fb;
 };
 
 /*
@@ -115,10 +137,42 @@ QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps 
*ops)
 f->opaque = opaque;
 f->ops = ops;
 
-f->current_buf = g_new0(QEMUFileBuffer, 1);
-f->current_buf->buf = g_malloc(IO_BUF_SIZE);
-f->current_buf->iov = g_new0(struct iovec, MAX_IOV_SIZE);
-f->current_buf->may_free = bitmap_new(MAX_IOV_SIZE);
+if (f->ops->enable_buffered) {
+f->buffered_mode = f->ops->enable_buffered(f->opaque);
+}
+
+if (f->buffered_mode && qemu_file_is_writable(f)) {
+int i;
+/*
+ * in buffered_mode we don't use internal io vectors
+ * and may_free bitmap, because we copy the data to be
+ * written right away to the buffer
+ */
+f->pool = aio_task_pool_new(IO_BUF_NUM);
+
+/* allocate io buffers */
+for (i = 0; i < IO_BUF_NUM; i++) {
+QEMUFileBuffer *fb = g_new0(QEMUFileBuffer, 1);
+
+fb->buf = qemu_memalign(IO_BUF_ALIGNMENT, IO_BUF_SIZE);
+fb->buf_size = IO_BUF_SIZE;
+
+/*
+ * put the first buffer to the current buf and the rest
+ * to the list of free buffers
+ */
+if (i == 0) {
+f->current_buf = fb;
+} else {
+QLIST_INSERT_HEAD(>free_buffers, fb, link);
+}
+}
+} else {
+f->current_buf = g_new0(QEMUFileBuffer, 1);
+f->current_buf->buf = g_malloc(IO_BUF_SIZE);
+f->current_buf->iov = g_new0(struct iovec, MAX_IOV_SIZE);
+f->current_buf->may_free = bitmap_new(MAX_IOV_SIZE);
+}
 
 return f;
 }
@@ -190,6 +244,8 @@ static void qemu_iovec_release_ram(QEMUFile *f)
 unsigned long idx;
 QEMUFileBuffer *fb = f->current_buf;
 
+assert(!f->buffered_mode);
+
 /* Find and release all the contiguous memory ranges marked as may_free. */
 idx = find_next_bit(fb->may_free, fb->iovcnt, 0);
 if (idx >= fb->iovcnt) {
@@ -221,6 +277,147 @@ static void qemu_iovec_release_ram(QEMUFile *f)
 bitmap_zero(fb->may_free, MAX_IOV_SIZE);
 }
 
+static void advance_buf_ptr(QEMUFile *f, size_t size)
+{
+QEMUFileBuffer *fb = f->current_buf;
+/* must not advance to 0 */
+assert(size);
+/* must not overflow buf_index (int) */
+assert(fb->buf_index + size <= INT_MAX);
+/* must not exceed buf_size */
+assert(fb->buf_index + size <= fb->buf_size);
+
+fb->buf_index += size;
+}
+
+static size_t 

[RFC patch v1 1/3] qemu-file: introduce current buffer

2020-04-13 Thread Denis Plotnikov
To approach async wrtiting in the further commits, the buffer
allocated in QEMUFile struct is replaced with the link to the
current buffer. We're going to use many buffers to write the
qemu file stream to the unerlying storage asynchronously. The
current buffer points out to the buffer is currently filled
with data.

This patch doesn't add any features to qemu-file and doesn't
change any qemu-file behavior.

Signed-off-by: Denis Plotnikov 
---
 include/qemu/typedefs.h |   1 +
 migration/qemu-file.c   | 156 +---
 2 files changed, 95 insertions(+), 62 deletions(-)

diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 375770a..88dce54 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -97,6 +97,7 @@ typedef struct QDict QDict;
 typedef struct QEMUBH QEMUBH;
 typedef struct QemuConsole QemuConsole;
 typedef struct QEMUFile QEMUFile;
+typedef struct QEMUFileBuffer QEMUFileBuffer;
 typedef struct QemuLockable QemuLockable;
 typedef struct QemuMutex QemuMutex;
 typedef struct QemuOpt QemuOpt;
diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 1c3a358..285c6ef 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -33,6 +33,17 @@
 #define IO_BUF_SIZE 32768
 #define MAX_IOV_SIZE MIN(IOV_MAX, 64)
 
+QEMU_BUILD_BUG_ON(!QEMU_IS_ALIGNED(IO_BUF_SIZE, 512));
+
+struct QEMUFileBuffer {
+int buf_index;
+int buf_size; /* 0 when writing */
+uint8_t *buf;
+unsigned long *may_free;
+struct iovec *iov;
+unsigned int iovcnt;
+};
+
 struct QEMUFile {
 const QEMUFileOps *ops;
 const QEMUFileHooks *hooks;
@@ -43,18 +54,12 @@ struct QEMUFile {
 
 int64_t pos; /* start of buffer when writing, end of buffer
 when reading */
-int buf_index;
-int buf_size; /* 0 when writing */
-uint8_t buf[IO_BUF_SIZE];
-
-DECLARE_BITMAP(may_free, MAX_IOV_SIZE);
-struct iovec iov[MAX_IOV_SIZE];
-unsigned int iovcnt;
-
 int last_error;
 Error *last_error_obj;
 /* has the file has been shutdown */
 bool shutdown;
+/* currently used buffer */
+QEMUFileBuffer *current_buf;
 };
 
 /*
@@ -109,6 +114,12 @@ QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps 
*ops)
 
 f->opaque = opaque;
 f->ops = ops;
+
+f->current_buf = g_new0(QEMUFileBuffer, 1);
+f->current_buf->buf = g_malloc(IO_BUF_SIZE);
+f->current_buf->iov = g_new0(struct iovec, MAX_IOV_SIZE);
+f->current_buf->may_free = bitmap_new(MAX_IOV_SIZE);
+
 return f;
 }
 
@@ -177,35 +188,37 @@ static void qemu_iovec_release_ram(QEMUFile *f)
 {
 struct iovec iov;
 unsigned long idx;
+QEMUFileBuffer *fb = f->current_buf;
 
 /* Find and release all the contiguous memory ranges marked as may_free. */
-idx = find_next_bit(f->may_free, f->iovcnt, 0);
-if (idx >= f->iovcnt) {
+idx = find_next_bit(fb->may_free, fb->iovcnt, 0);
+if (idx >= fb->iovcnt) {
 return;
 }
-iov = f->iov[idx];
+iov = fb->iov[idx];
 
 /* The madvise() in the loop is called for iov within a continuous range 
and
  * then reinitialize the iov. And in the end, madvise() is called for the
  * last iov.
  */
-while ((idx = find_next_bit(f->may_free, f->iovcnt, idx + 1)) < f->iovcnt) 
{
+while ((idx = find_next_bit(fb->may_free,
+fb->iovcnt, idx + 1)) < fb->iovcnt) {
 /* check for adjacent buffer and coalesce them */
-if (iov.iov_base + iov.iov_len == f->iov[idx].iov_base) {
-iov.iov_len += f->iov[idx].iov_len;
+if (iov.iov_base + iov.iov_len == fb->iov[idx].iov_base) {
+iov.iov_len += fb->iov[idx].iov_len;
 continue;
 }
 if (qemu_madvise(iov.iov_base, iov.iov_len, QEMU_MADV_DONTNEED) < 0) {
 error_report("migrate: madvise DONTNEED failed %p %zd: %s",
  iov.iov_base, iov.iov_len, strerror(errno));
 }
-iov = f->iov[idx];
+iov = fb->iov[idx];
 }
 if (qemu_madvise(iov.iov_base, iov.iov_len, QEMU_MADV_DONTNEED) < 0) {
 error_report("migrate: madvise DONTNEED failed %p %zd: %s",
  iov.iov_base, iov.iov_len, strerror(errno));
 }
-memset(f->may_free, 0, sizeof(f->may_free));
+bitmap_zero(fb->may_free, MAX_IOV_SIZE);
 }
 
 /**
@@ -219,6 +232,7 @@ void qemu_fflush(QEMUFile *f)
 ssize_t ret = 0;
 ssize_t expect = 0;
 Error *local_error = NULL;
+QEMUFileBuffer *fb = f->current_buf;
 
 if (!qemu_file_is_writable(f)) {
 return;
@@ -227,9 +241,9 @@ void qemu_fflush(QEMUFile *f)
 if (f->shutdown) {
 return;
 }
-if (f->iovcnt > 0) {
-expect = iov_size(f->iov, f->iovcnt);
-ret = f->ops->writev_buffer(f->opaque, f->iov, f->iovcnt, f->pos,
+if (fb->iovcnt > 0) {
+expect = iov_size(fb->iov, fb->iovcnt);
+ret = f->ops->writev_buffer(f->opaque, fb->iov, 

[RFC patch v1 3/3] migration/savevm: use qemu-file buffered mode for non-cached bdrv

2020-04-13 Thread Denis Plotnikov
This makes internal snapshots of HDD placed qcow2 images opened with
O_DIRECT flag 4 times faster.

The test:
   creates 500M internal snapshot for a cow2 image placed on HDD
Result times:
   with the patch: ~6 sec
   without patch: ~24 sec

This happens because the internal snapshot saving produces a lot of
pwrites, because of flushing the internal buffers with non-aligned
io vectors and direct calling qemu_fflush.

To fix it, we introduce an internal pointer and size aligned buffer.
The most of the time the buffer is flushed only when it's full regardless
of direct calling qemu_fflush. When the buffer is full, it is written
asynchronously.

This gives us a cople of advantages leading to performance improvement:

1. beacause of pointer and size aligned buffers we can use asynchronous
   os write syscall, like io_submit
2. when some buffer is being written, another buffer is filled with
   data.

Signed-off-by: Denis Plotnikov 
---
 migration/savevm.c | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index c00a680..db0cac9 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -63,6 +63,7 @@
 #include "migration/colo.h"
 #include "qemu/bitmap.h"
 #include "net/announce.h"
+#include "block/block_int.h"
 
 const unsigned int postcopy_ram_discard_version = 0;
 
@@ -153,6 +154,12 @@ static int bdrv_fclose(void *opaque, Error **errp)
 return bdrv_flush(opaque);
 }
 
+static bool qemu_file_is_buffered(void *opaque)
+{
+BlockDriverState *bs = (BlockDriverState *) opaque;
+return !!(bs->open_flags & BDRV_O_NOCACHE);
+}
+
 static const QEMUFileOps bdrv_read_ops = {
 .get_buffer = block_get_buffer,
 .close =  bdrv_fclose
@@ -160,7 +167,8 @@ static const QEMUFileOps bdrv_read_ops = {
 
 static const QEMUFileOps bdrv_write_ops = {
 .writev_buffer  = block_writev_buffer,
-.close  = bdrv_fclose
+.close  = bdrv_fclose,
+.enable_buffered = qemu_file_is_buffered
 };
 
 static QEMUFile *qemu_fopen_bdrv(BlockDriverState *bs, int is_writable)
@@ -2624,7 +2632,7 @@ int qemu_load_device_state(QEMUFile *f)
 return 0;
 }
 
-int save_snapshot(const char *name, Error **errp)
+static int coroutine_fn save_snapshot_fn(const char *name, Error **errp)
 {
 BlockDriverState *bs, *bs1;
 QEMUSnapshotInfo sn1, *sn = , old_sn1, *old_sn = _sn1;
@@ -2747,6 +2755,32 @@ int save_snapshot(const char *name, Error **errp)
 return ret;
 }
 
+ typedef struct SaveVMParams {
+ const char *name;
+ Error **errp;
+ int ret;
+ } SaveVMParams;
+
+static void coroutine_fn save_snapshot_entry(void *opaque)
+{
+SaveVMParams *p = (SaveVMParams *) opaque;
+p->ret = save_snapshot_fn(p->name, p->errp);
+}
+
+int save_snapshot(const char *name, Error **errp)
+{
+SaveVMParams p = (SaveVMParams) {
+.name = name,
+.errp = errp,
+.ret = -EINPROGRESS,
+};
+
+Coroutine *co = qemu_coroutine_create(save_snapshot_entry, );
+aio_co_enter(qemu_get_aio_context(), co);
+AIO_WAIT_WHILE(qemu_get_aio_context(), p.ret == -EINPROGRESS);
+return p.ret;
+}
+
 void qmp_xen_save_devices_state(const char *filename, bool has_live, bool live,
 Error **errp)
 {
-- 
1.8.3.1




[RFC patch v1 0/3] qemu-file writing performance improving

2020-04-13 Thread Denis Plotnikov
Problem description: qcow2 internal snapshot saving time is too big on HDD ~ 25 
sec

When a qcow2 image is placed on a regular HDD and the image is openned with
O_DIRECT the snapshot saving time is around 26 sec.
The snapshot saving time can be 4 times sorter.
The patch series propose the way to achive that. 

Why is the saving time = ~25 sec?

There are three things:
1. qemu-file iov limit (currently 64)
2. direct qemu_fflush calls, inducing disk writings
3. ram data copying and synchronous disk wrtings

When 1, 2 are quite clear, the 3rd needs some explaination:

Internal snapshot uses qemu-file as an interface to store the data with
stream semantics.
qemu-file avoids data coping when possible (mostly for ram data)
and use iovectors to propagate the data to an undelying block driver state.
In the case when qcow2 openned with O_DIRECT it is suboptimal.

This is what happens: on writing, when the iovectors query goes from qemu-file
to bdrv (here and further by brdv I mean qcow2 with posix O_DIRECT openned 
backend),
the brdv checks all iovectors to be base and size aligned, if it's not the case,
the data copied to an internal buffer and synchronous pwrite is called.
If the iovectors are aligned, io_submit is called.

In our case, snapshot almost always induces pwrite, since we never have all
the iovectors aligned in the query, because of frequent adding a short iovector:
8 byte ram-page delimiters, after adding each ram page iovector.

So the qemu-file code in this case:
1. doesn't aviod ram copying
2. works fully synchronously

How to improve the snapshot time:

1. easy way: to increase iov limit to IOV_MAX (1024).
This will reduce synchronous writing frequency.
My test revealed that with iov limit = IOV_MAX the snapshot time *~12 sec*.

2. complex way: do writings asynchronously.
Introduce both base- and size-aligned buffer, write the data only when
the buffer is full, write the buffer asynchronously, meanwhile filling another
buffer with snapshot data.
My test revealed that this complex way provides the snapshot time *~6 sec*,
2 times better than just iov limit increasing.

The patch proposes how to improve the snapshot performance in the complex way,
allowing to use the asyncronous writings when needed.

This is an RFC series, as I didn't confident that I fully understand all
qemu-file use cases. I tried to make the series in a safe way to not break
anything related to qemu-file using in other places, like migration.

All comments are *VERY* appriciated!

Thanks,
Denis

Denis Plotnikov (3):
  qemu-file: introduce current buffer
  qemu-file: add buffered mode
  migration/savevm: use qemu-file buffered mode for non-cached bdrv

 include/qemu/typedefs.h |   2 +
 migration/qemu-file.c   | 479 +---
 migration/qemu-file.h   |   9 +
 migration/savevm.c  |  38 +++-
 4 files changed, 456 insertions(+), 72 deletions(-)

-- 
1.8.3.1




[PULL 4/4] exec: Fix for qemu_ram_resize() callback

2020-04-13 Thread Michael S. Tsirkin
From: David Hildenbrand 

Summarizing the issue:
1. Memory regions contain ram blocks with a different size,  if the
   size is  not properly aligned. While memory regions can have an
   unaligned size, ram blocks can't. This is true when creating
   resizable memory region with  an unaligned size.
2. When resizing a ram block/memory region, the size of the memory
   region  is set to the aligned size. The callback is called with
   the aligned size. The unaligned piece is lost.

Because of the above, if ACPI blob length modifications happens
after the initial virt_acpi_build() call, and the changed blob
length is within the PAGE size boundary, then the revised size
is not seen by the firmware on Guest reboot.

Hence make sure callback is called if memory region size is changed,
irrespective of aligned or not.

Signed-off-by: David Hildenbrand 
[Shameer: added commit log]
Signed-off-by: Shameer Kolothum 
Reviewed-by: Igor Mammedov 
Message-Id: <20200403101827.30664-4-shameerali.kolothum.th...@huawei.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Philippe Mathieu-Daudé 
---
 exec.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index de9d949902..2874bb5088 100644
--- a/exec.c
+++ b/exec.c
@@ -2074,11 +2074,23 @@ static int memory_try_enable_merging(void *addr, size_t 
len)
  */
 int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
 {
+const ram_addr_t unaligned_size = newsize;
+
 assert(block);
 
 newsize = HOST_PAGE_ALIGN(newsize);
 
 if (block->used_length == newsize) {
+/*
+ * We don't have to resize the ram block (which only knows aligned
+ * sizes), however, we have to notify if the unaligned size changed.
+ */
+if (unaligned_size != memory_region_size(block->mr)) {
+memory_region_set_size(block->mr, unaligned_size);
+if (block->resized) {
+block->resized(block->idstr, unaligned_size, block->host);
+}
+}
 return 0;
 }
 
@@ -2102,9 +2114,9 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, 
Error **errp)
 block->used_length = newsize;
 cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
 DIRTY_CLIENTS_ALL);
-memory_region_set_size(block->mr, newsize);
+memory_region_set_size(block->mr, unaligned_size);
 if (block->resized) {
-block->resized(block->idstr, newsize, block->host);
+block->resized(block->idstr, unaligned_size, block->host);
 }
 return 0;
 }
-- 
MST




[PULL 3/4] fw_cfg: Migrate ACPI table mr sizes separately

2020-04-13 Thread Michael S. Tsirkin
From: Shameer Kolothum 

Any sub-page size update to ACPI MRs will be lost during
migration, as we use aligned size in ram_load_precopy() ->
qemu_ram_resize() path. This will result in inconsistency in
FWCfgEntry sizes between source and destination. In order to avoid
this, save and restore them separately during migration.

Up until now, this problem may not be that relevant for x86 as both
ACPI table and Linker MRs gets padded and aligned. Also at present,
qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
unaligned size changes. But since we are going to fix the
qemu_ram_resize() in the subsequent patch, the issue may become
more serious especially for RSDP MR case.

Moreover, the issue will soon become prominent in arm/virt as well
where the MRs are not padded or aligned at all and eventually have
acpi table changes as part of future additions like NVDIMM hot-add
feature.

Suggested-by: David Hildenbrand 
Signed-off-by: Shameer Kolothum 
Acked-by: David Hildenbrand 
Message-Id: <20200403101827.30664-3-shameerali.kolothum.th...@huawei.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/nvram/fw_cfg.h |  6 +++
 hw/core/machine.c |  1 +
 hw/nvram/fw_cfg.c | 91 ++-
 3 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index b5291eefad..25d9307018 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -53,6 +53,12 @@ struct FWCfgState {
 dma_addr_t dma_addr;
 AddressSpace *dma_as;
 MemoryRegion dma_iomem;
+
+/* restore during migration */
+bool acpi_mr_restore;
+uint64_t table_mr_size;
+uint64_t linker_mr_size;
+uint64_t rsdp_mr_size;
 };
 
 struct FWCfgIoState {
diff --git a/hw/core/machine.c b/hw/core/machine.c
index de0c425605..c1a444cb75 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
 { "usb-redir", "suppress-remote-wake", "off" },
 { "qxl", "revision", "4" },
 { "qxl-vga", "revision", "4" },
+{ "fw_cfg", "acpi-mr-restore", "false" },
 };
 const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
 
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 179b302f01..4be6c9d9fd 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -39,6 +39,7 @@
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "hw/acpi/aml-build.h"
 
 #define FW_CFG_FILE_SLOTS_DFLT 0x20
 
@@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
 return s->dma_enabled;
 }
 
+static bool fw_cfg_acpi_mr_restore(void *opaque)
+{
+FWCfgState *s = opaque;
+bool mr_aligned;
+
+mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
+ QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) 
&&
+ QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
+return s->acpi_mr_restore && !mr_aligned;
+}
+
+static void fw_cfg_update_mr(FWCfgState *s, uint16_t key, size_t size)
+{
+MemoryRegion *mr;
+ram_addr_t offset;
+int arch = !!(key & FW_CFG_ARCH_LOCAL);
+void *ptr;
+
+key &= FW_CFG_ENTRY_MASK;
+assert(key < fw_cfg_max_entry(s));
+
+ptr = s->entries[arch][key].data;
+mr = memory_region_from_host(ptr, );
+
+memory_region_ram_resize(mr, size, _abort);
+}
+
+static int fw_cfg_acpi_mr_restore_post_load(void *opaque, int version_id)
+{
+FWCfgState *s = opaque;
+int i, index;
+
+assert(s->files);
+
+index = be32_to_cpu(s->files->count);
+
+for (i = 0; i < index; i++) {
+if (!strcmp(s->files->f[i].name, ACPI_BUILD_TABLE_FILE)) {
+fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->table_mr_size);
+} else if (!strcmp(s->files->f[i].name, ACPI_BUILD_LOADER_FILE)) {
+fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->linker_mr_size);
+} else if (!strcmp(s->files->f[i].name, ACPI_BUILD_RSDP_FILE)) {
+fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->rsdp_mr_size);
+}
+}
+
+return 0;
+}
+
 static const VMStateDescription vmstate_fw_cfg_dma = {
 .name = "fw_cfg/dma",
 .needed = fw_cfg_dma_enabled,
@@ -619,6 +669,20 @@ static const VMStateDescription vmstate_fw_cfg_dma = {
 },
 };
 
+static const VMStateDescription vmstate_fw_cfg_acpi_mr = {
+.name = "fw_cfg/acpi_mr",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = fw_cfg_acpi_mr_restore,
+.post_load = fw_cfg_acpi_mr_restore_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(table_mr_size, FWCfgState),
+VMSTATE_UINT64(linker_mr_size, FWCfgState),
+VMSTATE_UINT64(rsdp_mr_size, FWCfgState),
+VMSTATE_END_OF_LIST()
+},
+};
+
 static const VMStateDescription vmstate_fw_cfg = {
 .name = "fw_cfg",
 .version_id = 2,
@@ -631,6 +695,7 @@ static const VMStateDescription vmstate_fw_cfg = {
 

[PULL 2/4] acpi: Use macro for table-loader file name

2020-04-13 Thread Michael S. Tsirkin
From: Shameer Kolothum 

Use macro for "etc/table-loader" and move it to the header
file similar to ACPI_BUILD_TABLE_FILE/ACPI_BUILD_RSDP_FILE etc.

Signed-off-by: Shameer Kolothum 
Reviewed-by: Igor Mammedov 
Message-Id: <20200403101827.30664-2-shameerali.kolothum.th...@huawei.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/acpi/aml-build.h | 1 +
 hw/arm/virt-acpi-build.c| 2 +-
 hw/i386/acpi-build.c| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index de4a406568..0f4ed53d7f 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -13,6 +13,7 @@
 #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
 #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
 #define ACPI_BUILD_TPMLOG_FILE "etc/tpm/log"
+#define ACPI_BUILD_LOADER_FILE "etc/table-loader"
 
 #define AML_NOTIFY_METHOD "NTFY"
 
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 7ef0733d71..81d41a3990 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -929,7 +929,7 @@ void virt_acpi_setup(VirtMachineState *vms)
 
 build_state->linker_mr =
 acpi_add_rom_blob(virt_acpi_build_update, build_state,
-  tables.linker->cmd_blob, "etc/table-loader", 0);
+  tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
 
 fw_cfg_add_file(vms->fw_cfg, ACPI_BUILD_TPMLOG_FILE, tables.tcpalog->data,
 acpi_data_len(tables.tcpalog));
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 2a7e55bae7..23c77eeb95 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -3043,7 +3043,7 @@ void acpi_setup(void)
 
 build_state->linker_mr =
 acpi_add_rom_blob(acpi_build_update, build_state,
-  tables.linker->cmd_blob, "etc/table-loader", 0);
+  tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
 
 fw_cfg_add_file(x86ms->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
 tables.tcpalog->data, acpi_data_len(tables.tcpalog));
-- 
MST




[PULL 1/4] MAINTAINERS: Add myself as vhost-user-blk maintainer

2020-04-13 Thread Michael S. Tsirkin
From: Raphael Norwitz 

As suggested by Michael, let's add me as a maintainer of
vhost-user-blk and vhost-user-scsi.

CC: Michael S. Tsirkin 
CC Peter Maydell 
Signed-off-by: Raphael Norwitz 
Message-Id: <1585213047-20089-1-git-send-email-raphael.norw...@nutanix.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 642c8e0b6b..5f93e8c01d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1853,6 +1853,18 @@ F: hw/display/virtio-gpu*
 F: hw/display/virtio-vga.*
 F: include/hw/virtio/virtio-gpu.h
 
+vhost-user-blk
+M: Raphael Norwitz 
+S: Maintained
+F: contrib/vhost-user-blk/
+F: contrib/vhost-user-scsi/
+F: hw/block/vhost-user-blk.c
+F: hw/scsi/vhost-user-scsi.c
+F: hw/virtio/vhost-user-blk-pci.c
+F: hw/virtio/vhost-user-scsi-pci.c
+F: include/hw/virtio/vhost-user-blk.h
+F: include/hw/virtio/vhost-user-scsi.h
+
 vhost-user-gpu
 M: Marc-André Lureau 
 M: Gerd Hoffmann 
-- 
MST




[PULL 0/4] pc: bugfixes, maintainers

2020-04-13 Thread Michael S. Tsirkin
The following changes since commit f3bac27cc1e303e1860cc55b9b6889ba39dee587:

  Update version for v5.0.0-rc2 release (2020-04-07 23:13:37 +0100)

are available in the Git repository at:

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

for you to fetch changes up to ce4adc0b6e6167091373389ef8befd379c61fddb:

  exec: Fix for qemu_ram_resize() callback (2020-04-13 06:55:54 -0400)


pc: bugfixes, maintainers

A couple of bugfixes.
Add a new vhost-user-blk maintainer.

Signed-off-by: Michael S. Tsirkin 


David Hildenbrand (1):
  exec: Fix for qemu_ram_resize() callback

Raphael Norwitz (1):
  MAINTAINERS: Add myself as vhost-user-blk maintainer

Shameer Kolothum (2):
  acpi: Use macro for table-loader file name
  fw_cfg: Migrate ACPI table mr sizes separately

 include/hw/acpi/aml-build.h |  1 +
 include/hw/nvram/fw_cfg.h   |  6 +++
 exec.c  | 16 +++-
 hw/arm/virt-acpi-build.c|  2 +-
 hw/core/machine.c   |  1 +
 hw/i386/acpi-build.c|  2 +-
 hw/nvram/fw_cfg.c   | 91 -
 MAINTAINERS | 12 ++
 8 files changed, 126 insertions(+), 5 deletions(-)




Re: [PATCH v2] gdbstub: Fix segment fault for i386 target

2020-04-13 Thread Laurent Vivier
Le 13/04/2020 à 01:32, Changbin Du a écrit :
> With GByteArray, we should pass the object itself but not to plus an offset.
> 
> gdb log:
> Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> __memmove_avx_unaligned_erms () at 
> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384
> 384   ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file 
> or directory.
> 
> Fixes: a010bdbe71 ("gdbstub: extend GByteArray to read register helpers")
> Signed-off-by: Changbin Du 
> 
> ---
> v2: remove m68k fix since it's already queued.
> ---
>  target/i386/gdbstub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
> index f3d23b614e..b98a99500a 100644
> --- a/target/i386/gdbstub.c
> +++ b/target/i386/gdbstub.c
> @@ -106,7 +106,7 @@ int x86_cpu_gdb_read_register(CPUState *cs, GByteArray 
> *mem_buf, int n)
>  } else if (n >= IDX_FP_REGS && n < IDX_FP_REGS + 8) {
>  floatx80 *fp = (floatx80 *) >fpregs[n - IDX_FP_REGS];
>  int len = gdb_get_reg64(mem_buf, cpu_to_le64(fp->low));
> -len += gdb_get_reg16(mem_buf + len, cpu_to_le16(fp->high));
> +len += gdb_get_reg16(mem_buf, cpu_to_le16(fp->high));
>  return len;
>  } else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
>  n -= IDX_XMM_REGS;
> 

Reviewed-by: Laurent Vivier 



Re: [PATCH v4 10/30] qcow2: Add offset_to_sc_index()

2020-04-13 Thread Vladimir Sementsov-Ogievskiy

17.03.2020 21:16, Alberto Garcia wrote:

For a given offset, return the subcluster number within its cluster
(i.e. with 32 subclusters per cluster it returns a number between 0
and 31).

Signed-off-by: Alberto Garcia
Reviewed-by: Max Reitz


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir



Re: [PATCH-for-5.0 0/3] virtio, vhost-gpu: Release memory returned by malloc() with free()

2020-04-13 Thread Michael S. Tsirkin
On Mon, Mar 23, 2020 at 09:41:20AM -0400, Michael S. Tsirkin wrote:
> On Mon, Mar 23, 2020 at 12:29:40PM +0100, Philippe Mathieu-Daudé wrote:
> > Coverity reported a ALLOC_FREE_MISMATCH in vg_handle_cursor(),
> > because the memory returned by vu_queue_pop() is allocated with
> > malloc(). Fix it.
> > 
> > Similar error occurs with virtio. Document and fix.
> 
> I will queue this. Thanks!

So what are we doing with this patchset? Marc-André reported issues -
any plan to fix them up? Split up the patchset to 3 independent
patches?

> > Philippe Mathieu-Daudé (3):
> >   vhost-user-gpu: Release memory returned by vu_queue_pop() with free()
> >   virtio: Document virtqueue_pop()
> >   virtio-gpu: Release memory returned by virtqueue_pop() with free()
> > 
> >  include/hw/virtio/virtio.h  | 8 
> >  contrib/vhost-user-gpu/vhost-user-gpu.c | 4 ++--
> >  contrib/vhost-user-gpu/virgl.c  | 2 +-
> >  hw/display/virtio-gpu-3d.c  | 2 +-
> >  hw/display/virtio-gpu.c | 8 
> >  5 files changed, 16 insertions(+), 8 deletions(-)
> > 
> > -- 
> > 2.21.1




Re: [PATCH] hw/pci/pcie: Forbid hot-plug via QMP if it's disabled on the slot

2020-04-13 Thread Michael S. Tsirkin
On Wed, Apr 08, 2020 at 12:51:20PM +0200, Igor Mammedov wrote:
> On Tue,  7 Apr 2020 16:50:17 +0200
> Julia Suvorova  wrote:
> 
> > Raise an error when trying to hot-plug/unplug a device through QMP to a 
> > device
> > with disabled hot-plug capability. This makes the device behaviour more
> > consistent and provides an explanation of the failure in the case of
> > asynchronous unplug.
> 
> it applies to hotplug in general (i.e. not only QMP)
> 
> > 
> > Signed-off-by: Julia Suvorova 
> > ---
> >  hw/pci/pcie.c | 24 +---
> >  1 file changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > index 0eb3a2a5d2..e9798caa8a 100644
> > --- a/hw/pci/pcie.c
> > +++ b/hw/pci/pcie.c
> > @@ -415,6 +415,7 @@ void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, 
> > DeviceState *dev,
> >  {
> >  PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev);
> >  uint8_t *exp_cap = hotplug_pdev->config + hotplug_pdev->exp.exp_cap;
> > +uint32_t sltcap = pci_get_word(exp_cap + PCI_EXP_SLTCAP);
> >  PCIDevice *pci_dev = PCI_DEVICE(dev);
> >  
> >  /* Don't send event when device is enabled during qemu machine 
> > creation:
> > @@ -430,6 +431,13 @@ void pcie_cap_slot_plug_cb(HotplugHandler 
> > *hotplug_dev, DeviceState *dev,
> >  return;
> >  }
> >  
> > +/* Hot-plug is disabled on the slot */
> > +if ((sltcap & PCI_EXP_SLTCAP_HPC) == 0) {
> > +error_setg(errp, "Device '%s' does not support hot-plug",
> > + DEVICE(hotplug_dev)->id);
> plug and unplug_req are synchronous. so one can skip on "Device '%s'",
> user will get this error message as response to device_add/del command.
> 
> and more exactly it's concrete slot that does not support hotplug, how about
> "slot doesn't support ..." or just "hotlpug is not supported"

Well device name is useful here, while these commands are synchronous
others aren't so log parsing might not be synchronous.

I do think we should mention slot since that's the reason
hotplug failed:
"Device '%s' hot-plug failed: unsupported by slot"

> > +return;
> > +}
> > +
> >  /* To enable multifunction hot-plug, we just ensure the function
> >   * 0 added last. When function 0 is added, we set the sltsta and
> >   * inform OS via event notification.
> > @@ -464,14 +472,24 @@ static void pcie_unplug_device(PCIBus *bus, PCIDevice 
> > *dev, void *opaque)
> >  object_unparent(OBJECT(dev));
> >  }
> >  
> > -void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev,
> > +void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_handler,
> >   DeviceState *dev, Error **errp)
> >  {
> >  Error *local_err = NULL;
> >  PCIDevice *pci_dev = PCI_DEVICE(dev);
> >  PCIBus *bus = pci_get_bus(pci_dev);
> > +PCIDevice *hotplug_dev = PCI_DEVICE(hotplug_handler);
> > +uint8_t *exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
> > +uint32_t sltcap = pci_get_word(exp_cap + PCI_EXP_SLTCAP);
> > +
> > +/* Hot-unplug is disabled on the slot */
> > +if ((sltcap & PCI_EXP_SLTCAP_HPC) == 0) {
> > +error_setg(errp, "Device '%s' does not support hot-unplug",
> > + DEVICE(hotplug_dev)->id);
> > +return;

Here too let's mention slot since that's the reason
hotplug failed:
"Device '%s' hot-unplug failed: unsupported by slot"

?

> > +}
> >  
> > -pcie_cap_slot_plug_common(PCI_DEVICE(hotplug_dev), dev, _err);
> > +pcie_cap_slot_plug_common(hotplug_dev, dev, _err);
> >  if (local_err) {
> >  error_propagate(errp, local_err);
> >  return;
> > @@ -490,7 +508,7 @@ void pcie_cap_slot_unplug_request_cb(HotplugHandler 
> > *hotplug_dev,
> >  return;
> >  }
> >  
> > -pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
> > +pcie_cap_slot_push_attention_button(hotplug_dev);
> >  }
> >  
> >  /* pci express slot for pci express root/downstream port




[PATCH v3] migration/throttle: Add cpu-throttle-tailslow migration parameter

2020-04-13 Thread Keqian Zhu
At the tail stage of throttling, the Guest is very sensitive to
CPU percentage while the @cpu-throttle-increment is excessive
usually at tail stage.

If this parameter is true, we will compute the ideal CPU percentage
used by the Guest, which may exactly make the dirty rate match the
dirty rate threshold. Then we will choose a smaller throttle increment
between the one specified by @cpu-throttle-increment and the one
generated by ideal CPU percentage.

Therefore, it is compatible to traditional throttling, meanwhile
the throttle increment won't be excessive at tail stage. This may
make migration time longer, and is disabled by default.

Signed-off-by: Keqian Zhu 
---
Cc: Juan Quintela 
Cc: "Dr. David Alan Gilbert" 
Cc: Eric Blake 
Cc: Markus Armbruster 
---
 migration/migration.c | 13 
 migration/ram.c   | 25 +-
 monitor/hmp-cmds.c|  8 
 qapi/migration.json   | 48 +++
 4 files changed, 89 insertions(+), 5 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 187ac0410c..d478a87290 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -785,6 +785,8 @@ MigrationParameters *qmp_query_migrate_parameters(Error 
**errp)
 params->cpu_throttle_initial = s->parameters.cpu_throttle_initial;
 params->has_cpu_throttle_increment = true;
 params->cpu_throttle_increment = s->parameters.cpu_throttle_increment;
+params->has_cpu_throttle_tailslow = true;
+params->cpu_throttle_tailslow = s->parameters.cpu_throttle_tailslow;
 params->has_tls_creds = true;
 params->tls_creds = g_strdup(s->parameters.tls_creds);
 params->has_tls_hostname = true;
@@ -1324,6 +1326,10 @@ static void 
migrate_params_test_apply(MigrateSetParameters *params,
 dest->cpu_throttle_increment = params->cpu_throttle_increment;
 }
 
+if (params->has_cpu_throttle_tailslow) {
+dest->cpu_throttle_tailslow = params->cpu_throttle_tailslow;
+}
+
 if (params->has_tls_creds) {
 assert(params->tls_creds->type == QTYPE_QSTRING);
 dest->tls_creds = g_strdup(params->tls_creds->u.s);
@@ -1412,6 +1418,10 @@ static void migrate_params_apply(MigrateSetParameters 
*params, Error **errp)
 s->parameters.cpu_throttle_increment = params->cpu_throttle_increment;
 }
 
+if (params->has_cpu_throttle_tailslow) {
+s->parameters.cpu_throttle_tailslow = params->cpu_throttle_tailslow;
+}
+
 if (params->has_tls_creds) {
 g_free(s->parameters.tls_creds);
 assert(params->tls_creds->type == QTYPE_QSTRING);
@@ -3594,6 +3604,8 @@ static Property migration_properties[] = {
 DEFINE_PROP_UINT8("x-cpu-throttle-increment", MigrationState,
   parameters.cpu_throttle_increment,
   DEFAULT_MIGRATE_CPU_THROTTLE_INCREMENT),
+DEFINE_PROP_BOOL("x-cpu-throttle-tailslow", MigrationState,
+  parameters.cpu_throttle_tailslow, false),
 DEFINE_PROP_SIZE("x-max-bandwidth", MigrationState,
   parameters.max_bandwidth, MAX_THROTTLE),
 DEFINE_PROP_UINT64("x-downtime-limit", MigrationState,
@@ -3700,6 +3712,7 @@ static void migration_instance_init(Object *obj)
 params->has_throttle_trigger_threshold = true;
 params->has_cpu_throttle_initial = true;
 params->has_cpu_throttle_increment = true;
+params->has_cpu_throttle_tailslow = true;
 params->has_max_bandwidth = true;
 params->has_downtime_limit = true;
 params->has_x_checkpoint_delay = true;
diff --git a/migration/ram.c b/migration/ram.c
index 04f13feb2e..3317c99786 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -616,20 +616,34 @@ static size_t save_page_header(RAMState *rs, QEMUFile *f, 
 RAMBlock *block,
  * able to complete migration. Some workloads dirty memory way too
  * fast and will not effectively converge, even with auto-converge.
  */
-static void mig_throttle_guest_down(void)
+static void mig_throttle_guest_down(uint64_t bytes_dirty_period,
+uint64_t bytes_dirty_threshold)
 {
 MigrationState *s = migrate_get_current();
 uint64_t pct_initial = s->parameters.cpu_throttle_initial;
-uint64_t pct_icrement = s->parameters.cpu_throttle_increment;
+uint64_t pct_increment = s->parameters.cpu_throttle_increment;
+bool pct_tailslow = s->parameters.cpu_throttle_tailslow;
 int pct_max = s->parameters.max_cpu_throttle;
 
+uint64_t throttle_now = cpu_throttle_get_percentage();
+uint64_t cpu_now, cpu_ideal, throttle_inc;
+
 /* We have not started throttling yet. Let's start it. */
 if (!cpu_throttle_active()) {
 cpu_throttle_set(pct_initial);
 } else {
 /* Throttling already on, just increase the rate */
-cpu_throttle_set(MIN(cpu_throttle_get_percentage() + pct_icrement,
- pct_max));
+if (!pct_tailslow) {
+throttle_inc = pct_increment;
+

Re: [PATCH 0/7] hw/sparc/leon3: Few fixes and disable HelenOS test

2020-04-13 Thread KONRAD Frederic




Le 4/11/20 à 7:30 PM, Philippe Mathieu-Daudé a écrit :

On 3/31/20 12:50 PM, Philippe Mathieu-Daudé wrote:

Philippe Mathieu-Daudé (7):
   hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to AHB PnP
 registers
   hw/misc/grlib_ahb_apb_pnp: Fix AHB PnP 8-bit accesses


Ping ^^^ for 5.0?


Hi Philippe,

You already have my rb tag for those one, and IMHO they should be good candidate
for 5.0 (if it's not too late).

Cheers,
Fred




   hw/misc/grlib_ahb_apb_pnp: Add trace events on read accesses
   hw/timer/grlib_gptimer: Display frequency in decimal
   target/sparc/int32_helper: Remove DEBUG_PCALL definition
   target/sparc/int32_helper: Extract and use excp_name_str()

  hw/misc/grlib_ahb_apb_pnp.c | 24 ++--
  target/sparc/int32_helper.c | 23 ---
  hw/misc/trace-events|  4 
  hw/timer/trace-events   |  2 +-
  tests/acceptance/machine_sparc_leon3.py |  4 
  5 files changed, 43 insertions(+), 14 deletions(-)





Re: [PATCH v2] lockable: Replace locks with lock guard macros

2020-04-13 Thread Yuval Shaia
On Thu, 2 Apr 2020 at 09:50, Simran Singhal 
wrote:

> Replace manual lock()/unlock() calls with lock guard macros
> (QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD).
>
> Signed-off-by: Simran Singhal 
> ---
> Changes in v2:
> -Drop changes in file hw/rdma/rdma_utils.c
>

So i guess we are expected to see this back soon, right?

Ignore my r-b and t-b for v1, i did not encounter the build errors, this
one is okay too.

For the hw/rdma stuff:

Reviewed-by: Yuval Shaia 
Tested-by: Yuval Shaia 

Thanks,
Yuval


>
>  hw/hyperv/hyperv.c | 15 ++---
>  hw/rdma/rdma_backend.c | 50 +-
>  hw/rdma/rdma_rm.c  |  3 +--
>  3 files changed, 33 insertions(+), 35 deletions(-)
>
> diff --git a/hw/hyperv/hyperv.c b/hw/hyperv/hyperv.c
> index 8ca3706f5b..4ddafe1de1 100644
> --- a/hw/hyperv/hyperv.c
> +++ b/hw/hyperv/hyperv.c
> @@ -15,6 +15,7 @@
>  #include "sysemu/kvm.h"
>  #include "qemu/bitops.h"
>  #include "qemu/error-report.h"
> +#include "qemu/lockable.h"
>  #include "qemu/queue.h"
>  #include "qemu/rcu.h"
>  #include "qemu/rcu_queue.h"
> @@ -491,7 +492,7 @@ int hyperv_set_msg_handler(uint32_t conn_id,
> HvMsgHandler handler, void *data)
>  int ret;
>  MsgHandler *mh;
>
> -qemu_mutex_lock(_mutex);
> +QEMU_LOCK_GUARD(_mutex);
>  QLIST_FOREACH(mh, _handlers, link) {
>  if (mh->conn_id == conn_id) {
>  if (handler) {
> @@ -501,7 +502,7 @@ int hyperv_set_msg_handler(uint32_t conn_id,
> HvMsgHandler handler, void *data)
>  g_free_rcu(mh, rcu);
>  ret = 0;
>  }
> -goto unlock;
> +return ret;
>  }
>  }
>
> @@ -515,8 +516,7 @@ int hyperv_set_msg_handler(uint32_t conn_id,
> HvMsgHandler handler, void *data)
>  } else {
>  ret = -ENOENT;
>  }
> -unlock:
> -qemu_mutex_unlock(_mutex);
> +
>  return ret;
>  }
>
> @@ -565,7 +565,7 @@ static int set_event_flag_handler(uint32_t conn_id,
> EventNotifier *notifier)
>  int ret;
>  EventFlagHandler *handler;
>
> -qemu_mutex_lock(_mutex);
> +QEMU_LOCK_GUARD(_mutex);
>  QLIST_FOREACH(handler, _flag_handlers, link) {
>  if (handler->conn_id == conn_id) {
>  if (notifier) {
> @@ -575,7 +575,7 @@ static int set_event_flag_handler(uint32_t conn_id,
> EventNotifier *notifier)
>  g_free_rcu(handler, rcu);
>  ret = 0;
>  }
> -goto unlock;
> +return ret;
>  }
>  }
>
> @@ -588,8 +588,7 @@ static int set_event_flag_handler(uint32_t conn_id,
> EventNotifier *notifier)
>  } else {
>  ret = -ENOENT;
>  }
> -unlock:
> -qemu_mutex_unlock(_mutex);
> +
>  return ret;
>  }
>
> diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
> index 3dd39fe1a7..db7e5c8be5 100644
> --- a/hw/rdma/rdma_backend.c
> +++ b/hw/rdma/rdma_backend.c
> @@ -95,36 +95,36 @@ static int rdma_poll_cq(RdmaDeviceResources
> *rdma_dev_res, struct ibv_cq *ibcq)
>  struct ibv_wc wc[2];
>  RdmaProtectedGSList *cqe_ctx_list;
>
> -qemu_mutex_lock(_dev_res->lock);
> -do {
> -ne = ibv_poll_cq(ibcq, ARRAY_SIZE(wc), wc);
> +WITH_QEMU_LOCK_GUARD(_dev_res->lock) {
> +do {
> +ne = ibv_poll_cq(ibcq, ARRAY_SIZE(wc), wc);
>
> -trace_rdma_poll_cq(ne, ibcq);
> +trace_rdma_poll_cq(ne, ibcq);
>
> -for (i = 0; i < ne; i++) {
> -bctx = rdma_rm_get_cqe_ctx(rdma_dev_res, wc[i].wr_id);
> -if (unlikely(!bctx)) {
> -rdma_error_report("No matching ctx for req %"PRId64,
> -  wc[i].wr_id);
> -continue;
> -}
> +for (i = 0; i < ne; i++) {
> +bctx = rdma_rm_get_cqe_ctx(rdma_dev_res, wc[i].wr_id);
> +if (unlikely(!bctx)) {
> +rdma_error_report("No matching ctx for req %"PRId64,
> +  wc[i].wr_id);
> +continue;
> +}
>
> -comp_handler(bctx->up_ctx, [i]);
> +comp_handler(bctx->up_ctx, [i]);
>
> -if (bctx->backend_qp) {
> -cqe_ctx_list = >backend_qp->cqe_ctx_list;
> -} else {
> -cqe_ctx_list = >backend_srq->cqe_ctx_list;
> -}
> +if (bctx->backend_qp) {
> +cqe_ctx_list = >backend_qp->cqe_ctx_list;
> +} else {
> +cqe_ctx_list = >backend_srq->cqe_ctx_list;
> +}
>
> -rdma_protected_gslist_remove_int32(cqe_ctx_list, wc[i].wr_id);
> -rdma_rm_dealloc_cqe_ctx(rdma_dev_res, wc[i].wr_id);
> -g_free(bctx);
> -}
> -total_ne += ne;
> -} while (ne > 0);
> -atomic_sub(_dev_res->stats.missing_cqe, total_ne);
> -qemu_mutex_unlock(_dev_res->lock);
> +

[PATCH 1/3] bugfix: Use gicr_typer in arm_gicv3_icc_reset

2020-04-13 Thread Keqian Zhu
The KVM_VGIC_ATTR macro expect the second parameter as gicr_typer,
of which high 32bit is constructed by mp_affinity. For most case,
the high 32bit of mp_affinity is zero, so it will always access the
ICC_CTLR_EL1 of CPU0.

Signed-off-by: Keqian Zhu 
---
 hw/intc/arm_gicv3_kvm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index 49304ca589..ca43bf87ca 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -658,13 +658,11 @@ static void kvm_arm_gicv3_get(GICv3State *s)
 
 static void arm_gicv3_icc_reset(CPUARMState *env, const ARMCPRegInfo *ri)
 {
-ARMCPU *cpu;
 GICv3State *s;
 GICv3CPUState *c;
 
 c = (GICv3CPUState *)env->gicv3state;
 s = c->gic;
-cpu = ARM_CPU(c->cpu);
 
 c->icc_pmr_el1 = 0;
 c->icc_bpr[GICV3_G0] = GIC_MIN_BPR;
@@ -681,7 +679,7 @@ static void arm_gicv3_icc_reset(CPUARMState *env, const 
ARMCPRegInfo *ri)
 
 /* Initialize to actual HW supported configuration */
 kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS,
-  KVM_VGIC_ATTR(ICC_CTLR_EL1, cpu->mp_affinity),
+  KVM_VGIC_ATTR(ICC_CTLR_EL1, c->gicr_typer),
   >icc_ctlr_el1[GICV3_NS], false, _abort);
 
 c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
-- 
2.19.1




[PATCH 2/3] intc/gicv3_kvm: use kvm_gicc_access to get ICC_CTLR_EL1

2020-04-13 Thread Keqian Zhu
Replace kvm_device_access with kvm_gicc_access to simplify
code.

Signed-off-by: Keqian Zhu 
---
 hw/intc/arm_gicv3_kvm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index ca43bf87ca..85f6420498 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -678,9 +678,8 @@ static void arm_gicv3_icc_reset(CPUARMState *env, const 
ARMCPRegInfo *ri)
 }
 
 /* Initialize to actual HW supported configuration */
-kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS,
-  KVM_VGIC_ATTR(ICC_CTLR_EL1, c->gicr_typer),
-  >icc_ctlr_el1[GICV3_NS], false, _abort);
+kvm_gicc_access(s, ICC_CTLR_EL1, c->cpu->cpu_index,
+>icc_ctlr_el1[GICV3_NS], false);
 
 c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
 }
-- 
2.19.1




[PATCH 0/3] Some trivial fixes

2020-04-13 Thread Keqian Zhu
Hi all,

This patch-set contains trivial bugfix and typo fix.

Thanks,
Keqian

Keqian Zhu (3):
  bugfix: Use gicr_typer in arm_gicv3_icc_reset
  intc/gicv3_kvm: use kvm_gicc_access to get ICC_CTLR_EL1
  Typo: Correct the name of CPU hotplug memory region

 hw/acpi/cpu.c   | 2 +-
 hw/intc/arm_gicv3_kvm.c | 7 ++-
 2 files changed, 3 insertions(+), 6 deletions(-)

-- 
2.19.1




  1   2   >