Re: [RESEND v5 3/4] target/ppc: turned SPR R/W callbacks not static

[David Gibson]

On Fri, May 07, 2021 at 08:55:12AM -0300, Bruno Larsen (billionai) wrote:
> To be able to compile translate_init.c.inc as a standalone file,
> we have to make the callbacks accessible outside of translate.c;
> This patch does exactly that
> 
> Signed-off-by: Bruno Larsen (billionai)
> 

Applied to ppc-for-6.1, thanks.

> ---
>  target/ppc/spr_tcg.h   | 134 ++
>  target/ppc/translate.c | 210 -
>  2 files changed, 237 insertions(+), 107 deletions(-)
>  create mode 100644 target/ppc/spr_tcg.h
> 
> diff --git a/target/ppc/spr_tcg.h b/target/ppc/spr_tcg.h
> new file mode 100644
> index 00..1d2890dea0
> --- /dev/null
> +++ b/target/ppc/spr_tcg.h
> @@ -0,0 +1,134 @@
> +/*
> + *  PowerPC emulation for qemu: read/write callbacks for SPRs
> + *
> + *  Copyright (C) 2021 Instituto de Pesquisas Eldorado
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + */
> +#ifndef SPR_TCG_H
> +#define SPR_TCG_H
> +
> +/* prototypes for readers and writers for SPRs */
> +void spr_noaccess(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_generic(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_generic(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_xer(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_xer(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_lr(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_lr(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_ctr(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_ctr(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_ureg(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_tbl(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_tbu(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_atbl(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_atbu(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_601_rtcl(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_601_rtcu(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_spefscr(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_spefscr(DisasContext *ctx, int sprn, int gprn);
> +
> +#ifndef CONFIG_USER_ONLY
> +void spr_write_generic32(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_clear(DisasContext *ctx, int sprn, int gprn);
> +void spr_access_nop(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_decr(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_decr(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_tbl(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_tbu(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_atbl(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_atbu(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_ibat(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_ibat_h(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_ibatu(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_ibatu_h(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_ibatl(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_ibatl_h(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_dbat(DisasContext *ctx, int gprn, int sprn);
> +void spr_read_dbat_h(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_dbatu(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_dbatu_h(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_dbatl(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_dbatl_h(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_sdr1(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_601_rtcu(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_601_rtcl(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_hid0_601(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_601_ubat(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_601_ubatu(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_601_ubatl(DisasContext *ctx, int sprn, int gprn);
> +void spr_read_40x_pit(DisasContext *ctx, int gprn, int sprn);
> +void spr_write_40x_pit(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_40x_dbcr0(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_40x_sler(DisasContext *ctx, int sprn, int gprn);
> +void spr_write_booke_tcr(DisasContext *ctx, int sprn, int gprn);

Re: [PATCH v3 15/17] target/ppc/kvm: Replace alloca() by g_malloc()

[David Gibson]

On Fri, May 07, 2021 at 04:43:13PM +0200, Philippe Mathieu-Daudé wrote:
> The ALLOCA(3) man-page mentions its "use is discouraged".
> 
> Use autofree heap allocation instead, replacing it by a g_malloc call.
> 
> Reviewed-by: Greg Kurz 
> Signed-off-by: Philippe Mathieu-Daudé 

Acked-by: David Gibson 

> ---
>  target/ppc/kvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 104a308abb5..23c4ea377e8 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2698,11 +2698,11 @@ int kvmppc_save_htab(QEMUFile *f, int fd, size_t 
> bufsize, int64_t max_ns)
>  int kvmppc_load_htab_chunk(QEMUFile *f, int fd, uint32_t index,
> uint16_t n_valid, uint16_t n_invalid, Error 
> **errp)
>  {
> -struct kvm_get_htab_header *buf;
> +g_autofree struct kvm_get_htab_header *buf = NULL;
>  size_t chunksize = sizeof(*buf) + n_valid * HASH_PTE_SIZE_64;
>  ssize_t rc;
>  
> -buf = alloca(chunksize);
> +buf = g_malloc(chunksize);
>  buf->index = index;
>  buf->n_valid = n_valid;
>  buf->n_invalid = n_invalid;

-- 
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 0/2] ppc/pnv: Add support for the POWER10 DD2 CPU

[David Gibson]

On Wed, May 05, 2021 at 11:06:07AM +0200, Cédric Le Goater wrote:
> Hello,
> 
> The POWER10 DD2 CPU adds an extra LPCR[HAIL] bit which is a requirement
> to support the scv instruction on PowerNV POWER10 platforms (glibc-2.33).
> 
> These changes add a POWER10 DD2 CPU and switch the default chip model
> of the powernv10 machine to use this CPU. This to make sure that the
> machine can boot the latest distros.

LGTM as far as it goes.  Couple of points

 * I'd prefer to combine the two patches together, basically
   atomically replacing DD1 with DD2
 * I'd like to sort out the DAWR1 support first, or at the same time.
   I think it's reasonable to treat anything about POWER10 emulation
   as experimental and unstable until we put an actually publically
   available chip in there.  If we sort out DAWR1 support now, it
   means we can avoid having another spapr capability flag to handle
   the case of qemu versions that support DD2, but not DAWR1.

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

[Bug 1920602] Re: QEMU crash after a QuickBASIC program integer overflow

[Philippe Mathieu-Daudé]

FErr# IRQ raise since bf13bfab084 ("i386: implement IGNNE"):

  Change the handling of port F0h writes and FPU exceptions to implement IGNNE.
  
  The implementation mixes a bit what the chipset and processor do in real
  hardware, but the effect is the same as what happens with actual FERR#
  and IGNNE# pins: writing to port F0h asserts IGNNE# in addition to lowering
  FP_IRQ; while clearing the SE bit in the FPU status word deasserts IGNNE#.

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

Title:
  QEMU crash after a QuickBASIC program integer overflow

Status in QEMU:
  Confirmed

Bug description:
  A trivial program compiled with QuickBASIC 4.5 with integer overflow
  will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:

  C:\KILLER>type killer.bas
  A% = VAL("9"):PRINT A%

  C:\KILLER>killer.exe
  **
    ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
  Aborted

  QEMU version v5.2, compiler for ARM, and started with command line:

  qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img

  The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version
  4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On
  DOSBOX, the machine does not die and program outputs the value -31073.

  The EXE to reproduce the issue is attached.

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

Re: [RFC PATCH 2/5] hw/intc: Add Nuclei ECLIC device

[Bin Meng]

On Mon, May 10, 2021 at 10:27 AM Bin Meng  wrote:
>
> On Mon, May 10, 2021 at 10:21 AM Alistair Francis  
> wrote:
> >
> > On Fri, May 7, 2021 at 11:24 PM wangjunqiang  
> > wrote:
> > >
> > > This patch provides an implementation of Nuclei ECLIC Device.
> > > Nuclei processor core have been equipped with an Enhanced Core Local
> > > Interrupt Controller (ECLIC), which is optimized based on the RISC-V
> > > standard CLIC, to manage all interrupt sources.
> > >
> > > https://doc.nucleisys.com/nuclei_spec/isa/eclic.html
> >
> > Hello,
> >
> > There are patches on the QEMU list adding support for the CLIC. How
> > different is the ECLIC from the CLIC? Could you use the CLIC as a
> > starting point instead of implementing a new interrupt controller?
> >
>
> That's my thought too when I saw this patch at first.
>
> A better way is to scandalize the CLIC support in QEMU first, then we

Sorry for the typo. I meant to say: standardize the CLIC support

> will see how Nuclei's eCLIC could be built on top of that. Thanks!

Regards,
Bin

[Bug 1906516] Re: [RISCV] sfence.vma need to end the translation block

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Tags added: tcg

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  [RISCV] sfence.vma need to end the translation block

Status in QEMU:
  Incomplete

Bug description:
  QEMU emulator version 5.0.0

  sfence.vma will flush the tlb, so after this instruction, the translation 
block should be end. The following code will only work in single step mode:
  ```
  relocate:
   li a0, OFFSET

   la t0, 1f
   add t0, t0, a0
   csrw stvec, t0

  la t0, early_pgtbl
   srl t0, t0, PAGE_SHIFT
   li t1, SATP_SV39
   or t0, t1, t0

  csrw satp, t0
  1:
   sfence.vma
   la t0, trap_s
   csrw stvec, t0
   ret
  ```

  In this code, I want to relocate pc to virtual address with the OFFSET
  prefix. Before writing to satp, pc run at physic address, stvec has
  been set to label 1 with a virtual prefix and virtual address has been
  mapping in early_pgtbl, after writing satp, qemu will throw a page
  fault, and pc will set to virtual address of label 1.

  The problem is that, in this situation, the translation block will not
  end after sfence.vma, and stvec will be set to trap_s,

  ```
  
  IN:
  Priv: 1; Virt: 0
  0x80dc:  00a080b3  add ra,ra,a0
  0x80e0:  7297  auipc   t0,28672# 
0x800070e0
  0x80e4:  f2028293  addit0,t0,-224
  0x80e8:  00c2d293  srlit0,t0,12
  0x80ec:  fff0031b  addiw   t1,zero,-1
  0x80f0:  03f31313  sllit1,t1,63
  0x80f4:  005362b3  or  t0,t1,t0
  0x80f8:  18029073  csrrw   zero,satp,t0

  
  IN:
  Priv: 1; Virt: 0
  0x80fc:  1273  sfence.vma  zero,zero
  0x8100:  0297  auipc   t0,0# 
0x8100
  0x8104:  1c828293  addit0,t0,456
  0x8108:  10529073  csrrw   zero,stvec,t0

  riscv_raise_exception: 12
  riscv_raise_exception: 12
  riscv_raise_exception: 12
  riscv_raise_exception: 12
  ...
  ```

  So, the program will crash, and the program will work in single step mode:
  ```
  
  IN:
  Priv: 1; Virt: 0
  0x80f8:  18029073  csrrw   zero,satp,t0

  
  IN:
  Priv: 1; Virt: 0
  0x80fc:  1273  sfence.vma  zero,zero

  riscv_raise_exception: 12
  
  IN:
  Priv: 1; Virt: 0
  0x80fc:  1273  sfence.vma  zero,zero

  
  IN:
  Priv: 1; Virt: 0
  0x8100:  0297  auipc   t0,0# 
0x8100

  ```
  The pc will set to label 1, instead of trap_s.

  I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma:
  ```
  tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn);
  exit_tb(ctx);
  ctx->base.is_jmp = DISAS_NORETURN;
  ```
  This codes can help to end the tranlate block, since I'm not a qemu guy, I'm 
not sure if this is a corret method.

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

[Bug 1906536] Re: Unable to set SVE VL to 1024 bits or above since 7b6a2198

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Unable to set SVE VL to 1024 bits or above since 7b6a2198

Status in QEMU:
  Incomplete

Bug description:
  Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option
  sve-max-vq could be used to set the vector length of the
  implementation. This is useful (among other reasons) for testing
  software compiled with a fixed SVE vector length. Since this commit,
  the vector length is capped at 512 bits.

  To reproduce the issue:

  $ cat rdvl.s
  .global _start
  _start:
rdvl x0, #1
asr x0, x0, #4
mov x8, #93 // exit
svc #0
  $ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o
  $ aarch64-linux-gnu-ld rdvl.o
  $ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu 
max,sve-max-vq=$vl a.out; echo $?; done
  1
  2
  4
  4
  4

  For a QEMU built prior to the above revision, we get the output:
  1
  2
  4
  8
  16

  as expected. It seems that either the old behavior should be restored,
  or there should be an option to force a higher vector length?

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

[Bug 1906185] Re: Guest display resolution cannot be changed when using certain graphics/interface combinations

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Guest display resolution cannot be changed when using certain
  graphics/interface combinations

Status in QEMU:
  Incomplete

Bug description:
  Guest display resolution cannot be changed with certain virtual
  graphics card (-vga) and interface (-display) combinations.

  For example, resolution changing doesn't work with the following QEMU
  start commands, it resets to the default resolution immediately:

  QXL with SDL interface:
  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom 
./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display 
sdl

  QXL with GTK interface:
  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom 
./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display 
gtk

  QXL with "remote" SPICE interface via unix socket:
  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom 
./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device 
virtio-serial-pci -device 
virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev 
spicevmc,id=spicechannel0,name=vdagent -spice 
unix,addr=/tmp/vm_spice.socket,disable-ticketing

  for "remote" access:
  remote-viewer spice+unix:///tmp/vm_spice.socket


  Other tested combinations:
  -- virtio + SDL (GL on): works!
  -- virtio + GTK (GL on): does not work properly. The resolution is changed 
but window size is not so the guest screen will look like garbage.
  -- vmware: The initial Kubuntu setup screen is visible but booting does not 
progress to the desktop
  -- std + GTK: works!
  -- std + SDL: works!

  
  QEMU version: 5.1.0
  Guest: Kubuntu 20.04 64-bit (live) with 5.4.0-26 kernel; may occur with other 
guests as well
  Host: Arch Linux, with KDE desktop

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

[Bug 1905297] Re: Zynq7000 UART clock reset initialization

[Thomas Huth]

Has this been fixed in QEMU v6.0?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Zynq7000 UART clock reset initialization

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  we have come across a strange behavior in the Zynq7000 model of Qemu
  that seems to have been  introduced between 5.0.0 and 5.1.0.

  
  The reset values of the SLCR register, in particular those for UART_CLK_CTRL, 
are such that
  the UARTs should find functional clocks. Up to 5.0.0 this was also the 
behavior that was
  implemented in QEMU.

  Starting in 5.1.0, we found that - despite correct reset values [1] - the 
UARTs are non-functional
  upon reset. Some investigation revealed that the cause for that is that the 
corresponding
  clocks are not properly initialized.

  Between 5.0.0 and 5.1.0, there are three commits  that touch the Zynq
  UART clocks [2]. The last of them [3] triggers the faulty behavior.

  Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We 
surmise that the
  underlying device release issue runs much deeper, so it is only meant to 
identify the issue.


  [1] hw/misc/zynq_slcr.c
static void zynq_slcr_reset_init(Object *obj, ResetType type)
 s->regs[R_UART_CLK_CTRL]  = 0x3F03;
  [2] 38867cb7ec90..5b49a34c6800
  [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde 
Date:   Mon Apr 6 15:52:50 2020 +0200

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

[Bug 1906181] Re: Mouse starts jumping wildly on guest desktop

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Mouse starts jumping wildly on guest desktop

Status in QEMU:
  Incomplete

Bug description:
  Sometimes mouse goes completely crazy and starts jumping around the
  guest desktop by itself and becomes completely unusable.

  This does not happen on every boot, only sometimes. It may be caused
  by some input combination but I haven't yet found any specific cause.
  It happens soon after the desktop has been loaded and rebooting seems
  to be the only way to resolve the situation.

  
  Guest: Kubuntu 20.04 64-bit (live), with KDE desktop
  Host: Arch Linux, with KDE desktop
  QEMU version: 5.1.0

  QEMU start command:
  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom 
./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda 
-display sdl,gl=on

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

[Bug 1905651] Re: Tests cannot call g_error

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Tests cannot call g_error

Status in QEMU:
  Incomplete

Bug description:
  I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
  as a template.

  g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get 
run.
  This in turn means qemu is not killed, which hangs the test because the 
tap-driver.pl script hangs waiting for more input.
  There are a few tests that call g_error().

  The SIGABRT handler explicitly kills qemu, e.g.:

  qos-test.c:
  qtest_add_abrt_handler(kill_qemu_hook_func, s);

  ref:
  
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272

  But not unexpectedly there's no such handler for SIGTRAP.

  Apply this patch to trigger a repro:

  diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
  index fc226fdfeb..e83ace1b5c 100644
  --- a/tests/qtest/e1000e-test.c
  +++ b/tests/qtest/e1000e-test.c
  @@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int 
*test_sockets, QGuestAllocator *a
   /* Wait for TX WB interrupt */
   e1000e_wait_isr(d, E1000E_TX0_MSG_ID);

  +g_message("Test g_error hang ...");
  +g_error("Pretend something timed out");
  +
   /* Check DD bit */
   g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);

  Then:

  configure
  make
  make check-qtest-i386

  check-qtest-i386 will take awhile. To repro faster:

  $ grep qtest-i386/qos-test Makefile.mtest
  .test.name.229 := qtest-i386/qos-test
  $ make run-test-229
  Running test qtest-i386/qos-test
  ** Message: 18:40:49.821: Test g_error hang ...

  ** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something 
timed out
  ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out

  At this point things are hung because tap-driver.pl is still waiting
  for input because qemu is still running.

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

[Bug 1905521] Re: assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma:
  Assertion `s->current' failed

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  I found an assertion failure in hw/scsi/lsi53c895a.c:624

  This was found in latest version 5.2.0.

  
  my reproduced environment is as follows:
  Host: ubuntu 18.04
  Guest: ubuntu 18.04


  QEMU boot command line:
  qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive 
format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:-:22 -display 
none -device lsi53c895a -trace lsi\*

  Backtrace is as follows:
  #0  0x7f845c6eff47 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
  #1  0x7f845c6f18b1 in __GI_abort () at abort.c:79
  #2  0x7f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 
"s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", 
line=line@entry=624, function=function@entry=0x55a10344ae60 
<__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92
  #3  0x7f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 
"s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, 
function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at 
assert.c:101
  #4  0x55a102049c65 in lsi_do_dma (s=0x6260c100, out=1) at 
../hw/scsi/lsi53c895a.c:624
  #5  0x55a102051573 in lsi_execute_script (s=0x6260c100) at 
../hw/scsi/lsi53c895a.c:1250
  #6  0x55a10205b05d in lsi_reg_writeb (s=0x6260c100, offset=47, 
val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984
  #7  0x55a10205fef8 in lsi_io_write (opaque=0x6260c100, addr=47, 
val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146
  #8  0x55a102d1b791 in memory_region_write_accessor (mr=0x6260cbe0, 
addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at 
../softmmu/memory.c:484
  #9  0x55a102d1bba8 in access_with_adjusted_size (addr=47, 
value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, 
access_fn=0x55a102d1b4de , mr=0x6260cbe0, 
attrs=...) at ../softmmu/memory.c:545
  #10 0x55a102d261ef in memory_region_dispatch_write (mr=0x6260cbe0, 
addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494
  #11 0x55a102b57c3c in flatview_write_continue (fv=0x606ea920, 
addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, 
mr=0x6260cbe0) at ../softmmu/physmem.c:2767
  #12 0x55a102b57f07 in flatview_write (fv=0x606ea920, addr=49199, 
attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807
  #13 0x55a102b587cb in address_space_write (as=0x55a105ebca80 
, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at 
../softmmu/physmem.c:2899
  #14 0x55a102b58878 in address_space_rw (as=0x55a105ebca80 
, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, 
is_write=true) at ../softmmu/physmem.c:2909
  #15 0x55a102ad4d50 in kvm_handle_io (port=49199, attrs=..., 
data=0x7f8449efb000, direction=1, size=1, count=1) at 
../accel/kvm/kvm-all.c:2283
  #16 0x55a102ad6a0f in kvm_cpu_exec (cpu=0x62e00400) at 
../accel/kvm/kvm-all.c:2529
  #17 0x55a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e00400) at 
../accel/kvm/kvm-cpus.c:49
  #18 0x55a1032c08f8 in qemu_thread_start (args=0x60382780) at 
../util/qemu-thread-posix.c:521
  #19 0x7f845caa96db in start_thread (arg=0x7f8349dff700) at 
pthread_create.c:463
  #20 0x7f845c7d2a3f in clone 

[Bug 1905562] Re: Guest seems suspended after host freed memory for it using oom-killer

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Guest seems suspended after host freed memory for it using oom-killer

Status in QEMU:
  Incomplete

Bug description:
  Host: qemu 5.1.0, linux 5.5.13
  Guest: Windows 7 64-bit

  This guest ran a memory intensive process, and triggered oom-killer on
  host.  Luckily, it killed chromium.  My understanding is this should
  mean qemu should have continued running unharmed.  But, the spice
  connection shows the host system clock is stuck at the exact time oom-
  killer was triggered.  The host is completely unresponsive.

  I can telnet to the qemu monitor.  "info status" shows "running".
  But, multiple times running "info registers -a" and saving the output
  to text files shows the registers are 100% unchanged, so it's not
  really running.

  On the host, top shows around 4% CPU usage by qemu.  strace shows
  about 1,000 times a second, these 6 lines repeat:

  0.000698 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c10) = 0 <0.10>
  0.34 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c60) = 0 <0.09>
  0.31 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c20) = 0 <0.07>
  0.28 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c70) = 0 <0.07>
  0.30 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, 
events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events
 =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, 
events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, 
events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)  <0.09>
  0.43 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, 
events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events
 =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, 
events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, 
events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, 
tv_nsec=769662}, NULL, 8) = 0 (Tim eout) <0.000788>

  In the monitor, "info irq" shows IRQ 0 is increasing about 1,000 times
  a second.  IRQ 0 seems to be for the system clock, and 1,000 times a
  second seems to be the frequency a windows 7 guest might have the
  clock at.

  Those fd's are for: (9) [eventfd]; [signalfd], type=STREAM, 4 x the
  spice socket file, and "TCP localhost:ftnmtp->localhost:36566
  (ESTABLISHED)".

  Because the guest's registers aren't changing, it seems to me like
  monitor thinks the VM is running, but it's actually effectively in a
  paused state.  I think all the strace activity shown above must be
  generated by the host.  Perhaps it's repeatedly trying to contact the
  guest to inject a new clock, and communicate with it on the various
  eventfd's, spice socket, etc.  So, I'm thinking the strace doesn't
  give any information about the real reason why the VM is acting as if
  it's paused.

  I've checked "info block", and there's nothing showing that a device
  is paused, or that there's any issues with them.  (Can't remember what
  term can be there, but a paused/blocked/etc block device I think
  caused a VM to act like this for me in the past.)

  
  Is there something I can provide to help fix the bug here?

  Is there something I can do, to try to get the VM running again?  (I
  sadly have unsaved work in it.)

To manage notifications 

[Bug 1906184] Re: Lots of stuttering/crackling in guest sound

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Lots of stuttering/crackling in guest sound

Status in QEMU:
  Incomplete

Bug description:
  When listening to music (e.g. with VLC) or watching Youtube on the
  guest, there's lots of stuttering and crackling in the sound.

  
  Tested with the following QEMU start commands:

  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom
  ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw
  hda -display sdl,gl=on

  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom
  ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda
  -display sdl

  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom
  ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda
  -display gtk

  
  If I use the following command (QXL graphics, "remote" access via SPICE over 
unix socket), stuttering is not completely gone but MUCH less annoying:

  qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom
  ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl
  -device virtio-serial-pci -device
  virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev
  spicevmc,id=spicechannel0,name=vdagent -spice
  unix,addr=/tmp/vm_spice.socket,disable-ticketing

  and this command for accessing the VM:
  remote-viewer spice+unix:///tmp/vm_spice.socket 


  Guest: Kubuntu 20.04 64-bit (live), but occurs with many other as well
  Host: Arch Linux, with KDE desktop
  CPU: Intel Xeon E3-1230v2 (4 cores + hyperthreading)
  RAM: 16 GB
  GPU: Nvidia GTX 980 Ti

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

[Bug 1761798] Re: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8"

[Thomas Huth]

Is this still an issue with the latest release of QEMU (v6.0)?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  live migration intermittently fails in CI with "VQ 0 size 0x80 Guest
  index 0x12c inconsistent with Host index 0x134: delta 0xfff8"

Status in OpenStack Compute (nova):
  Confirmed
Status in QEMU:
  Incomplete

Bug description:
  Seen here:

  http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-
  multinode-live-
  migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-0002.txt.gz

  2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev 
pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to 
/dev/pts/0 (label charserial0)
  warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
  2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 
0x12c inconsistent with Host index 0x134: delta 0xfff8
  2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load 
virtio-blk:virtio
  2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for 
instance 0x0 of device ':00:04.0/virtio-blk'
  2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: 
Operation not permitted
  2018-04-05 21:48:43.198+: shutting down, reason=crashed

  And in the n-cpu logs on the other host:

  http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-
  multinode-live-
  migration/8de6e74/logs/screen-n-cpu.txt.gz#_Apr_05_21_48_43_257541

  There is a related Red Hat bug:

  https://bugzilla.redhat.com/show_bug.cgi?id=1450524

  The CI job failures are at present using the Pike UCA:

  ii  libvirt-bin 3.6.0-1ubuntu6.2~cloud0

  ii  qemu-system-x86 1:2.10+dfsg-0ubuntu3.5~cloud0

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

[Bug 1905226] Re: intel-hda: stream reset bits are broken

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  intel-hda: stream reset bits are broken

Status in QEMU:
  Incomplete

Bug description:
  From HD audio spec, section 3.3.35:

  "Stream Reset (SRST): Writing a 1 causes the corresponding stream to
  be reset. [...] After the stream hardware has completed sequencing
  into the reset state, it will report a 1 in this bit. Software must
  read a 1 from this bit to verify that the stream is in reset. Writing
  a 0 causes the corresponding stream to exit reset. When the stream
  hardware is ready to begin operation, it will report a 0 in this bit.
  Software must read a 0 from this bit before accessing any of the
  stream registers."

  So to reset a stream I set the bit, but it never reads back as 1 so
  the driver either times out or will hang forever waiting for it to
  become 1. I looked into why this happens and found that as of the
  latest version (8110fa1), in function intel_hda_set_st_ctl() of the
  https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c,

  if (st->ctl & 0x01) {
  /* reset */
  dprint(d, 1, "st #%d: reset\n", reg->stream);
  st->ctl = SD_STS_FIFO_READY << 24;
  }

  This causes the bit to immediately become set to 0 even if I write a
  1, and clearly does not meet the spec. I checked behaviour of real
  hardware and it works as expected, i.e. I see the bit will become 1
  and 0 when I write to it.

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

[Bug 1904652] Re: Assertion failure in usb-ohci

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Assertion failure in usb-ohci

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  Using hypervisor fuzzer, hyfuzz, I found an assertion failure through
  usb-ohci.

  A malicious guest user/process could use this flaw to abort the QEMU
  process on the host, resulting in a denial of service.

  This was found in version 5.2.0 (master)

  

  ```

  Program terminated with signal SIGABRT, Aborted.

  #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
  [Current thread is 1 (Thread 0x7f34d0411440 (LWP 9418))]
  gdb-peda$ bt
  #0  0x7f34c8d4ef47 in __GI_raise (sig=sig@entry=0x6) at 
../sysdeps/unix/sysv/linux/raise.c:51
  #1  0x7f34c8d508b1 in __GI_abort () at abort.c:79
  #2  0x55d3a2081844 in ohci_frame_boundary (opaque=0x55d3a4ecdaf0) at 
../hw/usb/hcd-ohci.c:1297
  #3  0x55d3a25be155 in timerlist_run_timers (timer_list=0x55d3a3fd9840) at 
../util/qemu-timer.c:574
  #4  0x55d3a25beaba in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at 
../util/qemu-timer.c:588
  #5  0x55d3a25beaba in qemu_clock_run_all_timers () at 
../util/qemu-timer.c:670
  #6  0x55d3a25e69a1 in main_loop_wait (nonblocking=) at 
../util/main-loop.c:531
  #7  0x55d3a2433972 in qemu_main_loop () at ../softmmu/vl.c:1678
  #8  0x55d3a1d0969b in main (argc=, argc@entry=0x15, 
argv=,
  argv@entry=0x7ffc6de722a8, envp=) at ../softmmu/main.c:50
  #9  0x7f34c8d31b97 in __libc_start_main (main=
  0x55d3a1d09690 , argc=0x15, argv=0x7ffc6de722a8, init=, fini=, rtld_fini=, 
stack_end=0x7ffc6de72298) at ../csu/libc-start.c:310
  #10 0x55d3a1d095aa in _start ()
  ```

  To reproduce the assertion failure, please run the QEMU with the
  following command line.

  ```
  [Terminal 1]

  $ qemu-system-i386 -m 512 -drive
  file=./fs.img,index=1,media=disk,format=raw -drive
  file=./hyfuzz.img,index=0,media=disk,format=raw -drive
  if=none,id=stick,file=./usbdisk.img,format=raw -device pci-ohci,id=usb
  -device usb-storage,bus=usb.0,drive=stick

  [Terminal 2]

  $ ./repro_log ./fs.img ./pci-ohci

  ```

  Please let me know if I can provide any further info.
  -Cheolwoo, Myung (Seoul National University)

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

[Bug 1904490] Re: intel-hda: valid registers are unknown

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  intel-hda: valid registers are unknown

Status in QEMU:
  Incomplete

Bug description:
  According to HDA specification, "3.1.2 General Register Behaviors and
  Access Requirements":

  "All controller registers must be addressable as byte, Word, and Dword
  quantities."

  But e.g. if you try the following to reset and enable the CORB,
  assuming es:esi contains the base MMIO address of the controller,

   es or [esi+4bh], byte 80h   ; reset CORB
  corbresetloop:
   es test [esi+4bh], byte 80h ; is HW done resetting yet?
   jnz corbreset1ok; yes, bit is now 1
   hlt ; wait a little bit
   jmp corbresetloop   ; and check again
  corbreset1ok:
   es and [esi+4bh], byte 7fh  ; clear the bit

  It will hang indefinitely because the bit never gets set, and if you
  enable debug output of the controller with "-device intel-
  hda,debug=1", you will see infinitely the line "unknown register, addr
  0x4b" output. The same code on a real hardware (I tried with ICH7M)
  works fine, as it should according to the spec.

  Host/guest/version does not matter (I am writing own drivers) --- as
  of right now, latest version still has this code:

  https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c

  which seems to emit "unknown register" message in
  intel_hda_reg_find(), and this function does not take into account
  range of addresses that each register occupies.

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

[Bug 1904317] Re: cpu feature selection is not affected to guest 's cpuid with whpx

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Tags added: whpx

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  cpu feature selection is not affected to guest 's cpuid with whpx

Status in QEMU:
  Incomplete

Bug description:
  On windows with -accel whpx, "-cpu" is ignored without any messages.
  Guest recognizes features as same as host's.

  Confirmed on v5.2.0-rc1.

  I suggest qemu may do,

  - Warn with incompatible -cpu options were given.
  - Enhance cpuid handling.

  Background:
  I was investigated mmio and block copy issue in Linux kernel.
  I met a problem that Linux went ill for touching mmio with whpx. (not with 
tcg)
  I suspect erms(enhanced rep movs) might trigger.
  I tried to mask erms on qemu with -feature,erms, but it was ineffective.

  At last, I disabled erms manually, to tweak whpx-all.c to mask erms in
  cpuid.

  FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of 
erms.
  Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms.

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

[Bug 1904464] Re: Build fails with 64 bits time_t

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Build fails with 64 bits time_t

Status in QEMU:
  Incomplete

Bug description:
  time element is deprecated on new input_event structure in kernel's
  input.h [1]

  This will avoid the following build failure:

  hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
  hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no 
member named 'time'
198 | if (gettimeofday(, NULL)) {
|^

  Fixes:
   - 
http://autobuild.buildroot.org/results/a538167e288c14208d557cd45446df86d3d599d5
   - 
http://autobuild.buildroot.org/results/efd4474fb4b6c0ce0ab3838ce130429c51e43bbb

  [1]
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f

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

[PATCH] block: Improve backing file validation

[Li Zhijian]

Image below user cases:
case 1:
```
$ qemu-img create -f raw source.raw 1G
$ qemu-img create -f qcow2 -F raw -b source.raw ./source.raw
qemu-img info source.raw
image: source.raw
file format: qcow2
virtual size: 193K (197120 bytes)
disk size: 196K
cluster_size: 65536
backing file: source.raw <<
backing file format: raw
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
```

case 2:
```
$ qemu-img create -f raw source.raw 1G
$ ln -sf source.raw destination.qcow2
$ qemu-img create -f qcow2 -F raw -b source.raw ./destination.qcow2
qemu-img info source.raw
image: source.raw
file format: qcow2 <<
virtual size: 2.0G (2147483648 bytes)
disk size: 196K
cluster_size: 65536
backing file: source.raw
backing file format: raw
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
```
Generally, we don't expect to corrupte the source.raw anyway, while
actually it does.

Here we validate the realpath of file instead the input string.

Signed-off-by: Li Zhijian 
---
 block.c | 46 +++---
 1 file changed, 39 insertions(+), 7 deletions(-)

diff --git a/block.c b/block.c
index 9ad725d205..523845b763 100644
--- a/block.c
+++ b/block.c
@@ -6431,6 +6431,44 @@ bool bdrv_op_blocker_is_empty(BlockDriverState *bs)
 return true;
 }
 
+static bool validate_backing_file(const char *filename,
+  const char *backing_file, Error **errp)
+{
+bool ret = false;
+char *rf, *real_filename = g_malloc0(PATH_MAX + 1);
+char *rb, *real_backing = g_malloc0(PATH_MAX + 1);
+
+rf = realpath(filename, real_filename);
+if (!rf) {
+if (errno == ENOENT) {
+/* filename doesn't exit, ignore it */
+rf = (char *)filename;
+} else {
+error_setg(errp, "Failed to resolve %s", filename);
+goto out;
+}
+}
+rb = realpath(backing_file, real_backing);
+if (!rb) {
+error_setg(errp, "Failed to resolve %s", backing_file);
+goto out;
+}
+if (!strcmp(rf, rb)) {
+error_setg(errp, "Error: Trying to create an image with the "
+"same filename as the backing file");
+goto out;
+}
+if (backing_file[0] == '\0') {
+error_setg(errp, "Expected backing file name, got empty string");
+goto out;
+}
+ret = true;
+out:
+g_free(real_filename);
+g_free(real_backing);
+return ret;
+}
+
 void bdrv_img_create(const char *filename, const char *fmt,
  const char *base_filename, const char *base_fmt,
  char *options, uint64_t img_size, int flags, bool quiet,
@@ -6507,13 +6545,7 @@ void bdrv_img_create(const char *filename, const char 
*fmt,
 
 backing_file = qemu_opt_get(opts, BLOCK_OPT_BACKING_FILE);
 if (backing_file) {
-if (!strcmp(filename, backing_file)) {
-error_setg(errp, "Error: Trying to create an image with the "
- "same filename as the backing file");
-goto out;
-}
-if (backing_file[0] == '\0') {
-error_setg(errp, "Expected backing file name, got empty string");
+if (!validate_backing_file(filename, backing_file, errp)) {
 goto out;
 }
 }
-- 
2.30.2

[Bug 1904315] Re: CTRL+ALT is ignored on gtk window (configured with gtk and sdl)

[Thomas Huth]

Can you still reproduce the issue with the latest release QEMU v6.0?

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  CTRL+ALT is ignored on gtk window (configured with gtk and sdl)

Status in QEMU:
  Incomplete

Bug description:
  I am building and using qemu on Windows 10 via git.
  Building for targeting windows, on debian.

  Since meson is introduced, my executable, qemu-system-x86_64.exe, tends to 
ignore hotkeys
  (like CTRL+ATL+G, CTRL+ALT+2)

  As far as I have been investigating the issue, I am suspicious that gtk and 
sdl might be incompatible.
  With configure --disable-sdl, my executable works fine.
  My application doesn't require sdl.

  Possibly due to link order, especially SDLmain, I guess.

  I suggest;
  - Clarify that gtk and sdl are incompatible.
  - Tweak built script or startup not to prevent gtk and sdl each other.

  Excuse me, the issue has not been reproduced at home yet. I met it at work.
  (My manager said it's fine to report issues by me at home)
  I will construct reproducible environment at home, if my further 
investigation would be required.

  Thanks.

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

Re: [RFC PATCH 2/5] hw/intc: Add Nuclei ECLIC device

[Bin Meng]

On Mon, May 10, 2021 at 10:21 AM Alistair Francis  wrote:
>
> On Fri, May 7, 2021 at 11:24 PM wangjunqiang  wrote:
> >
> > This patch provides an implementation of Nuclei ECLIC Device.
> > Nuclei processor core have been equipped with an Enhanced Core Local
> > Interrupt Controller (ECLIC), which is optimized based on the RISC-V
> > standard CLIC, to manage all interrupt sources.
> >
> > https://doc.nucleisys.com/nuclei_spec/isa/eclic.html
>
> Hello,
>
> There are patches on the QEMU list adding support for the CLIC. How
> different is the ECLIC from the CLIC? Could you use the CLIC as a
> starting point instead of implementing a new interrupt controller?
>

That's my thought too when I saw this patch at first.

A better way is to scandalize the CLIC support in QEMU first, then we
will see how Nuclei's eCLIC could be built on top of that. Thanks!

Regards,
Bin

Re: [RFC PATCH 2/5] hw/intc: Add Nuclei ECLIC device

[Alistair Francis]

On Fri, May 7, 2021 at 11:24 PM wangjunqiang  wrote:
>
> This patch provides an implementation of Nuclei ECLIC Device.
> Nuclei processor core have been equipped with an Enhanced Core Local
> Interrupt Controller (ECLIC), which is optimized based on the RISC-V
> standard CLIC, to manage all interrupt sources.
>
> https://doc.nucleisys.com/nuclei_spec/isa/eclic.html

Hello,

There are patches on the QEMU list adding support for the CLIC. How
different is the ECLIC from the CLIC? Could you use the CLIC as a
starting point instead of implementing a new interrupt controller?

Alistair

> ---
>  hw/intc/Kconfig|   3 +
>  hw/intc/meson.build|   1 +
>  hw/intc/nuclei_eclic.c | 437 +
>  include/hw/intc/nuclei_eclic.h | 115 +
>  4 files changed, 556 insertions(+)
>  create mode 100644 hw/intc/nuclei_eclic.c
>  create mode 100644 include/hw/intc/nuclei_eclic.h
>
> diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
> index f4694088a4..eab30f6ffd 100644
> --- a/hw/intc/Kconfig
> +++ b/hw/intc/Kconfig
> @@ -73,3 +73,6 @@ config GOLDFISH_PIC
>
>  config M68K_IRQC
>  bool
> +
> +config NUCLEI_ECLIC
> +bool
> diff --git a/hw/intc/meson.build b/hw/intc/meson.build
> index 1c299039f6..7577ba69d2 100644
> --- a/hw/intc/meson.build
> +++ b/hw/intc/meson.build
> @@ -50,6 +50,7 @@ specific_ss.add(when: 'CONFIG_S390_FLIC_KVM', if_true: 
> files('s390_flic_kvm.c'))
>  specific_ss.add(when: 'CONFIG_SH_INTC', if_true: files('sh_intc.c'))
>  specific_ss.add(when: 'CONFIG_SIFIVE_CLINT', if_true: 
> files('sifive_clint.c'))
>  specific_ss.add(when: 'CONFIG_SIFIVE_PLIC', if_true: files('sifive_plic.c'))
> +specific_ss.add(when: 'CONFIG_NUCLEI_ECLIC', if_true: 
> files('nuclei_eclic.c'))
>  specific_ss.add(when: 'CONFIG_XICS', if_true: files('xics.c'))
>  specific_ss.add(when: ['CONFIG_KVM', 'CONFIG_XICS'],
> if_true: files('xics_kvm.c'))
> diff --git a/hw/intc/nuclei_eclic.c b/hw/intc/nuclei_eclic.c
> new file mode 100644
> index 00..52de83cb1d
> --- /dev/null
> +++ b/hw/intc/nuclei_eclic.c
> @@ -0,0 +1,437 @@
> +/*
> + * NUCLEI ECLIC(Enhanced Core Local Interrupt Controller)
> + *
> + * Copyright (c) 2020 Gao ZhiYuan 
> + * Copyright (c) 2020-2021 PLCT Lab.All rights reserved.
> + *
> + * This provides a parameterizable interrupt controller based on NucLei's 
> ECLIC.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program.  If not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/log.h"
> +#include "qemu/module.h"
> +#include "qemu/error-report.h"
> +#include "hw/sysbus.h"
> +#include "hw/pci/msi.h"
> +#include "hw/boards.h"
> +#include "hw/qdev-properties.h"
> +#include "target/riscv/cpu.h"
> +#include "sysemu/sysemu.h"
> +#include "hw/intc/nuclei_eclic.h"
> +#include "qapi/error.h"
> +
> +#define RISCV_DEBUG_ECLIC 0
> +
> +static void riscv_cpu_eclic_interrupt(RISCVCPU *cpu, int exccode)
> +{
> +CPURISCVState *env = >env;
> +bool locked = false;
> +
> +env->exccode = exccode;
> +
> +if (!qemu_mutex_iothread_locked()) {
> +locked = true;
> +qemu_mutex_lock_iothread();
> +}
> +
> +if (exccode != -1) {
> +env->irq_pending = true;
> +cpu_interrupt(CPU(cpu), CPU_INTERRUPT_ECLIC);
> +} else {
> +env->irq_pending = false;
> +cpu_reset_interrupt(CPU(cpu), CPU_INTERRUPT_ECLIC);
> +}
> +
> +if (locked) {
> +qemu_mutex_unlock_iothread();
> +}
> +}
> +
> +static int level_compare(NucLeiECLICState *eclic,
> + ECLICPendingInterrupt *irq1,
> + ECLICPendingInterrupt *irq2)
> +{
> +if (irq1->level == irq2->level) {
> +if (irq1->prio == irq2->prio) {
> +if (irq1->irq >= irq2->irq) {
> +return 0;
> +} else {
> +return 1;
> +}
> +} else if (irq1->prio > irq2->level) {
> +return 0;
> +} else {
> +return 1;
> +}
> +} else if (irq1->level > irq2->level) {
> +return 0;
> +} else {
> +return 1;
> +}
> +}
> +
> +static void nuclei_eclic_next_interrupt(void *eclic_ptr)
> +{
> +RISCVCPU *cpu = RISCV_CPU(qemu_get_cpu(0));
> +CPURISCVState *env = >env;
> +NucLeiECLICState *eclic = (NucLeiECLICState *)eclic_ptr;
> +

Re: [RFC PATCH 1/5] target/riscv: Add Nuclei CSR and Update interrupt handling

[Alistair Francis]

 C isOn Fri, May 7, 2021 at 11:25 PM wangjunqiang
 wrote:
>
> This patch adds Nuclei CSR support for ECLIC and update the
> related interrupt handling.
>
> https://doc.nucleisys.com/nuclei_spec/isa/core_csr.html

Hello,

Thanks for the patches!

This patch is very long and you will need to split it up before it can
be merged. I understand this is just an RFC, but it's still best to
start with small patches. Generally each patch should add a feature
and it seems like you have added lots of features in this patch. This
patch could probably be broken into at least 4 different patches.

As well as that you will want to ensure that your commit message and
description explains what you are doing in that patch and in some
cases justify the change. For example adding a new CPU doesn't need a
justification (as that's easy for me to understand), but changing some
existing code might need an explanation of why we need/want that
change.

This is still a great start though! I look forward to your future patches.

I have left a few comments below as well.

> ---
>  target/riscv/cpu.c  |  25 +-
>  target/riscv/cpu.h  |  42 ++-
>  target/riscv/cpu_bits.h |  37 +++
>  target/riscv/cpu_helper.c   |  80 +-
>  target/riscv/csr.c  | 347 +++-
>  target/riscv/insn_trans/trans_rvi.c.inc |  16 +-
>  target/riscv/op_helper.c|  14 +
>  7 files changed, 552 insertions(+), 9 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 7d6ed80f6b..b2a96effbc 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -173,6 +173,16 @@ static void rv64_sifive_e_cpu_init(Object *obj)
>  set_priv_version(env, PRIV_VERSION_1_10_0);
>  qdev_prop_set_bit(DEVICE(obj), "mmu", false);
>  }
> +
> +static void rv64imafdcu_nuclei_cpu_init(Object *obj)
> +{
> +CPURISCVState *env = _CPU(obj)->env;
> +set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> +set_priv_version(env, PRIV_VERSION_1_10_0);
> +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> +set_resetvec(env, DEFAULT_RSTVEC);
> +set_feature(env, RISCV_FEATURE_PMP);
> +}
>  #else
>  static void rv32_base_cpu_init(Object *obj)
>  {
> @@ -212,6 +222,16 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
>  set_resetvec(env, DEFAULT_RSTVEC);
>  qdev_prop_set_bit(DEVICE(obj), "mmu", false);
>  }
> +
> +static void rv32imafdcu_nuclei_cpu_init(Object *obj)
> +{
> +CPURISCVState *env = _CPU(obj)->env;
> +set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> +set_priv_version(env, PRIV_VERSION_1_10_0);
> +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> +set_resetvec(env, DEFAULT_RSTVEC);
> +set_feature(env, RISCV_FEATURE_PMP);
> +}
>  #endif
>
>  static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
> @@ -331,7 +351,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
>   * Definition of the WFI instruction requires it to ignore the privilege
>   * mode and delegation registers, but respect individual enables
>   */
> -return (env->mip & env->mie) != 0;
> +return ((env->mip & env->mie) != 0  || (env->exccode != -1));

This change for example needs to be explained, I'm not sure what exccode is

>  #else
>  return true;
>  #endif
> @@ -356,6 +376,7 @@ static void riscv_cpu_reset(DeviceState *dev)
>  env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
>  env->mcause = 0;
>  env->pc = env->resetvec;
> +env->exccode = -1;
>  env->two_stage_lookup = false;
>  #endif
>  cs->exception_index = EXCP_NONE;
> @@ -704,10 +725,12 @@ static const TypeInfo riscv_cpu_type_infos[] = {
>  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32_sifive_e_cpu_init),
>  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   rv32_imafcu_nommu_cpu_init),
>  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32_sifive_u_cpu_init),
> +DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_N307FD,rv32imafdcu_nuclei_cpu_init),
>  #elif defined(TARGET_RISCV64)
>  DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   rv64_base_cpu_init),
>  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64_sifive_e_cpu_init),
>  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54,   rv64_sifive_u_cpu_init),
> +DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_NX600FD,
> rv64imafdcu_nuclei_cpu_init),
>  #endif
>  };
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 0a33d387ba..1d3a1986a6 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -33,6 +33,7 @@
>  #define RISCV_CPU_TYPE_SUFFIX "-" TYPE_RISCV_CPU
>  #define RISCV_CPU_TYPE_NAME(name) (name RISCV_CPU_TYPE_SUFFIX)
>  #define CPU_RESOLVING_TYPE TYPE_RISCV_CPU
> +#define CPU_INTERRUPT_ECLIC CPU_INTERRUPT_TGT_EXT_0
>
>  #define TYPE_RISCV_CPU_ANY  RISCV_CPU_TYPE_NAME("any")
>  #define TYPE_RISCV_CPU_BASE32   RISCV_CPU_TYPE_NAME("rv32")
> @@ -43,6 +44,8 @@
>  #define TYPE_RISCV_CPU_SIFIVE_E51   

[Bug 1890208] Re: Mouse pointer disappears when it is over console window

[Adriano Marto Reis]

The emulated machine (guest) has the following graphics card, according to 
lspci:
00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card 
(rev 04)

The host machine has the following graphics card:
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M1000M] 
(rev a2)

I haven't tried to report the issue to virt-manager, but I have another
computer running Debian with a similar setup and the problem does not
happen there.

** Bug watch added: github.com/virt-manager/virt-manager/issues #251
   https://github.com/virt-manager/virt-manager/issues/251

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

Title:
  Mouse pointer disappears when it is over console window

Status in QEMU:
  Incomplete

Bug description:
  The host mouse pointer disappears when it is over a console window.

  I am emulating quite simple hardware: just text console and no mouse.
  I don't expect the mouse to have any effect on the emulated computers,
  but I need to know where the mouse pointer is. That is  important
  because I need to use the mouse to switch between applications and to
  switch between virtual machines (QEMU grabs Alt+Tab events). Also, it
  is quite tricky to work with multiple screens when we don't know where
  the mouse pointer is.

  I am using:
  * Virtual Machine Manager 2.2.1
  * QEMU 4.2.0
  * Fedora 32
  * KDE Plasma 5.18.5

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

[Bug 1890208] Re: Mouse pointer disappears when it is over console window

[Adriano Marto Reis]

I also reported this issue in:
https://github.com/virt-manager/virt-manager/issues/251

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

Title:
  Mouse pointer disappears when it is over console window

Status in QEMU:
  Incomplete

Bug description:
  The host mouse pointer disappears when it is over a console window.

  I am emulating quite simple hardware: just text console and no mouse.
  I don't expect the mouse to have any effect on the emulated computers,
  but I need to know where the mouse pointer is. That is  important
  because I need to use the mouse to switch between applications and to
  switch between virtual machines (QEMU grabs Alt+Tab events). Also, it
  is quite tricky to work with multiple screens when we don't know where
  the mouse pointer is.

  I am using:
  * Virtual Machine Manager 2.2.1
  * QEMU 4.2.0
  * Fedora 32
  * KDE Plasma 5.18.5

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

[Bug 1920602] Re: QEMU crash after a QuickBASIC program integer overflow

[Philippe Mathieu-Daudé]

Since commit 975af797f1e helper_fist_ST0() sets float_flag_invalid.

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

Title:
  QEMU crash after a QuickBASIC program integer overflow

Status in QEMU:
  Confirmed

Bug description:
  A trivial program compiled with QuickBASIC 4.5 with integer overflow
  will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:

  C:\KILLER>type killer.bas
  A% = VAL("9"):PRINT A%

  C:\KILLER>killer.exe
  **
    ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
  Aborted

  QEMU version v5.2, compiler for ARM, and started with command line:

  qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img

  The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version
  4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On
  DOSBOX, the machine does not die and program outputs the value -31073.

  The EXE to reproduce the issue is attached.

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

[Bug 1920602] Re: QEMU crash after a QuickBASIC program integer overflow

[Philippe Mathieu-Daudé]

** Changed in: qemu
   Status: New => Confirmed

** Tags added: i386 tcg

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

Title:
  QEMU crash after a QuickBASIC program integer overflow

Status in QEMU:
  Confirmed

Bug description:
  A trivial program compiled with QuickBASIC 4.5 with integer overflow
  will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:

  C:\KILLER>type killer.bas
  A% = VAL("9"):PRINT A%

  C:\KILLER>killer.exe
  **
    ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
  Aborted

  QEMU version v5.2, compiler for ARM, and started with command line:

  qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img

  The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version
  4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On
  DOSBOX, the machine does not die and program outputs the value -31073.

  The EXE to reproduce the issue is attached.

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

[Bug 1751674] Re: qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers

[Peter Maydell]

Still valid.


** Changed in: qemu
   Status: Incomplete => Confirmed

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

Title:
  qemu-system-arm segmentation fault using pmemsave on the interrupt
  controller registers

Status in QEMU:
  Confirmed

Bug description:
  Qemu segfaults trying to generate a VM memory dump:

  $ QEMU_AUDIO_DRV=none qemu-git-src/arm-softmmu/qemu-system-arm -M vexpress-a9 
-smp 4 -m 1024 -machine secure=off,dump-guest-core=on -kernel 
linux-4.9.75/arch/arm/boot/zImage -append "root=/dev/mmcblk0 rw rootfstype=ext4 
mem=1024M net.ifnames=0 console=ttyAMA0" -dtb vexpress-v2p-ca9.dtb -sd 
armv7-hd.qcow2 -netdev tap,ifname=tap_armv7,script=no,downscript=no,id=net0 
-device virtio-net-device,mac=00:AA:AD:BB:FF:02,netdev=net0  -monitor stdio 
-serial vc  -loadvm SS0
  QEMU 2.11.50 monitor - type 'help' for more information
  (qemu) pmemsave 0 0x3FFF memory.dmp
  Segmentation fault (core dumped)

  $ git rev-parse HEAD
  b384cd95eb9c6f73ad84ed1bb0717a26e29cc78f

  It's the second time I try to submit this bug, I think last time it
  failed because the attached core dump size (400M compressed). Have a
  look if you can get that file, otherwise I will try to update this
  ticket once it's created:

  (Error ID: OOPS-65553b72bc14be693eb1e37814ff9267)

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

[Bug 1920602] Re: QEMU crash after a QuickBASIC program integer overflow

[Aaro Koskinen]

Attached is a minimal FreeDOS floppy disk to reproduce the TCG crash.
Still reproducible with QEMU v6.0.0:

WARNING: Image format was not specified for 'test-floppy.img' and probing 
guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
SeaBIOS (version rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org)
Booting from Floppy...
123
FreeDOS kernel 2042 (build 2042 OEM:0xfd) [compiled May 11 2016]
Kernel compatibility 7.10 - WATCOMC - FAT32 support

(C) Copyright 1995-2012 Pasquale J. Villani and The FreeDOS Project.
All Rights Reserved. This is free software and comes with ABSOLUTELY NO
WARRANTY; you can redistribute it and/or modify it under the terms of the
GNU General Public License as published by the Free Software Foundation;
either version 2, or (at your option) any later version.
 - InitDiskno hard disks detected

FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
A:\>KILLER.EXE
**
ERROR:../accel/tcg/tcg-accel-ops.c:80:tcg_handle_interrupt: assertion failed: 
(qemu_mutex_iothread_locked())
Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:80:tcg_handle_interrupt: assertion 
failed: (qemu_mutex_iothread_locked())
Aborted


** Attachment added: "test-floppy.img.gz"
   
https://bugs.launchpad.net/qemu/+bug/1920602/+attachment/5495920/+files/test-floppy.img.gz

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

Title:
  QEMU crash after a QuickBASIC program integer overflow

Status in QEMU:
  New

Bug description:
  A trivial program compiled with QuickBASIC 4.5 with integer overflow
  will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:

  C:\KILLER>type killer.bas
  A% = VAL("9"):PRINT A%

  C:\KILLER>killer.exe
  **
    ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
  Aborted

  QEMU version v5.2, compiler for ARM, and started with command line:

  qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img

  The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version
  4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On
  DOSBOX, the machine does not die and program outputs the value -31073.

  The EXE to reproduce the issue is attached.

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Stefan Weil]

Meanwhile QEMU builds for CI and also my inofficial QEMU installers for
Windows use free WHPX headers instead of the copyrighted MS ones, so
this issue is fixed.

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

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

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Fix Released

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for 
Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable 
material.

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

Re: [PATCH v2] This makes it easier to figure out whether a particular instruction was actually translated.

[Alex Bennée]

Nathan Ringo  writes:

> I'm mostly looking at AArch64, so they're the same there :) I'm using
> this to collect code coverage information, so I have the disassembly,
> and it's slightly easier to report it that way;

Have you considered collecting this information with TCG plugins? That
way you can instrument what was actually instrumented directly.

> if you think it'd be
> more useful on other architectures to report the byte range instead,
> it'd be an easy change to my scripts.
>
> Also, noticed I accidentally deleted the first line of the commit
> message when I updated the patch... I can fix that if you want me to
> switch the size metric.


-- 
Alex Bennée

[PATCH] net/slirp.c: fix SMB share with Samba 4 and Windows XP guests

[Casper Ti. Vector]

cf. 

Signed-off-by: Casper Ti. Vector 
---
 net/slirp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/slirp.c b/net/slirp.c
index 7a4e96d..73042af 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -876,6 +876,7 @@ static int slirp_smb(SlirpState* s, const char 
*exported_dir,
 "printing = bsd\n"
 "disable spoolss = yes\n"
 "usershare max shares = 0\n"
+"server min protocol = NT1\n"
 "[qemu]\n"
 "path=%s\n"
 "read only=no\n"
-- 
2.31.1

[Bug 1792659] Re: watchpoints might not properly stop execution at the right address

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/245


** Changed in: qemu
   Status: Confirmed => Invalid

** Changed in: qemu
 Assignee: Richard Henderson (rth) => (unassigned)

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #245
   https://gitlab.com/qemu-project/qemu/-/issues/245

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

Title:
  watchpoints might not properly stop execution at the right address

Status in QEMU:
  Invalid

Bug description:
  This bug has been tested with the latest development tree
  (19b599f7664b2ebfd0f405fb79c14dd241557452).

  I am using qemu-system-i386 with the gdbserver stub. I set a
  watchpoint on some address. When the watchpoint is hit, it will be
  reported by gdb, but it might happen that eip points to the wrong
  address (execution has not properly stopped when the watchpoint was
  hit).

  The setup I used to reproduce it is quite complex, but I believe I
  have found the cause of the bug, so I will describe that.

  The check_watchpoint() function sets cflags_next_tb in order to force
  the execution of only one instruction, and then exits the current tb.
  It then expects to be called again after that one instruction is
  executed, the watchpoint is hit and it is reported to gdb.

  The problem is that another interrupt might have been generated around
  the same time as the watchpoint. If the interrupt changes eip and
  execution goes on in another address, the value of cflags_next_tb will
  be spoiled. When we come back from the interrupt to the address where
  the watchpoint is hit, it is possible that a tb with multiple
  instructions is been executed, and therefore eip points to the wrong
  address, ahead of where it should be.

  In my case, the order is as follows:
  * i8259 generates an IRQ
- cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and 
CPU_INTERRUPT_HARD
  * cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called
- it deals with CPU_INTERRUPT_TGT_EXT_1
- execution continues
  * I am exactly at the instruction where the watchpoint is hit.
- check_watchpoint() is called and cflags_next_tb is set to force the 
execution of only one instruction.
- execution breaks out of the loop with siglongjmp()
  * cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called
- it deals with the IRQ. eip is changed and cflags_next_tb is spoiled
- execution continues at the IRQ

  [...]
  * The kernel finishes dealing with the IRQ

  * I am back at the instruction where the watchpoint is hit.
- A tb is created and executed with two instructions instead of one
- eip is now ahead of the instruction that hit the watchpoint
  * cpu_handle_interrupt() is called
- it deals with CPU_INTERRUPT_DEBUG
- the watchpoint is reported by gdb, but with the wrong eip.

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

[Bug 1926277] Re: MIPS MT dvpe does not regard VPEConf0.MVP

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/244


** Changed in: qemu
   Status: Confirmed => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #244
   https://gitlab.com/qemu-project/qemu/-/issues/244

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

Title:
  MIPS MT dvpe does not regard VPEConf0.MVP

Status in QEMU:
  Invalid

Bug description:
  Hi,

  According to MIPS32® Architecture for Programmers VolumeIV-f: The
  MIPS® MT Application-Specific Extension to the MIPS32® Architecture,
  for instruction: dvpe, evpe:

  If the VPE executing the instruction is not a Master VPE, with the MVP
  bit of the VPEConf0 register set, the EVP bit is unchanged by the
  instruction.

  The pseudo code is:

  data ←  MVPControl
  GPR[rt] ←  data
  if(VPEConf0.MVP = 1) then
MVPControl.EVP ←  sc
  endif

  However the helper functions of dvpe, evpe does not regard the
  VPEConf0.MVP bit, namely, it does not check if the VPE is a master
  VPE. Code is copied below as:

  target_ulong helper_dvpe(CPUMIPSState *env)
  {
  CPUState *other_cs = first_cpu;
  target_ulong prev = env->mvp->CP0_MVPControl;

  CPU_FOREACH(other_cs) {
  MIPSCPU *other_cpu = MIPS_CPU(other_cs);
  /* Turn off all VPEs except the one executing the dvpe.  */
  if (_cpu->env != env) {
  other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP);
  mips_vpe_sleep(other_cpu);
  }
  }
  return prev;
  }

  Is this a bug?

  QEMU head commit: 0cef06d18762374c94eb4d511717a4735d668a24 is checked.

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

[Bug 1811888] Re: Qemu refuses to multiboot Elf64 kernels

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/243


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #243
   https://gitlab.com/qemu-project/qemu/-/issues/243

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

Title:
  Qemu refuses to multiboot Elf64 kernels

Status in QEMU:
  Invalid

Bug description:
  Qemu does not multiboot Elf64 bit kernels when emulating x86_64
  systems. This is unfortunate because it renders the `-kernel` option
  quite useless. It's true that a multiboot compatible bootloader puts
  you in protected mode by default, and you have to set up the long mode
  yourself. While it is easy to put such 32-bit bootstrap code in a 64
  bit binary, it is not possible to compile a 64 bit kernel into a 32
  bit binary.

  After quick search, it turned out that loading 64 bit elf binaries has
  been disabled to be compatible with GRUB. However, since that time,
  both GRUB and Syslinux load 64 bit ELF kernels just fine, which makes
  qemu incompatible with them. Furthermore, it seems that this feature
  does and has always worked fine and that people have since submitted
  patches to re-enable it.

  https://patchwork.ozlabs.org/patch/62142/
  https://patchwork.kernel.org/patch/9770523/

  Please consider applying the attached patch.

  Best Regards,
  Lukasz Janyst

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

[Bug 1502613] Re: [Feature Request] Battery Status / Virtual Battery

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/242


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #242
   https://gitlab.com/qemu-project/qemu/-/issues/242

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

Title:
  [Feature Request] Battery Status / Virtual Battery

Status in QEMU:
  Invalid

Bug description:
  When using virtualization on notebooks heavily then virtual machines
  do not realize that they're running on a notebook device causing high
  power consumption because they're not switching into a optimized
  "laptop mode". This leads to the circumstance that they are trying to
  do things like defragmentation / virtus scan / etc. while the host is
  still running on batteries.

  So it would be great if QEMU / KVM would have support for emulating
  "Virtual Batteries" to guests causing them to enable power-saving
  options like disabling specific services / devices / file operations
  automatically by OS.

  Optionally a great feature would be to set virtual battery's status
  manually. For example: Current charge rate / charging / discharging /
  ...

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

[Bug 1849894] Re: hw/scsi/scsi-disk.c line 2554 allocation overflow

[Philippe Mathieu-Daudé]

Likely not happening anymore since commit e91bae8e98a ("scsi: Silence
gcc warning").

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

Title:
  hw/scsi/scsi-disk.c line 2554 allocation overflow

Status in QEMU:
  Incomplete

Bug description:
  When compiling qemu from git master (at commit
  03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9
  9.2.1 , and using `-march=native -flto`, during linking of most target
  binaries, compiler does detect an issue with allocation in
  scsi_disk_new_request_dump and aborts compilation.

  
  make[1]: Entering directory '/home/user/qemu/slirp'
  make[1]: Nothing to be done for 'all'.
  make[1]: Leaving directory '/home/user/qemu/slirp'
  nm: stats64.o: no symbols
LINKaarch64-softmmu/qemu-system-aarch64
  In function ‘scsi_disk_new_request_dump’,
  inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9,
  inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21:
  hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ 
exceeds maximum object size 9223372036854775807 
[-Werror=alloc-size-larger-than=]
  hw/scsi/scsi-disk.c: In function ‘scsi_new_request’:
  /usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation 
function ‘g_malloc’ declared here
 78 | gpointer g_malloc (gsize  n_bytes) G_GNUC_MALLOC 
G_GNUC_ALLOC_SIZE(1);
|  ^
  lto1: all warnings being treated as errors
  lto-wrapper: fatal error: c++ returned 1 exit status
  compilation terminated.
  /usr/bin/ld: error: lto-wrapper failed
  collect2: error: ld returned 1 exit status


  same happens for most other targets: alpha-softmmu/qemu-system-alpha
  arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu
  /qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu-
  system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu-
  system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu-
  system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu-
  system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu-
  system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system-
  sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system-
  sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system-
  xtensa xtensaeb-softmmu/qemu-system-xtensaeb

  Notice -softmmu being a common factor here.


  The size of the allocation for the temporary buffer for dumping using
  snprintf is determined based on the size of the buffer via call to
  scsi_cdb_length. I believe the heavy inlining and constant propagation
  makes scsi_cdb_length return -1, so len = -1. Then allocation size is
  5*len + 1, or -4. Which overflows to 2^64 - 4 or so.

  The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5)
  is not 0, 1, 2, 4 or 5.

  However, I can't find out how gcc figures out that buf[0] is not one
  of these variables. To me looking at this function, compiler should
  not know anything about buf[0].

  I tried following the chain of calls back, including devirtualize
  alloc_req, and I found scsi_device_alloc_req calling these alloc_req
  callbacks, but it is itself called from scsi_req_new, which is called
  in  get_scsi_requests , just after buf is filled from QEMUFile using
  qemu_get_buffer, which ultimately goes even further into read paths,
  which there might be many AFAIK.


  
  glib2 version 2.62.1-1

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

[Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/241


** Changed in: qemu
   Status: Incomplete => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #241
   https://gitlab.com/qemu-project/qemu/-/issues/241

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

Title:
  Please refactor linux-user/mips/cpu_loop.c

Status in QEMU:
  Invalid

Bug description:
  Hello. I am working with qemu on test images. I've added a new syscall
  (436) to qemu but received ENOSYS from mips application.

  Please open "linux-user/mips/cpu_loop.c". I've added at the end of
  "mips_syscall_args" the following:

  ```
  MIPS_SYS(sys_getdents64_x32, 3)
  ```

  But

  ```
  syscall_num = env->active_tc.gpr[2] - 4000;
  if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -TARGET_ENOSYS;
  ```

  returns -TARGET_ENOSYS

  We can see that "linux-user/mips/cpu_loop.c" differs a lot from
  "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc.

  Can you please refactor mips cpu loop in the same way as arm? Thank
  you.

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

[Bug 1804678] Re: qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/240


** Changed in: qemu
   Status: Confirmed => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #240
   https://gitlab.com/qemu-project/qemu/-/issues/240

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

Title:
  qemu-3.1.0-rc0: mips emulation hangs when executing invalid
  instructions

Status in QEMU:
  Invalid

Bug description:
  QEMU version:
  -

  qemu-3.1.0-rc0 compiled from sources (earlier versions also affected)

  Summary:
  

  QEMU MIPS system emulation hangs when trying to execute the following
  invalid instructions:

  71c5a9bf   sdbbp 0x716a6
  2c4745aa   sltiu a3, v0, 0x45aa
  f47539fb   sdc1 f21, 0x39fb(v1)
  5fa5e284   invalid

  qemu-system-mips falls under an infinite loop condition and it needs
  to be ended.

  The issue has been reproduced in Ubuntu x64 host running Debian MIPS
  32-bits guest with the following command line:

  qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda
  debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1
  console=tty0"

  It can also be reproduced using mips-linux-user, in which case throws
  the following exception:

  qemu-mips mips_loop_static.elf
  qemu: unhandled CPU exception 0x10 - aborting
  pc=0x004a9da0 HI=0x0003 LO=0x0002 ds 00e2 004a9da0 0
  GPR00: r0  at fff8 v0 004a9da0 v1 004ad000
  GPR04: a0 0001 a1 7fffefc4 a2 7fffefcc a3 
  GPR08: t0 004ab854 t1 0ffe t2 81010100 t3 2f2f2f2f
  GPR12: t4 71ad t5 004ab090 t6 004ab06c t7 004ab07c
  GPR16: s0  s1 452ac505 s2 00400db4 s3 00400d38
  GPR20: s4  s5  s6  s7 
  GPR24: t8 004ab0a8 t9 004a9da0 k0  k1 
  GPR28: gp 004b25a0 sp 7fffeec0 s8 7fffeec0 ra 0040041c
  CP0 Status  0x2410 Cause   0x EPC0x
  Config0 0x80008482 Config1 0x9e190c8f LLAddr 0x
  Config2 0x8000 Config3 0x
  Config4 0x Config5 0x
  qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x602dbad8

  Testcase:
  -

  C program to reproduce the problem:

  unsigned char code[] = 
"\x71\xC5\xA9\xBF\x2C\x47\x45\xAA\xF4\x75\x39\xFB\x5F\xA5\xE2\x84";
  main()
  {
int (*ret)() = (int(*)())code;
ret();
  }

  Also, find a statically compiled ELF attached.

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

Re: [PATCH v2 00/11] PS/2 controller related fixes

[Volker Rümelin]

This patch series fixes two different PS/2 mouse stream corruptions
and adds a feature that allows some old misbehaving DOS programs to
have a working keyboard. With the last few patches, the PS/2 con-
troller behaves more like a real controller.

v2:
Introduce the function kbd_pending() in a preliminary patch to ease
the review of patch "pckbd: correctly disable PS/2 communication",
as Philippe suggested.

Volker Rümelin (11):
  ps2: fix mouse stream corruption
  ps2: don't raise an interrupt if queue is full
  ps2: don't deassert irq twice if queue is empty
  pckbd: split out interrupt line changing code
  pckbd: don't update OBF flags if KBD_STAT_OBF is set
  pckbd: PS/2 keyboard throttle
  pckbd: add state variable for interrupt source
  pckbd: add controller response queue
  pckbd: add function kbd_pending()
  pckbd: correctly disable PS/2 communication
  pckbd: remove duplicated keyboard and mouse defines


I'm sorry, there is a bug somewhere in this series. Seabios sometimes
doesn't detect the PS/2 keyboard. Please ignore this series for now.

With best regards,
Volker



 hw/input/pckbd.c | 293 ++-
 hw/input/ps2.c   |  11 +-
 2 files changed, 223 insertions(+), 81 deletions(-)

Re: [PULL 00/10] Gitlab-CI, qtest, moxie removal and misc patches

[Thomas Huth]

On 07/05/2021 14.41, Paolo Bonzini wrote:

On 07/05/21 11:45, Thomas Huth wrote:



diff --git a/Makefile b/Makefile
index bcbbec71a1..3088502329 100644
--- a/Makefile
+++ b/Makefile
@@ -85,7 +85,8 @@ x := $(shell rm -rf meson-private meson-info meson-logs)
  endif

  # 1. ensure config-host.mak is up-to-date
-config-host.mak: $(SRC_PATH)/configure $(SRC_PATH)/pc-bios 
$(SRC_PATH)/VERSION
+config-host.mak: $(SRC_PATH)/configure $(SRC_PATH)/pc-bios 
$(SRC_PATH)/VERSION \

+    $(SRC_PATH)/default-configs/targets
 @echo config-host.mak is out-of-date, running configure
 @if test -f meson-private/coredata.dat; then \
   ./config.status --skip-meson; \

I.e. re-run configure if somethings in default-configs/targets changed.
Does that look sane?


I am not sure if using a directory is reliable (it's pre-existing for
pc-bios).  However you probably can use

# currently in tests/Makefile.include, move it to toplevel Makefile
TARGETS=$(patsubst libqemu-%.fa, %, $(filter libqemu-%.fa, $(ninja-targets)))
config-host.mak: $(SRC_PATH)/configure $(TARGETS:%=default-configs/targets/%)

And then if a file goes missing it will trigger the rebuild of config-host.mak.


Sounds like an idea, too ... but I'm unsure whether it's doable due to the 
order of the statements there... TARGETS gets populated from ninja-targets, 
but ninja-targets gets set *after* the config-host.mak block ... would it be 
safe to move the config-host.mak block around?


 Thomas

[Bug 1502613] Re: [Feature Request] Battery Status / Virtual Battery

[Philippe Mathieu-Daudé]

** Changed in: qemu
 Assignee: Sergey Nizovtsev (snizovtsev) => (unassigned)

** Changed in: qemu
   Status: In Progress => New

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

Title:
  [Feature Request] Battery Status / Virtual Battery

Status in QEMU:
  New

Bug description:
  When using virtualization on notebooks heavily then virtual machines
  do not realize that they're running on a notebook device causing high
  power consumption because they're not switching into a optimized
  "laptop mode". This leads to the circumstance that they are trying to
  do things like defragmentation / virtus scan / etc. while the host is
  still running on batteries.

  So it would be great if QEMU / KVM would have support for emulating
  "Virtual Batteries" to guests causing them to enable power-saving
  options like disabling specific services / devices / file operations
  automatically by OS.

  Optionally a great feature would be to set virtual battery's status
  manually. For example: Current charge rate / charging / discharging /
  ...

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

[Bug 1912059] Re: capstone link failure building linux-user static

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/238


** Changed in: qemu
   Status: Incomplete => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #238
   https://gitlab.com/qemu-project/qemu/-/issues/238

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

Title:
  capstone link failure building linux-user static

Status in QEMU:
  Invalid

Bug description:
  $ ../configure --disable-system --static

  qemu 5.2.50

   static build: YES
   capstone: system
  [...]

  $ make qemu-i386
  [...]
  [478/478] Linking target qemu-i386
  FAILED: qemu-i386 
  cc  -o qemu-i386 libcommon.fa.p/hw_core_cpu.c.o 
libcommon.fa.p/disas_capstone.c.o libcommon.fa.p/disas_i386.c.o ... 
-Wl,--as-needed -Wl,--no-undefined -Wl,--whole-archive libhwcore.fa libqom.fa 
-Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static -m64 
-fstack-protector-strong -Wl,--start-group libqemuutil.a 
subprojects/libvhost-user/libvhost-user-glib.a 
subprojects/libvhost-user/libvhost-user.a libhwcore.fa libqom.fa -lcapstone 
-lrt -pthread -lutil -lm -lgthread-2.0 -lglib-2.0 -lpcre -lgthread-2.0 
-lglib-2.0 -lpcre -Wl,--end-group
  /usr/bin/ld: cannot find -lcapstone
  collect2: error: ld returned 1 exit status
  ninja: build stopped: subcommand failed.
  make: *** [Makefile:172: run-ninja] Error 1

  $ rpm -ql capstone-devel
  /usr/include/capstone
  /usr/include/capstone/arm.h
  /usr/include/capstone/arm64.h
  /usr/include/capstone/capstone.h
  /usr/include/capstone/evm.h
  /usr/include/capstone/m680x.h
  /usr/include/capstone/m68k.h
  /usr/include/capstone/mips.h
  /usr/include/capstone/platform.h
  /usr/include/capstone/ppc.h
  /usr/include/capstone/sparc.h
  /usr/include/capstone/systemz.h
  /usr/include/capstone/tms320c64x.h
  /usr/include/capstone/x86.h
  /usr/include/capstone/xcore.h
  /usr/lib64/libcapstone.so
  /usr/lib64/pkgconfig/capstone.pc

  libcapstone.a seems detected by Meson but is not installed on the
  system (Fedora 32).

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

[Bug 1914748] Re: Confuse error message when KVM can not start requested CPU

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/239


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #239
   https://gitlab.com/qemu-project/qemu/-/issues/239

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

Title:
  Confuse error message when KVM can not start requested CPU

Status in QEMU:
  Invalid

Bug description:
  As of commit 1ba089f2255, on Cavium CN8890 (ThunderX cores):

  $ qemu-system-aarch64 -display none -accel kvm -M virt,gic-version=3 -accel 
kvm -cpu cortex-a57 --trace \*kvm_vcpu\*  
  kvm_vcpu_ioctl cpu_index 0, type 0x4020aeae, arg 0x9b7f9b18 
  qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid 
argument

  (same using "-cpu cortex-a53" or cortex-a72).

  Explanation from Peter Maydell on IRC:
  > using a specific cpu type will only work with KVM if the host CPU really is 
that
  > exact CPU type, otherwise, use "-cpu host" or "-cpu max"

  Having a better error description would help to understand the reason.

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

[Bug 1881249] Re: CPU fetch from unpopulated ROM on reset

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/236


** Changed in: qemu
   Status: Confirmed => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #236
   https://gitlab.com/qemu-project/qemu/-/issues/236

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

Title:
  CPU fetch from unpopulated ROM on reset

Status in QEMU:
  Invalid

Bug description:
  Some architectures fetch the $PC/$SP register as vectors in memory, usually 
ROM.
  The CPU reset() handler is called before the ROM code is populated, resulting 
in fetching incorrect PC/SP.

  Architectures affected:
  - M68K
  - RX
  - ARM M-profile

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

[Bug 1910505] Re: atomic failure linking with --enable-sanitizers on 32-bit Linux hosts

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/235


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #235
   https://gitlab.com/qemu-project/qemu/-/issues/235

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

Title:
  atomic failure linking with --enable-sanitizers on 32-bit Linux hosts

Status in QEMU:
  Invalid

Bug description:
  As of commit 50536341b47, using --enable-sanitizers on 32-bit Linux host:
  - displays various warnings
  - fails linking

  Using Ubuntu 18.04 (release 20201211.1) and Clang10 on i386:

  [139/675] Compiling C object softmmu.fa.p/softmmu_icount.c.o
  In file included from ../softmmu/icount.c:31:
  In file included from include/exec/exec-all.h:23:
  In file included from ../target/mips/cpu.h:4:
  In file included from ../target/mips/cpu-qom.h:23:
  In file included from include/hw/core/cpu.h:23:
  In file included from include/hw/qdev-core.h:5:
  In file included from include/qemu/bitmap.h:16:
  In file included from include/qemu/bitops.h:17:
  include/qemu/atomic.h:463:12: warning: misaligned atomic operation may
  incur significant performance penalty [-Watomic-alignment]
  return qatomic_read__nocheck(ptr);
 ^
  include/qemu/atomic.h:129:5: note: expanded from macro
  'qatomic_read__nocheck'
  __atomic_load_n(ptr, __ATOMIC_RELAXED)
  ^
  include/qemu/atomic.h:473:5: warning: misaligned atomic operation may
  incur significant performance penalty [-Watomic-alignment]
  qatomic_set__nocheck(ptr, val);
  ^
  include/qemu/atomic.h:138:5: note: expanded from macro
  'qatomic_set__nocheck'
  __atomic_store_n(ptr, i, __ATOMIC_RELAXED)
  ^
  2 warnings generated.
  [...]

  [850/2216] Linking target tests/test-hbitmap
  FAILED: tests/test-hbitmap
  clang  -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o
  tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined
  -pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa
  libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined
  -fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb
  -fstack-protector-strong -Wl,--start-group libqemuutil.a
  subprojects/libvhost-user/libvhost-user-glib.a
  subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa
  libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0
  -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls
  -lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so
  -liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl
  /usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls
  -Wl,--end-group
  libblock.fa(block_io.c.o): In function `stat64_max':
  include/qemu/stats64.h:58: undefined reference to `__atomic_load_8'
  include/qemu/stats64.h:60: undefined reference to
  `__atomic_compare_exchange_8'
  libblock.fa(block_qapi.c.o): In function `stat64_get':
  include/qemu/stats64.h:40: undefined reference to `__atomic_load_8'
  libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64':
  include/qemu/atomic.h:478: undefined reference to `__atomic_store_8'
  libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64':
  include/qemu/atomic.h:468: undefined reference to `__atomic_load_8'
  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)

  Issue previously reported on the list here:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg770128.html

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

[Bug 1879646] Re: [Feature request] x86: dump MSR features in human form

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/237


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #237
   https://gitlab.com/qemu-project/qemu/-/issues/237

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

Title:
  [Feature request] x86: dump MSR features in human form

Status in QEMU:
  Invalid

Bug description:
  QEMU might fail because host/guest cpu features are not properly
  configured:

  qemu-system-x86_64: error: failed to set MSR 0x48f to 0x7fefff00036dfb
  qemu-system-x86_64: /root/qemu-master/target/i386/kvm.c:2695:
  kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.

  To ease debugging, it the MSR features bit could be dumped.

  Example in this thread:

  https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05593.html

The high 32 bits are 0111  1110   .

The low 32 bits are   0011 0110 1101  1011.

The features that are set are the xor, so 0111 1100 1000 0010 
  0100:

- bit 2, vmx-exit-nosave-debugctl
- bit 9, host address space size, is handled automatically by QEMU
- bit 15, vmx-exit-ack-intr
- bit 17, vmx-exit-save-pat
- bit 18, vmx-exit-load-pat
- bit 19, vmx-exit-save-efer
- bit 20, vmx-exit-load-efer
- bit 21, vmx-exit-save-preemption-timer

  This output ^^^ is easier to digest.

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

[Bug 1925449] Re: Failure building with clang-10 and libssh

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/234


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #234
   https://gitlab.com/qemu-project/qemu/-/issues/234

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

Title:
  Failure building with clang-10 and libssh

Status in QEMU:
  Invalid

Bug description:
  On Fedora 32, configuring with --enable-libssh and building with
  clang:

  qemu 5.2.94

Compilation
  host CPU : x86_64
  host endianness  : little
  C compiler   : clang-10
  Host C compiler  : clang-10

Dependencies
  libssh support   : YES

  triggers:

  FAILED: libblock.fa.p/block_ssh.c.o 
  block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated 
[-Werror,-Wdeprecated-declarations]
  state = ssh_is_server_known(s->session);
  ^
  /usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been 
explicitly marked deprecated here
  SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session);
  ^
  /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
  #define SSH_DEPRECATED __attribute__ ((deprecated))
 ^
  block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated 
[-Werror,-Wdeprecated-declarations]
  r = ssh_get_publickey(s->session, );
  ^
  /usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been 
explicitly marked deprecated here
  SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key 
*key);
  ^
  /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
  #define SSH_DEPRECATED __attribute__ ((deprecated))
 ^
  2 errors generated.

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/233


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #233
   https://gitlab.com/qemu-project/qemu/-/issues/233

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

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Invalid

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for 
Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable 
material.

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

[Bug 1836762] Re: Many leaks from qemu_spice_create_update

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/231


** Changed in: qemu
   Status: Incomplete => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #231
   https://gitlab.com/qemu-project/qemu/-/issues/231

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

Title:
  Many leaks from qemu_spice_create_update

Status in QEMU:
  Invalid

Bug description:
  tag: v4.1.0-rc0

  Compiled with --enable-sanitizers

  $ qemu-system-x86_64 -device qxl-vga ...
  [guest exits calling 'hlt']
  ==20452==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 167616 byte(s) in 582 object(s) allocated from:
  #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
  #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
  #2 0x561148c6d547 in qemu_spice_create_update 
qemu/ui/spice-display.c:222:21
  #3 0x561148c6ba2b in qemu_spice_display_refresh 
qemu/ui/spice-display.c:488:9
  #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
  #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
  #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
  #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
  #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
  #9 0x56114955a489 in qemu_clock_run_all_timers 
qemu/util/qemu-timer.c:708:25
  #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
  #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
  #12 0x561147c4976d in main qemu/vl.c:4473:5
  #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)

  Direct leak of 5184 byte(s) in 18 object(s) allocated from:
  #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
  #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
  #2 0x561148c6e3e7 in qemu_spice_create_update 
qemu/ui/spice-display.c:243:13
  #3 0x561148c6ba2b in qemu_spice_display_refresh 
qemu/ui/spice-display.c:488:9
  #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
  #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
  #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
  #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
  #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
  #9 0x56114955a489 in qemu_clock_run_all_timers 
qemu/util/qemu-timer.c:708:25
  #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
  #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
  #12 0x561147c4976d in main qemu/vl.c:4473:5
  #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)

  Direct leak of 2560 byte(s) in 4 object(s) allocated from:
  #0 0x561146f2cb46 in realloc (x86_64-softmmu/qemu-system-x86_64+0x1824b46)
  #1 0x7f73ac04c420  (/lib64/libfontconfig.so.1+0x21420)

  Direct leak of 22 byte(s) in 1 object(s) allocated from:
  #0 0x561146f2c6af in __interceptor_malloc 
(x86_64-softmmu/qemu-system-x86_64+0x18246af)
  #1 0x7f73ae781953 in XGetAtomName (/lib64/libX11.so.6+0x2a953)

  Indirect leak of 54936 byte(s) in 510 object(s) allocated from:
  #0 0x561146f2c6af in __interceptor_malloc 
(x86_64-softmmu/qemu-system-x86_64+0x18246af)
  #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5)
  #2 0x561148c6d547 in qemu_spice_create_update 
qemu/ui/spice-display.c:222:21
  #3 0x561148c6ba2b in qemu_spice_display_refresh 
qemu/ui/spice-display.c:488:9
  #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
  #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
  #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
  #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
  #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
  #9 0x56114955a489 in qemu_clock_run_all_timers 
qemu/util/qemu-timer.c:708:25
  #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
  #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
  #12 0x561147c4976d in main qemu/vl.c:4473:5
  #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)

  Indirect leak of 30720 byte(s) in 23 object(s) allocated from:
  #0 0x561146f2c6af in __interceptor_malloc 
(x86_64-softmmu/qemu-system-x86_64+0x18246af)
  #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5)
  #2 0x561148c6e3e7 in qemu_spice_create_update 
qemu/ui/spice-display.c:243:13
  #3 0x561148c6ba2b in qemu_spice_display_refresh 
qemu/ui/spice-display.c:488:9
  #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
  #5 

[Bug 1880539] Re: I/O write make QXL abort in qxl_set_mode()

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/232


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #232
   https://gitlab.com/qemu-project/qemu/-/issues/232

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

Title:
  I/O write make QXL abort in qxl_set_mode()

Status in QEMU:
  Invalid

Bug description:
  libFuzzer found:

  qxl-0: guest bug: qxl_add_memslot: guest_start > guest_end 0x 
> 0x3ff
  qemu-fuzz-i386: hw/display/qxl.c:1611: void qxl_set_mode(PCIQXLDevice *, 
unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0' 
failed.
  ==8134== ERROR: libFuzzer: deadly signal
  #0 0x55fddfcfb3f0 in __sanitizer_print_stack_trace 
(qemu-fuzz-i386+0xcb13f0)
  #1 0x55fddfc0a3e1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0xbc03e1)
  #2 0x55fddfbeac6f in fuzzer::Fuzzer::CrashCallback() 
(qemu-fuzz-i386+0xba0c6f)
  #3 0x55fddfbeacc3 in fuzzer::Fuzzer::StaticCrashSignalCallback() 
(qemu-fuzz-i386+0xba0cc3)
  #4 0x7fd640644c6f  (/lib64/libpthread.so.0+0x12c6f)
  #5 0x7fd640483e34 in __GI_raise (/lib64/libc.so.6+0x37e34)
  #6 0x7fd64046e894 in __GI_abort (/lib64/libc.so.6+0x22894)
  #7 0x7fd64046e768 in __assert_fail_base.cold (/lib64/libc.so.6+0x22768)
  #8 0x7fd64047c565 in __GI___assert_fail (/lib64/libc.so.6+0x30565)
  #9 0x55fde08afd8b in qxl_set_mode (qemu-fuzz-i386+0x1865d8b)
  #10 0x55fde08b9602 in ioport_write (qemu-fuzz-i386+0x186f602)
  #11 0x55fddff170a7 in memory_region_write_accessor 
(qemu-fuzz-i386+0xecd0a7)
  #12 0x55fddff16c13 in access_with_adjusted_size (qemu-fuzz-i386+0xeccc13)
  #13 0x55fddff157b4 in memory_region_dispatch_write 
(qemu-fuzz-i386+0xecb7b4)

  Can be reproduce doing "writeb 0x06 0x23" on QXL I/O (PCI BAR #3).

  Command line: 'qemu-system-i386 -display none -M pc -vga qxl'

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

[Bug 1887820] Re: TCG test targets missing from 'make check-help'

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/228


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #228
   https://gitlab.com/qemu-project/qemu/-/issues/228

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

Title:
  TCG test targets missing from 'make check-help'

Status in QEMU:
  Invalid

Bug description:
  We can run the TCG tests using:

  $ make run-tcg-tests-$TARGET-softmmu

  This is not listed in 'make check-help'.

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

[Bug 1919021] Re: Confuse error message in virtio_init_region_cache()

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/230


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #230
   https://gitlab.com/qemu-project/qemu/-/issues/230

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

Title:
  Confuse error message in virtio_init_region_cache()

Status in QEMU:
  Invalid

Bug description:
  The error message added in commit e45da653223 to virtio_init_region_cache()
  are somehow confuse:

qemu-system-i386: Cannot map used

  It would be helpful to more explicit string, including "virtio"
  prefix.

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

[Bug 1920767] Re: build-tools-and-docs-debian job waste cycles building pointless things

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/229


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #229
   https://gitlab.com/qemu-project/qemu/-/issues/229

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

Title:
  build-tools-and-docs-debian job waste cycles building pointless things

Status in QEMU:
  Invalid

Bug description:
  The build-tools-and-docs-debian job waste CI cycles building softfloat:
  https://gitlab.com/qemu-project/qemu/-/jobs/1117005759

  Possible fix suggested on the list:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg793872.html

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

[Bug 1893744] Re: meson: incomplete 'make help'

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/227


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #227
   https://gitlab.com/qemu-project/qemu/-/issues/227

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

Title:
  meson: incomplete 'make help'

Status in QEMU:
  Invalid

Bug description:
  Since the meson switch, 'make help' doesn't list various targets.

  Diff before/after:

  ---
   Generic targets:
 all- Build all
 dir/file.o - Build specified target only
 install- Install QEMU
 ctags/TAGS - Generate tags file for editors
 cscope - Generate cscope index
  -
  -Architecture specific targets:
  -  aarch64-softmmu/all- Build for aarch64-softmmu
  -  alpha-softmmu/all  - Build for alpha-softmmu
  -  arm-softmmu/all- Build for arm-softmmu
  -  avr-softmmu/all- Build for avr-softmmu
  -  cris-softmmu/all   - Build for cris-softmmu
  -  hppa-softmmu/all   - Build for hppa-softmmu
  -  i386-softmmu/all   - Build for i386-softmmu
  -  lm32-softmmu/all   - Build for lm32-softmmu
  -  m68k-softmmu/all   - Build for m68k-softmmu
  -  microblazeel-softmmu/all   - Build for microblazeel-softmmu
  -  microblaze-softmmu/all - Build for microblaze-softmmu
  -  mips64el-softmmu/all   - Build for mips64el-softmmu
  -  mips64-softmmu/all - Build for mips64-softmmu
  -  mipsel-softmmu/all - Build for mipsel-softmmu
  -  mips-softmmu/all   - Build for mips-softmmu
  -  moxie-softmmu/all  - Build for moxie-softmmu
  -  nios2-softmmu/all  - Build for nios2-softmmu
  -  or1k-softmmu/all   - Build for or1k-softmmu
  -  ppc64-softmmu/all  - Build for ppc64-softmmu
  -  ppc-softmmu/all- Build for ppc-softmmu
  -  riscv32-softmmu/all- Build for riscv32-softmmu
  -  riscv64-softmmu/all- Build for riscv64-softmmu
  -  rx-softmmu/all - Build for rx-softmmu
  -  s390x-softmmu/all  - Build for s390x-softmmu
  -  sh4eb-softmmu/all  - Build for sh4eb-softmmu
  -  sh4-softmmu/all- Build for sh4-softmmu
  -  sparc64-softmmu/all- Build for sparc64-softmmu
  -  sparc-softmmu/all  - Build for sparc-softmmu
  -  tricore-softmmu/all- Build for tricore-softmmu
  -  unicore32-softmmu/all  - Build for unicore32-softmmu
  -  x86_64-softmmu/all - Build for x86_64-softmmu
  -  xtensaeb-softmmu/all   - Build for xtensaeb-softmmu
  -  xtensa-softmmu/all - Build for xtensa-softmmu
  -  aarch64_be-linux-user/all  - Build for aarch64_be-linux-user
  -  aarch64-linux-user/all - Build for aarch64-linux-user
  -  alpha-linux-user/all   - Build for alpha-linux-user
  -  armeb-linux-user/all   - Build for armeb-linux-user
  -  arm-linux-user/all - Build for arm-linux-user
  -  cris-linux-user/all- Build for cris-linux-user
  -  hppa-linux-user/all- Build for hppa-linux-user
  -  i386-linux-user/all- Build for i386-linux-user
  -  m68k-linux-user/all- Build for m68k-linux-user
  -  microblazeel-linux-user/all- Build for microblazeel-linux-user
  -  microblaze-linux-user/all  - Build for microblaze-linux-user
  -  mips64el-linux-user/all- Build for mips64el-linux-user
  -  mips64-linux-user/all  - Build for mips64-linux-user
  -  mipsel-linux-user/all  - Build for mipsel-linux-user
  -  mips-linux-user/all- Build for mips-linux-user
  -  mipsn32el-linux-user/all   - Build for mipsn32el-linux-user
  -  mipsn32-linux-user/all - Build for mipsn32-linux-user
  -  nios2-linux-user/all   - Build for nios2-linux-user
  -  or1k-linux-user/all- Build for or1k-linux-user
  -  ppc64abi32-linux-user/all  - Build for ppc64abi32-linux-user
  -  ppc64le-linux-user/all - Build for ppc64le-linux-user
  -  ppc64-linux-user/all   - Build for ppc64-linux-user
  -  ppc-linux-user/all - Build for ppc-linux-user
  -  riscv32-linux-user/all - Build for riscv32-linux-user
  -  riscv64-linux-user/all - Build for riscv64-linux-user
  -  s390x-linux-user/all   - Build for s390x-linux-user
  -  sh4eb-linux-user/all   - Build for sh4eb-linux-user
  -  sh4-linux-user/all - Build for 

[Bug 1831225] Re: guest migration 100% cpu freeze bug

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/223


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #223
   https://gitlab.com/qemu-project/qemu/-/issues/223

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

Title:
  guest migration 100% cpu freeze bug

Status in QEMU:
  Expired

Bug description:
  # Investigate migration cpu hog(100%) bug

  I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to 
kernel 4.19.43 running qemu 2.11.2.
  The hypervisors are running on debian jessie with libvirt v5.3.0.
  Linux, libvirt and qemu are all custom compiled.

  I migrated around 10.000 vms and every once in a while a vm is stuck
  at 100% cpu after what we can see right now is that the target
  hypervisor runs on linux 4.19.53. This happened with 4 vms so far. It
  is not that easy to debug, we found this out pretty quickly because we
  are running monitoring on frozen vms after migrations.

  Last year we were having the same "kind of" bug 
https://bugs.launchpad.net/qemu/+bug/177 when trying to upgrade qemu 2.6 to 
2.11.
  This bug was fixed after applying the following patch: 
http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html

  This patch is still applied as you can see because of the available pre_load 
var on the kvmclock_vmsd struct:
  (gdb) ptype kvmclock_vmsd
  type = const struct VMStateDescription {
  const char *name;
  int unmigratable;
  int version_id;
  int minimum_version_id;
  int minimum_version_id_old;
  MigrationPriority priority;
  LoadStateHandler *load_state_old;
  int (*pre_load)(void *);
  int (*post_load)(void *, int);
  int (*pre_save)(void *);
  _Bool (*needed)(void *);
  VMStateField *fields;
  const VMStateDescription **subsections;
  }

  I attached gdb to a vcpu thread of one stuck vm, and a bt showed the 
following info:
  Thread 4 (Thread 0x7f3a431a4700 (LWP 37799)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fca78d0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a431a4700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  Thread 3 (Thread 0x7f3a439a5700 (LWP 37798)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fc5cbb0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a439a5700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping
  inside the vm itself.

  I saved the state of the VM (with `virsh save`) after I found it was hanging 
on its vcpu threads. Then I restored this vm on a test environment running the 
same kernel, QEMU and libvirt version). After the restore the VM still was 
haning at 100% cpu usage on all the vcpus.
  I tried to use the perf kvm guest option to trace the guest vm with a copy of 
the kernel, modules and kallsyms files from inside the guest vm and I got to 
the following perf stat:

   Event Total %Total CurAvg/s
   kvm_entry   5198993   23.1   277007
   kvm_exit5198976   23.1   277006
   kvm_apic17321037.792289
   kvm_msr 17321017.792289
   kvm_inj_virq17319047.792278
   kvm_eoi 17319007.792278
   kvm_apic_accept_irq 17319007.792278
   kvm_hv_timer_state  17317807.792274
   kvm_pv_eoi  17317017.792267
   

[Bug 1839367] Re: Wrong interrupts generated for I.MX6 FEC controller

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/224


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #224
   https://gitlab.com/qemu-project/qemu/-/issues/224

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

Title:
  Wrong interrupts generated for I.MX6 FEC controller

Status in QEMU:
  Expired

Bug description:
  The imx_eth_update function in hw/net/imx_fec.c has the following
  comment
  
(https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445):

  /*
   * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC
   * interrupts swapped. This worked with older versions of Linux (4.14
   * and older) since Linux associated both interrupt lines with Ethernet
   * MAC interrupts. Specifically,
   * - Linux 4.15 and later have separate interrupt handlers for the MAC and
   *   timer interrupts. Those versions of Linux fail with versions of QEMU
   *   with swapped interrupt assignments.
   * - In linux 4.14, both interrupt lines were registered with the Ethernet
   *   MAC interrupt handler. As a result, all versions of qemu happen to
   *   work, though that is accidental.
   * - In Linux 4.9 and older, the timer interrupt was registered directly
   *   with the Ethernet MAC interrupt handler. The MAC interrupt was
   *   redirected to a GPIO interrupt to work around erratum ERR006687.
   *   This was implemented using the SOC's IOMUX block. In qemu, this GPIO
   *   interrupt never fired since IOMUX is currently not supported in qemu.
   *   Linux instead received MAC interrupts on the timer interrupt.
   *   As a result, qemu versions with the swapped interrupt assignment 
work,
   *   albeit accidentally, but qemu versions with the correct interrupt
   *   assignment fail.
   *
   * To ensure that all versions of Linux work, generate ENET_INT_MAC
   * interrrupts on both interrupt lines. This should be changed if and when
   * qemu supports IOMUX.
   */

  Unfortunately, this behavior causes the QNX Sabrelite BSP
  (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet
  initialization. This is caused by the fact that QEMU is firing the
  ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC
  flag is set). The BSP functions correctly on the actual hardware, but
  it is unable to handle the deliberately incorrect interrupt firing by
  QEMU.

  From reading the comment, it appears that this behavior is necessary
  to support certain versions of Linux. However, it would be very useful
  to be able to restore the correct interrupt behavior (possibly via a
  command-line flag).

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

[Bug 1808565] Re: Reading /proc/self/task//maps is not remapped to the target

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/222


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #222
   https://gitlab.com/qemu-project/qemu/-/issues/222

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

Title:
  Reading /proc/self/task//maps is not remapped to the target

Status in QEMU:
  Expired

Bug description:
  Seeing this in qemu-user 3.1.0

  The code in is_proc_myself which supports remapping of /proc/self/maps
  and /proc//maps does not support remapping of
  /proc/self/task//maps or /proc//task//maps. Extending
  is_proc_myself to cover these cases causes the maps to be rewritten
  correctly.

  These are useful in multithreaded programs to avoid freezing the
  entire program to capture the maps for a single tid.

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

[Bug 1859254] Re: host window size does not change when guest video screen size changes while moving host window

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/226


** Changed in: qemu
   Status: New => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #226
   https://gitlab.com/qemu-project/qemu/-/issues/226

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

Title:
  host window size does not change when guest video screen size changes
  while moving host window

Status in QEMU:
  Expired

Bug description:
  When QEMU is emulating a legacy text mode, then switches to a VESA
  mode, if you happen to be moving the host window while the switch is
  made, the host window never changes size.  The emulated size does, but
  the host window doesn't.

  For example, at Legacy boot up, the screen mode is mode 03 at 80x25.
  Then when the GUEST OS changes the screen to a VESA mode, say
  1024x768x16, normally the host window will change to that size to
  accommodate the new emulated screen size.

  However, if you happen to be moving the host window at the time of the
  screen mode change, the host window doesn't change in size to
  accommodate the new screen size.

  I am using:
QEMU for Windows, version 4.1.0-11789
Host: Windows 10 (latest updates)
Emulating: Intel x64, Legacy BIOS
  Command line:
  "c:\program files\qemu\qemu-system-x86_64.exe" -m 256 -drive 
file=C:\fysos64.img,format=raw,if=ide,media=disk,index=0 -parallel 
file:para.txt -boot c -d guest_errors -vga std -smp cpus=4 -rtc 
base=localtime,clock=host,driftfix=slew -net none -monitor stdio

  I tried different -vga settings:
 -vga std
 -vga cirrus
 -vga vmware
  Each did the same thing.

  [ Side note (possible error in documentation):
  [  at: https://qemu.weilnetz.de/doc/qemu-doc.html#SVGA-graphic-modes-support
  [  end of 2.16.2.1
  [  (option -std-vga)
  [possibly should be
  [  (option -vga std)

  If you need an image to test with, I have been using
  www.fysnet.net/temp/fysos64.zip (2meg zipped/10meg raw).  It starts in
  Legacy BIOS/Hardware mode 3, then switches to VESA 1024x768x16 within
  a few seconds, so be ready to move the HOST window when the mode
  changes.

  I do not have a Linux box to test with, so unknown if this is only an
  issue with the Windows version or not.

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

Re: [PATCH 0/9] accel/tcg: Add tlb_flush interface for a range of pages

[Philippe Mathieu-Daudé]

Oops, I forgot to add 'v2' in subject line :/

On Sun, May 9, 2021 at 5:16 PM Philippe Mathieu-Daudé  wrote:
>
> Hi Richard,
>
> I tried to make sense of the multiple changes in your patch
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg805595.html
> by splitting it in multiple trivial changes. At least this way
> it is easier to me to follow / review what you did.
>
> The original patch description was:
>
>   Add tlb_flush interface for a range of pages.
>   Call these tlb_flush_range_by_mmuidx*.
>   Rewrite the_flush_page_bits_by_mmuidx* to use the new
>   functions, passing in TARGET_PAGE_SIZE for length.
>
> If you find it useful, fill free to take / respin / reorder this
> series, improving descriptions.  Last patch certainly deserves a
> better description ;)

[Bug 1854204] Re: Menu is not clickable on OSX Catalina

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/225


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #225
   https://gitlab.com/qemu-project/qemu/-/issues/225

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

Title:
  Menu is not clickable on OSX Catalina

Status in QEMU:
  Expired

Bug description:
  1) Run `qemu-system-x86_64`
  2) Try to click on the main menu

  Menu is not clickable until another window is activated and QEMU
  window is activated again

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

[PATCH 9/9] accel/tcg: Remove tlb_flush_page_bits_by_mmuidx_async_1() ???

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Now than ... /* we use range? FILL ME... */ ... we can remove the
encode_pbm_to_runon() and flush_all_helper() calls.

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
XXX proper description, commit might be placed earlier in series.
---
 accel/tcg/cputlb.c | 86 +++---
 1 file changed, 20 insertions(+), 66 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index ad0e44bce63..2f7088614a7 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -788,34 +788,6 @@ static void tlb_flush_range_by_mmuidx_async_0(CPUState 
*cpu,
 }
 }
 
-static bool encode_pbm_to_runon(run_on_cpu_data *out,
-TLBFlushRangeData d)
-{
-/* We need 6 bits to hold to hold @bits up to 63. */
-if (d.idxmap <= MAKE_64BIT_MASK(0, TARGET_PAGE_BITS - 6)) {
-*out = RUN_ON_CPU_TARGET_PTR(d.addr | (d.idxmap << 6) | d.bits);
-return true;
-}
-return false;
-}
-
-static TLBFlushRangeData
-decode_runon_to_pbm(run_on_cpu_data data)
-{
-target_ulong addr_map_bits = (target_ulong) data.target_ptr;
-return (TLBFlushRangeData){
-.addr = addr_map_bits & TARGET_PAGE_MASK,
-.idxmap = (addr_map_bits & ~TARGET_PAGE_MASK) >> 6,
-.bits = addr_map_bits & 0x3f
-};
-}
-
-static void tlb_flush_page_bits_by_mmuidx_async_1(CPUState *cpu,
-  run_on_cpu_data runon)
-{
-tlb_flush_range_by_mmuidx_async_0(cpu, decode_runon_to_pbm(runon));
-}
-
 static void tlb_flush_range_by_mmuidx_async_1(CPUState *cpu,
   run_on_cpu_data data)
 {
@@ -829,7 +801,6 @@ void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong 
addr,
unsigned bits)
 {
 TLBFlushRangeData d;
-run_on_cpu_data runon;
 
 /*
  * If all bits are significant, and len is small,
@@ -853,8 +824,6 @@ void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong 
addr,
 
 if (qemu_cpu_is_self(cpu)) {
 tlb_flush_range_by_mmuidx_async_0(cpu, d);
-} else if (encode_pbm_to_runon(, d)) {
-async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_1, runon);
 } else {
 /* Otherwise allocate a structure, freed by the worker.  */
 TLBFlushRangeData *p = g_memdup(, sizeof(d));
@@ -874,7 +843,7 @@ void tlb_flush_range_by_mmuidx_all_cpus(CPUState *src_cpu,
 uint16_t idxmap, unsigned bits)
 {
 TLBFlushRangeData d;
-run_on_cpu_data runon;
+CPUState *dst_cpu;
 
 /*
  * If all bits are significant, and len is small,
@@ -896,19 +865,13 @@ void tlb_flush_range_by_mmuidx_all_cpus(CPUState *src_cpu,
 d.idxmap = idxmap;
 d.bits = bits;
 
-if (encode_pbm_to_runon(, d)) {
-flush_all_helper(src_cpu, tlb_flush_page_bits_by_mmuidx_async_1, 
runon);
-} else {
-CPUState *dst_cpu;
-
-/* Allocate a separate data block for each destination cpu.  */
-CPU_FOREACH(dst_cpu) {
-if (dst_cpu != src_cpu) {
-TLBFlushRangeData *p = g_memdup(, sizeof(d));
-async_run_on_cpu(dst_cpu,
- tlb_flush_range_by_mmuidx_async_1,
- RUN_ON_CPU_HOST_PTR(p));
-}
+/* Allocate a separate data block for each destination cpu.  */
+CPU_FOREACH(dst_cpu) {
+if (dst_cpu != src_cpu) {
+TLBFlushRangeData *p = g_memdup(, sizeof(d));
+async_run_on_cpu(dst_cpu,
+ tlb_flush_range_by_mmuidx_async_1,
+ RUN_ON_CPU_HOST_PTR(p));
 }
 }
 
@@ -929,8 +892,8 @@ void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
uint16_t idxmap,
unsigned bits)
 {
-TLBFlushRangeData d;
-run_on_cpu_data runon;
+TLBFlushRangeData d, *p;
+CPUState *dst_cpu;
 
 /*
  * If all bits are significant, and len is small,
@@ -952,27 +915,18 @@ void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
 d.idxmap = idxmap;
 d.bits = bits;
 
-if (encode_pbm_to_runon(, d)) {
-flush_all_helper(src_cpu, tlb_flush_page_bits_by_mmuidx_async_1, 
runon);
-async_safe_run_on_cpu(src_cpu, tlb_flush_page_bits_by_mmuidx_async_1,
-  runon);
-} else {
-CPUState *dst_cpu;
-TLBFlushRangeData *p;
-
-/* Allocate a separate data block for each destination cpu.  */
-CPU_FOREACH(dst_cpu) {
-if (dst_cpu != src_cpu) {
-p = g_memdup(, sizeof(d));
-async_run_on_cpu(dst_cpu, tlb_flush_range_by_mmuidx_async_1,
- 

[PATCH 8/9] accel/tlb: Rename tlb_flush_[page_bits > range]_by_mmuidx_async_[2 > 1]

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/cputlb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 47c83f0fc83..ad0e44bce63 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -816,8 +816,8 @@ static void tlb_flush_page_bits_by_mmuidx_async_1(CPUState 
*cpu,
 tlb_flush_range_by_mmuidx_async_0(cpu, decode_runon_to_pbm(runon));
 }
 
-static void tlb_flush_page_bits_by_mmuidx_async_2(CPUState *cpu,
-  run_on_cpu_data data)
+static void tlb_flush_range_by_mmuidx_async_1(CPUState *cpu,
+  run_on_cpu_data data)
 {
 TLBFlushRangeData *d = data.host_ptr;
 tlb_flush_range_by_mmuidx_async_0(cpu, *d);
@@ -858,7 +858,7 @@ void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong 
addr,
 } else {
 /* Otherwise allocate a structure, freed by the worker.  */
 TLBFlushRangeData *p = g_memdup(, sizeof(d));
-async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_2,
+async_run_on_cpu(cpu, tlb_flush_range_by_mmuidx_async_1,
  RUN_ON_CPU_HOST_PTR(p));
 }
 }
@@ -906,7 +906,7 @@ void tlb_flush_range_by_mmuidx_all_cpus(CPUState *src_cpu,
 if (dst_cpu != src_cpu) {
 TLBFlushRangeData *p = g_memdup(, sizeof(d));
 async_run_on_cpu(dst_cpu,
- tlb_flush_page_bits_by_mmuidx_async_2,
+ tlb_flush_range_by_mmuidx_async_1,
  RUN_ON_CPU_HOST_PTR(p));
 }
 }
@@ -964,13 +964,13 @@ void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
 CPU_FOREACH(dst_cpu) {
 if (dst_cpu != src_cpu) {
 p = g_memdup(, sizeof(d));
-async_run_on_cpu(dst_cpu, 
tlb_flush_page_bits_by_mmuidx_async_2,
+async_run_on_cpu(dst_cpu, tlb_flush_range_by_mmuidx_async_1,
  RUN_ON_CPU_HOST_PTR(p));
 }
 }
 
 p = g_memdup(, sizeof(d));
-async_safe_run_on_cpu(src_cpu, tlb_flush_page_bits_by_mmuidx_async_2,
+async_safe_run_on_cpu(src_cpu, tlb_flush_range_by_mmuidx_async_1,
   RUN_ON_CPU_HOST_PTR(p));
 }
 }
-- 
2.26.3

[PATCH 7/9] accel/tcg: Rename tlb_flush_page_bits -> range]_by_mmuidx_async_0

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/cputlb.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index bc4370f4e21..47c83f0fc83 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -764,9 +764,8 @@ typedef struct {
 uint16_t bits;
 } TLBFlushRangeData;
 
-static void
-tlb_flush_page_bits_by_mmuidx_async_0(CPUState *cpu,
-  TLBFlushRangeData d)
+static void tlb_flush_range_by_mmuidx_async_0(CPUState *cpu,
+  TLBFlushRangeData d)
 {
 CPUArchState *env = cpu->env_ptr;
 int mmu_idx;
@@ -814,14 +813,14 @@ decode_runon_to_pbm(run_on_cpu_data data)
 static void tlb_flush_page_bits_by_mmuidx_async_1(CPUState *cpu,
   run_on_cpu_data runon)
 {
-tlb_flush_page_bits_by_mmuidx_async_0(cpu, decode_runon_to_pbm(runon));
+tlb_flush_range_by_mmuidx_async_0(cpu, decode_runon_to_pbm(runon));
 }
 
 static void tlb_flush_page_bits_by_mmuidx_async_2(CPUState *cpu,
   run_on_cpu_data data)
 {
 TLBFlushRangeData *d = data.host_ptr;
-tlb_flush_page_bits_by_mmuidx_async_0(cpu, *d);
+tlb_flush_range_by_mmuidx_async_0(cpu, *d);
 g_free(d);
 }
 
@@ -853,7 +852,7 @@ void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong 
addr,
 d.bits = bits;
 
 if (qemu_cpu_is_self(cpu)) {
-tlb_flush_page_bits_by_mmuidx_async_0(cpu, d);
+tlb_flush_range_by_mmuidx_async_0(cpu, d);
 } else if (encode_pbm_to_runon(, d)) {
 async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_1, runon);
 } else {
@@ -913,7 +912,7 @@ void tlb_flush_range_by_mmuidx_all_cpus(CPUState *src_cpu,
 }
 }
 
-tlb_flush_page_bits_by_mmuidx_async_0(src_cpu, d);
+tlb_flush_range_by_mmuidx_async_0(src_cpu, d);
 }
 
 void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState *src_cpu,
-- 
2.26.3

[PATCH 4/9] accel/tcg: Add tlb_flush_range_by_mmuidx()

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/exec-all.h | 19 +++
 accel/tcg/cputlb.c  | 20 +++-
 2 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 6b036cae8f6..5a5f6d4c1a8 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -262,6 +262,20 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState *cpu, 
target_ulong addr,
 void tlb_flush_page_bits_by_mmuidx_all_cpus_synced
 (CPUState *cpu, target_ulong addr, uint16_t idxmap, unsigned bits);
 
+/**
+ * tlb_flush_range_by_mmuidx
+ * @cpu: CPU whose TLB should be flushed
+ * @addr: virtual address of the start of the range to be flushed
+ * @len: length of range to be flushed
+ * @idxmap: bitmap of mmu indexes to flush
+ * @bits: number of significant bits in address
+ *
+ * For each mmuidx in @idxmap, flush all pages within [@addr,@addr+@len),
+ * comparing only the low @bits worth of each virtual page.
+ */
+void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong addr,
+   target_ulong len, uint16_t idxmap,
+   unsigned bits);
 /**
  * tlb_set_page_with_attrs:
  * @cpu: CPU to add this TLB entry for
@@ -365,6 +379,11 @@ tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState 
*cpu, target_ulong addr,
   uint16_t idxmap, unsigned bits)
 {
 }
+static inline void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong addr,
+ target_ulong len, uint16_t idxmap,
+ unsigned bits)
+{
+}
 #endif
 /**
  * probe_access:
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 36e7831ef70..16924ceb777 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -825,14 +825,18 @@ static void 
tlb_flush_page_bits_by_mmuidx_async_2(CPUState *cpu,
 g_free(d);
 }
 
-void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, target_ulong addr,
-   uint16_t idxmap, unsigned bits)
+void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong addr,
+   target_ulong len, uint16_t idxmap,
+   unsigned bits)
 {
 TLBFlushRangeData d;
 run_on_cpu_data runon;
 
-/* If all bits are significant, this devolves to tlb_flush_page. */
-if (bits >= TARGET_LONG_BITS) {
+/*
+ * If all bits are significant, and len is small,
+ * this devolves to tlb_flush_page.
+ */
+if (bits >= TARGET_LONG_BITS && len <= TARGET_PAGE_SIZE) {
 tlb_flush_page_by_mmuidx(cpu, addr, idxmap);
 return;
 }
@@ -844,7 +848,7 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 
 /* This should already be page aligned */
 d.addr = addr & TARGET_PAGE_MASK;
-d.len = TARGET_PAGE_SIZE;
+d.len = len;
 d.idxmap = idxmap;
 d.bits = bits;
 
@@ -860,6 +864,12 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 }
 }
 
+void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, target_ulong addr,
+   uint16_t idxmap, unsigned bits)
+{
+tlb_flush_range_by_mmuidx(cpu, addr, TARGET_PAGE_SIZE, idxmap, bits);
+}
+
 void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState *src_cpu,
 target_ulong addr,
 uint16_t idxmap,
-- 
2.26.3

[PATCH 5/9] accel/tcg: Add tlb_flush_page_bits_by_mmuidx_all_cpus()

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/exec-all.h | 13 +
 accel/tcg/cputlb.c  | 24 +---
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 5a5f6d4c1a8..9a3dbb7ec08 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -276,6 +276,12 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus_synced
 void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong addr,
target_ulong len, uint16_t idxmap,
unsigned bits);
+
+/* Similarly, with broadcast and syncing. */
+void tlb_flush_range_by_mmuidx_all_cpus(CPUState *cpu, target_ulong addr,
+target_ulong len, uint16_t idxmap,
+unsigned bits);
+
 /**
  * tlb_set_page_with_attrs:
  * @cpu: CPU to add this TLB entry for
@@ -384,6 +390,13 @@ static inline void tlb_flush_range_by_mmuidx(CPUState 
*cpu, target_ulong addr,
  unsigned bits)
 {
 }
+static inline void tlb_flush_range_by_mmuidx_all_cpus(CPUState *cpu,
+  target_ulong addr,
+  target_ulong len,
+  uint16_t idxmap,
+  unsigned bits)
+{
+}
 #endif
 /**
  * probe_access:
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 16924ceb777..5314349ef9d 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -870,16 +870,18 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 tlb_flush_range_by_mmuidx(cpu, addr, TARGET_PAGE_SIZE, idxmap, bits);
 }
 
-void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState *src_cpu,
-target_ulong addr,
-uint16_t idxmap,
-unsigned bits)
+void tlb_flush_range_by_mmuidx_all_cpus(CPUState *src_cpu,
+target_ulong addr, target_ulong len,
+uint16_t idxmap, unsigned bits)
 {
 TLBFlushRangeData d;
 run_on_cpu_data runon;
 
-/* If all bits are significant, this devolves to tlb_flush_page. */
-if (bits >= TARGET_LONG_BITS) {
+/*
+ * If all bits are significant, and len is small,
+ * this devolves to tlb_flush_page.
+ */
+if (bits >= TARGET_LONG_BITS && len <= TARGET_PAGE_SIZE) {
 tlb_flush_page_by_mmuidx_all_cpus(src_cpu, addr, idxmap);
 return;
 }
@@ -891,7 +893,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 
 /* This should already be page aligned */
 d.addr = addr & TARGET_PAGE_MASK;
-d.len = TARGET_PAGE_SIZE;
+d.len = len;
 d.idxmap = idxmap;
 d.bits = bits;
 
@@ -914,6 +916,14 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 tlb_flush_page_bits_by_mmuidx_async_0(src_cpu, d);
 }
 
+void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState *src_cpu,
+target_ulong addr,
+uint16_t idxmap, unsigned bits)
+{
+tlb_flush_range_by_mmuidx_all_cpus(src_cpu, addr, TARGET_PAGE_SIZE,
+   idxmap, bits);
+}
+
 void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
target_ulong addr,
uint16_t idxmap,
-- 
2.26.3

[PATCH 2/9] accel/tcg: Pass length argument to tlb_flush_range_locked()

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Rename tlb_flush_page_bits_locked() -> tlb_flush_range_locked(), and
have callers pass a length argument (currently TARGET_PAGE_SIZE) via
the TLBFlushPageBitsByMMUIdxData structure.

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/cputlb.c | 48 +++---
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index f616b58a898..df5d5dbf879 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -707,8 +707,9 @@ void tlb_flush_page_all_cpus_synced(CPUState *src, 
target_ulong addr)
 tlb_flush_page_by_mmuidx_all_cpus_synced(src, addr, ALL_MMUIDX_BITS);
 }
 
-static void tlb_flush_page_bits_locked(CPUArchState *env, int midx,
-   target_ulong page, unsigned bits)
+static void tlb_flush_range_locked(CPUArchState *env, int midx,
+   target_ulong addr, target_ulong len,
+   unsigned bits)
 {
 CPUTLBDesc *d = _tlb(env)->d[midx];
 CPUTLBDescFast *f = _tlb(env)->f[midx];
@@ -718,20 +719,26 @@ static void tlb_flush_page_bits_locked(CPUArchState *env, 
int midx,
  * If @bits is smaller than the tlb size, there may be multiple entries
  * within the TLB; otherwise all addresses that match under @mask hit
  * the same TLB entry.
- *
  * TODO: Perhaps allow bits to be a few bits less than the size.
  * For now, just flush the entire TLB.
+ *
+ * If @len is larger than the tlb size, then it will take longer to
+ * test all of the entries in the TLB than it will to flush it all.
  */
-if (mask < f->mask) {
+if (mask < f->mask || len > f->mask) {
 tlb_debug("forcing full flush midx %d ("
-  TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
-  midx, page, mask);
+  TARGET_FMT_lx "/" TARGET_FMT_lx "+" TARGET_FMT_lx ")\n",
+  midx, addr, mask, len);
 tlb_flush_one_mmuidx_locked(env, midx, get_clock_realtime());
 return;
 }
 
-/* Check if we need to flush due to large pages.  */
-if ((page & d->large_page_mask) == d->large_page_addr) {
+/*
+ * Check if we need to flush due to large pages.
+ * Because large_page_mask contains all 1's from the msb,
+ * we only need to test the end of the range.
+ */
+if (((addr + len - 1) & d->large_page_mask) == d->large_page_addr) {
 tlb_debug("forcing full flush midx %d ("
   TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
   midx, d->large_page_addr, d->large_page_mask);
@@ -739,14 +746,20 @@ static void tlb_flush_page_bits_locked(CPUArchState *env, 
int midx,
 return;
 }
 
-if (tlb_flush_entry_mask_locked(tlb_entry(env, midx, page), page, mask)) {
-tlb_n_used_entries_dec(env, midx);
+for (target_ulong i = 0; i < len; i += TARGET_PAGE_SIZE) {
+target_ulong page = addr + i;
+CPUTLBEntry *entry = tlb_entry(env, midx, page);
+
+if (tlb_flush_entry_mask_locked(entry, page, mask)) {
+tlb_n_used_entries_dec(env, midx);
+}
+tlb_flush_vtlb_page_mask_locked(env, midx, page, mask);
 }
-tlb_flush_vtlb_page_mask_locked(env, midx, page, mask);
 }
 
 typedef struct {
 target_ulong addr;
+target_ulong len;
 uint16_t idxmap;
 uint16_t bits;
 } TLBFlushPageBitsByMMUIdxData;
@@ -760,18 +773,20 @@ tlb_flush_page_bits_by_mmuidx_async_0(CPUState *cpu,
 
 assert_cpu_is_self(cpu);
 
-tlb_debug("page addr:" TARGET_FMT_lx "/%u mmu_map:0x%x\n",
-  d.addr, d.bits, d.idxmap);
+tlb_debug("range:" TARGET_FMT_lx "/%u+" TARGET_FMT_lx " mmu_map:0x%x\n",
+  d.addr, d.bits, d.len, d.idxmap);
 
 qemu_spin_lock(_tlb(env)->c.lock);
 for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
 if ((d.idxmap >> mmu_idx) & 1) {
-tlb_flush_page_bits_locked(env, mmu_idx, d.addr, d.bits);
+tlb_flush_range_locked(env, mmu_idx, d.addr, d.len, d.bits);
 }
 }
 qemu_spin_unlock(_tlb(env)->c.lock);
 
-tb_flush_jmp_cache(cpu, d.addr);
+for (target_ulong i = 0; i < d.len; i += TARGET_PAGE_SIZE) {
+tb_flush_jmp_cache(cpu, d.addr + i);
+}
 }
 
 static bool encode_pbm_to_runon(run_on_cpu_data *out,
@@ -829,6 +844,7 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 
 /* This should already be page aligned */
 d.addr = addr & TARGET_PAGE_MASK;
+d.len = TARGET_PAGE_SIZE;
 d.idxmap = idxmap;
 d.bits = bits;
 
@@ -865,6 +881,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 
 /* This should already be page aligned */
 d.addr = addr & TARGET_PAGE_MASK;
+d.len = TARGET_PAGE_SIZE;
 d.idxmap = idxmap;
 d.bits = 

[PATCH 3/9] accel/tlb: Rename TLBFlushPageBitsByMMUIdxData -> TLBFlushRangeData

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/cputlb.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index df5d5dbf879..36e7831ef70 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -762,11 +762,11 @@ typedef struct {
 target_ulong len;
 uint16_t idxmap;
 uint16_t bits;
-} TLBFlushPageBitsByMMUIdxData;
+} TLBFlushRangeData;
 
 static void
 tlb_flush_page_bits_by_mmuidx_async_0(CPUState *cpu,
-  TLBFlushPageBitsByMMUIdxData d)
+  TLBFlushRangeData d)
 {
 CPUArchState *env = cpu->env_ptr;
 int mmu_idx;
@@ -790,7 +790,7 @@ tlb_flush_page_bits_by_mmuidx_async_0(CPUState *cpu,
 }
 
 static bool encode_pbm_to_runon(run_on_cpu_data *out,
-TLBFlushPageBitsByMMUIdxData d)
+TLBFlushRangeData d)
 {
 /* We need 6 bits to hold to hold @bits up to 63. */
 if (d.idxmap <= MAKE_64BIT_MASK(0, TARGET_PAGE_BITS - 6)) {
@@ -800,11 +800,11 @@ static bool encode_pbm_to_runon(run_on_cpu_data *out,
 return false;
 }
 
-static TLBFlushPageBitsByMMUIdxData
+static TLBFlushRangeData
 decode_runon_to_pbm(run_on_cpu_data data)
 {
 target_ulong addr_map_bits = (target_ulong) data.target_ptr;
-return (TLBFlushPageBitsByMMUIdxData){
+return (TLBFlushRangeData){
 .addr = addr_map_bits & TARGET_PAGE_MASK,
 .idxmap = (addr_map_bits & ~TARGET_PAGE_MASK) >> 6,
 .bits = addr_map_bits & 0x3f
@@ -820,7 +820,7 @@ static void tlb_flush_page_bits_by_mmuidx_async_1(CPUState 
*cpu,
 static void tlb_flush_page_bits_by_mmuidx_async_2(CPUState *cpu,
   run_on_cpu_data data)
 {
-TLBFlushPageBitsByMMUIdxData *d = data.host_ptr;
+TLBFlushRangeData *d = data.host_ptr;
 tlb_flush_page_bits_by_mmuidx_async_0(cpu, *d);
 g_free(d);
 }
@@ -828,7 +828,7 @@ static void tlb_flush_page_bits_by_mmuidx_async_2(CPUState 
*cpu,
 void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, target_ulong addr,
uint16_t idxmap, unsigned bits)
 {
-TLBFlushPageBitsByMMUIdxData d;
+TLBFlushRangeData d;
 run_on_cpu_data runon;
 
 /* If all bits are significant, this devolves to tlb_flush_page. */
@@ -854,7 +854,7 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_1, runon);
 } else {
 /* Otherwise allocate a structure, freed by the worker.  */
-TLBFlushPageBitsByMMUIdxData *p = g_memdup(, sizeof(d));
+TLBFlushRangeData *p = g_memdup(, sizeof(d));
 async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_2,
  RUN_ON_CPU_HOST_PTR(p));
 }
@@ -865,7 +865,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 uint16_t idxmap,
 unsigned bits)
 {
-TLBFlushPageBitsByMMUIdxData d;
+TLBFlushRangeData d;
 run_on_cpu_data runon;
 
 /* If all bits are significant, this devolves to tlb_flush_page. */
@@ -893,7 +893,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 /* Allocate a separate data block for each destination cpu.  */
 CPU_FOREACH(dst_cpu) {
 if (dst_cpu != src_cpu) {
-TLBFlushPageBitsByMMUIdxData *p = g_memdup(, sizeof(d));
+TLBFlushRangeData *p = g_memdup(, sizeof(d));
 async_run_on_cpu(dst_cpu,
  tlb_flush_page_bits_by_mmuidx_async_2,
  RUN_ON_CPU_HOST_PTR(p));
@@ -909,7 +909,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
uint16_t idxmap,
unsigned bits)
 {
-TLBFlushPageBitsByMMUIdxData d;
+TLBFlushRangeData d;
 run_on_cpu_data runon;
 
 /* If all bits are significant, this devolves to tlb_flush_page. */
@@ -935,7 +935,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
   runon);
 } else {
 CPUState *dst_cpu;
-TLBFlushPageBitsByMMUIdxData *p;
+TLBFlushRangeData *p;
 
 /* Allocate a separate data block for each destination cpu.  */
 CPU_FOREACH(dst_cpu) {
-- 
2.26.3

[PATCH 0/9] accel/tcg: Add tlb_flush interface for a range of pages

[Philippe Mathieu-Daudé]

Hi Richard,

I tried to make sense of the multiple changes in your patch
https://www.mail-archive.com/qemu-devel@nongnu.org/msg805595.html
by splitting it in multiple trivial changes. At least this way
it is easier to me to follow / review what you did.

The original patch description was:

  Add tlb_flush interface for a range of pages.
  Call these tlb_flush_range_by_mmuidx*.
  Rewrite the_flush_page_bits_by_mmuidx* to use the new
  functions, passing in TARGET_PAGE_SIZE for length.

If you find it useful, fill free to take / respin / reorder this
series, improving descriptions.  Last patch certainly deserves a
better description ;)

Regards,

Phil.

Richard Henderson (9):
  accel/tcg: Replace g_new() + memcpy() by g_memdup()
  accel/tcg: Pass length argument to tlb_flush_range_locked()
  accel/tlb: Rename TLBFlushPageBitsByMMUIdxData -> TLBFlushRangeData
  accel/tcg: Add tlb_flush_range_by_mmuidx()
  accel/tcg: Add tlb_flush_page_bits_by_mmuidx_all_cpus()
  accel/tlb: Add tlb_flush_range_by_mmuidx_all_cpus_synced()
  accel/tcg: Rename tlb_flush_page_bits -> range]_by_mmuidx_async_0
  accel/tlb: Rename tlb_flush_[page_bits > range]_by_mmuidx_async_[2 >
1]
  accel/tcg: Remove tlb_flush_page_bits_by_mmuidx_async_1() ???

 include/exec/exec-all.h |  44 
 accel/tcg/cputlb.c  | 231 
 2 files changed, 158 insertions(+), 117 deletions(-)

-- 
2.26.3

[PATCH 6/9] accel/tlb: Add tlb_flush_range_by_mmuidx_all_cpus_synced()

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/exec-all.h | 12 
 accel/tcg/cputlb.c  | 27 ---
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 9a3dbb7ec08..8021adf38f4 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -281,6 +281,11 @@ void tlb_flush_range_by_mmuidx(CPUState *cpu, target_ulong 
addr,
 void tlb_flush_range_by_mmuidx_all_cpus(CPUState *cpu, target_ulong addr,
 target_ulong len, uint16_t idxmap,
 unsigned bits);
+void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState *cpu,
+   target_ulong addr,
+   target_ulong len,
+   uint16_t idxmap,
+   unsigned bits);
 
 /**
  * tlb_set_page_with_attrs:
@@ -397,6 +402,13 @@ static inline void 
tlb_flush_range_by_mmuidx_all_cpus(CPUState *cpu,
   unsigned bits)
 {
 }
+static inline void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState *cpu,
+ target_ulong addr,
+ target_long len,
+ uint16_t idxmap,
+ unsigned bits)
+{
+}
 #endif
 /**
  * probe_access:
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 5314349ef9d..bc4370f4e21 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -924,16 +924,20 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
idxmap, bits);
 }
 
-void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
-   target_ulong addr,
-   uint16_t idxmap,
-   unsigned bits)
+void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
+   target_ulong addr,
+   target_ulong len,
+   uint16_t idxmap,
+   unsigned bits)
 {
 TLBFlushRangeData d;
 run_on_cpu_data runon;
 
-/* If all bits are significant, this devolves to tlb_flush_page. */
-if (bits >= TARGET_LONG_BITS) {
+/*
+ * If all bits are significant, and len is small,
+ * this devolves to tlb_flush_page.
+ */
+if (bits >= TARGET_LONG_BITS && len <= TARGET_PAGE_SIZE) {
 tlb_flush_page_by_mmuidx_all_cpus_synced(src_cpu, addr, idxmap);
 return;
 }
@@ -945,7 +949,7 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState 
*src_cpu,
 
 /* This should already be page aligned */
 d.addr = addr & TARGET_PAGE_MASK;
-d.len = TARGET_PAGE_SIZE;
+d.len = len;
 d.idxmap = idxmap;
 d.bits = bits;
 
@@ -972,6 +976,15 @@ void 
tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
 }
 }
 
+void tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
+   target_ulong addr,
+   uint16_t idxmap,
+   unsigned bits)
+{
+tlb_flush_range_by_mmuidx_all_cpus_synced(src_cpu, addr, TARGET_PAGE_SIZE,
+  idxmap, bits);
+}
+
 /* update the TLBs so that writes to code in the virtual page 'addr'
can be detected */
 void tlb_protect_code(ram_addr_t ram_addr)
-- 
2.26.3

[PATCH 1/9] accel/tcg: Replace g_new() + memcpy() by g_memdup()

[Philippe Mathieu-Daudé]

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20210508201640.1045808-1-richard.hender...@linaro.org>
[PMD: Split from bigger patch]
Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/cputlb.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 84e7d91a5ca..f616b58a898 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -837,11 +837,8 @@ void tlb_flush_page_bits_by_mmuidx(CPUState *cpu, 
target_ulong addr,
 } else if (encode_pbm_to_runon(, d)) {
 async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_1, runon);
 } else {
-TLBFlushPageBitsByMMUIdxData *p
-= g_new(TLBFlushPageBitsByMMUIdxData, 1);
-
 /* Otherwise allocate a structure, freed by the worker.  */
-*p = d;
+TLBFlushPageBitsByMMUIdxData *p = g_memdup(, sizeof(d));
 async_run_on_cpu(cpu, tlb_flush_page_bits_by_mmuidx_async_2,
  RUN_ON_CPU_HOST_PTR(p));
 }
@@ -875,13 +872,11 @@ void tlb_flush_page_bits_by_mmuidx_all_cpus(CPUState 
*src_cpu,
 flush_all_helper(src_cpu, tlb_flush_page_bits_by_mmuidx_async_1, 
runon);
 } else {
 CPUState *dst_cpu;
-TLBFlushPageBitsByMMUIdxData *p;
 
 /* Allocate a separate data block for each destination cpu.  */
 CPU_FOREACH(dst_cpu) {
 if (dst_cpu != src_cpu) {
-p = g_new(TLBFlushPageBitsByMMUIdxData, 1);
-*p = d;
+TLBFlushPageBitsByMMUIdxData *p = g_memdup(, sizeof(d));
 async_run_on_cpu(dst_cpu,
  tlb_flush_page_bits_by_mmuidx_async_2,
  RUN_ON_CPU_HOST_PTR(p));
@@ -927,15 +922,13 @@ void 
tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
 /* Allocate a separate data block for each destination cpu.  */
 CPU_FOREACH(dst_cpu) {
 if (dst_cpu != src_cpu) {
-p = g_new(TLBFlushPageBitsByMMUIdxData, 1);
-*p = d;
+p = g_memdup(, sizeof(d));
 async_run_on_cpu(dst_cpu, 
tlb_flush_page_bits_by_mmuidx_async_2,
  RUN_ON_CPU_HOST_PTR(p));
 }
 }
 
-p = g_new(TLBFlushPageBitsByMMUIdxData, 1);
-*p = d;
+p = g_memdup(, sizeof(d));
 async_safe_run_on_cpu(src_cpu, tlb_flush_page_bits_by_mmuidx_async_2,
   RUN_ON_CPU_HOST_PTR(p));
 }
-- 
2.26.3

[Bug 1829682] Re: QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: Confirmed => Incomplete

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

Title:
  QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

Status in QEMU:
  Incomplete

Bug description:
  Built from source on a debian system

  Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

  Last git commit (from queued gdibson repository)

  starting AIX 7.2 TL 2 SP 2 with the following : (the install was done
  under qemu 3.1.0)

  qemu-system-ppc64 -M pseries \
  -cpu power7 \
  -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \
  -net nic \
  -net tap,ifname=tap2,script=no \
  -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \
  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
  -m 4G \
  -serial stdio \
  -monitor unix:ms,server,nowait \
  -accel tcg \
  -k fr \
  -nographic \
  -prom-env input-device=/vdevice/vty@7100 \
  -prom-env output-device=/vdevice/vty@7100 \
  -prom-env diag-switch?=false \
  -prom-env boot-command="boot 
/pci@8002000/scsi@2/disk@100 -s verbose"

  Yields this :

  
  ^M
  SLOF^[[0m^[[?25l 
**^M
  ^[[1mQEMU Starting^M
  ^[[0m Build Date = Jan 14 2019 18:00:39^M
   FW Version = git-a5b428e1c1eae703^M
   Press "s" to enter Open Firmware.^M^M
  ^M^M
  
^[[0m^[[?25hC^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating
 /vdevice methods^M
  Populating /vdevice/vty@7100^M
  Populating /vdevice/nvram@7101^M
  Populating /vdevice/l-lan@7102^M
  Populating /vdevice/v-scsi@7103^M
 SCSI: Looking for devices^M
8200 CD-ROM   : "QEMU QEMU CD-ROM  2.5+"^M
  C05A0^MPopulating /pci@8002000^M
   00  (D) : 1234 qemu vga^M
   00 0800 (D) : 1033 0194serial bus [ usb-xhci ]^M
   00 1000 (D) : 1af4 1004virtio [ scsi ]^M
  Populating /pci@8002000/scsi@2^M
 SCSI: Looking for devices^M
100 DISK : "QEMU QEMU HARDDISK2.5+"^M
  C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M
  ^M
  ^M
  ^M
  C08B0^MScanning USB ^M
XHCI: Initializing^M
  USB Keyboard ^M
  USB mouse ^M
  C08C0^MC08D0^MNo console specified using screen & keyboard^M
  User selected input-device console: /vdevice/vty@7100^M
  User selected output-device console: /vdevice/vty@7100^M
  C08E0^MC08E8^MC08FF^M ^M
Welcome to Open Firmware^M
  ^M
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M
This program and the accompanying materials are made available^M
under the terms of the BSD License available at^M
http://www.opensource.org/licenses/bsd-license.php^M
  ^M
  ^M
  Trying to load: -s verbose from: 
/pci@8002000/scsi@2/disk@100 ...   Successfully loaded^M
  ^M
  ---> qemu,pseries detected <---^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  
---^M
  Welcome to AIX.^M
 boot image timestamp: 05:56:13 04/20/2019^M
  processor count: 1;  memory size: 4096MB;  kernel size: 38426884^M
   boot device: 

[Bug 1861161] Re: qemu-arm-static stuck with 100% CPU when cross-compiling emacs

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: Confirmed => Incomplete

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

Title:
  qemu-arm-static stuck with 100% CPU when cross-compiling emacs

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  I'm trying to build multi-arch docker images for
  https://hub.docker.com/r/silex/emacs.

  Here is the machine I'm building on (hetzner cloud machine):

  root@ubuntu-4gb-fsn1-1:~# lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 18.04.3 LTS
  Release:18.04
  Codename:   bionic
  root@ubuntu-4gb-fsn1-1:~# uname -a
  Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

  Whenever I try to build the following alpine Dockerfile
  https://gitlab.com/Silex777/docker-
  emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile like this:

  $ sysctl kernel.randomize_va_space=0
  $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
  $ docker build --pull -t test --platform arm .

  It builds fine until this:

  root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu
  root 26473 26465 99 14:26 pts/001:59:58 /usr/bin/qemu-arm-static 
../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq 
load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el

  This is supposed to take a few seconds, but here it takes 100% CPU and
  never ends. When I strace the process I see a never ending loop like
  this:

  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)
  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)
  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)
  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)
  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)

  It happens with all the QEMU versions I tested:
  - 2.11.1 (OS version)
  - 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1)
  - 4.2.0-2 (from multiarch/qemu-user-static)

  Any ideas of what I could do to debug it further?

  Kind regards,
  Philippe

  p.s: Everything builds fine when the base image is ubuntu. I also had
  similar hangs with basic commands like "apt-get install foo"
  sometimes.

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

[Bug 1839807] Re: Snapshots freeze guest Sabrelite IMX.6 board

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: Confirmed => Incomplete

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

Title:
  Snapshots freeze guest Sabrelite IMX.6 board

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  I'm trying to take and restore  a snapshot with the whole system state of the 
Sabrelite IMX.6 board running on QEMU with commands savevm/loadvm.
  It seems that I am able to take a snapshot but loading the snapshot fails.

  For comparison I checked out snapshots on 32bit ARM Virt with Debian as well 
as on the Versatilepb board with a bare metal application and it works fine.
  The problem occurs only with that one particular board.

  My environment is:
  Ubuntu 18.04
  QEMU 3.0.1 (I see the same issue in QEMU 4.0.0 as well)
  The kernel and device tree used for the board was 5.1.14 version from 
kernel.org

  The file system was build from imx_v6_v7_defconfig config in buildroot
  as and sd card image.

  Problem:

  Loading snapshot stops the whole machine and it's impossible to resume
  it.

  Steps to reproduce problem:

  1.  I converted the sdcard.img built from the buildroot to qcow2
  using command qemu-img convert -f raw -O qcow2 sdcard.img
  sdcard.qcow2, since the raw doesn't support snapshots.

  2.  I start QEMU with a command
  ./arm-softmmu/qemu-system-arm -m 512 -M sabrelite -kernel zImage -append 
"rootfstype=ext4 root=/dev/mmcblk2p2 rw rootwait" -rtc base=localtime,clock=vm 
-dtb imx6dl-sabresd.dtb -drive file=sdcard.qcow2,index=2,format=qcow2,id=mycard 
-device sd-card,drive=mycard -nographic -net nic -net user

  3.  I run a simple program which print characters to the console
  in the background and add some files in user directory, to differ from
  original image.

  4.  I switch to QEMU monitor, and type “savevm ”.
  When I type “info snapshots”, the snapshot is listed.
  So I assume it was saved correctly.

  5.  Then I switch back to Linux console from monitor, remove the
  added files and stop the background printing process.

  6.  I switch back to monitor and I'm trying now to load the
  snapshot by “loadvm ” command.

  That’s where the problem occurs. QEMU stops and I can't switch back from 
monitor to Linux.
  Typing “cont” doesn’t help.
  It seems like the simulation has freezed. CPU usage on my Laptop machine 
equals 100% until I exit QEMU.

  
  What’s interesting when I exit the QEMU and then start it again the Linux 
boots and after it reaches the command prompt I can see the files which were 
removed after saving the snapshot.

  It looks like loading the snapshots works for restoring disk space but
  it fails for restoring the running processes.

  Due to the answer on QEMU mailing list
  (https://lists.nongnu.org/archive/html/qemu-
  discuss/2019-08/msg00016.html) it is QEMUs bug.

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

[Bug 1741718] Re: qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: Confirmed => Incomplete

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

Title:
  qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No
  memory blocks found" with tribblix-sparc-0m16.iso

Status in QEMU:
  Incomplete

Bug description:
  qemu-system-sparc64 Niagara VM running Tribblix crashes with
  "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" on
  QEMU 2.11.0. Happens also with 1 GB, 4 GB, and 8 GB of RAM.

  $ qemu-system-sparc64 -nographic -M niagara -L 
/home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive 
if=pflash,readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 
2048
  cpu Probing I/O buses

  
  Sun Fire T2000, No Keyboard
  Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
  OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
  [mo23723 obp4.20.0 #0]
  Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.


  ok boot
  Boot device: vdisk  File and args: 
  hsfs-file-system 
  Loading: /platform/sun4v/boot_archive
  ramdisk-root ufs-file-system 
  Loading: /platform/sun4v/kernel/sparcv9/unix
  \
  panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found

  Warning - stack not written to the dumpbuf
  0180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 
81010100, ff00)
%l0-3: 01876c00  010d6c00 
%l4-7: 80008f000740 80008fc54750 f0254cc4 010dedd0
  0180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1)
%l0-3: fff32000 fff340e0 fff34590 010d5f28
%l4-7: 0016  0016 0011
  0180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91)
%l0-3: 2000 fff34000 01874c00 01874c00
%l4-7:  01874c00 0180b950 010de048
  0180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0)
%l0-3: 0180e380 0183c678 0180ba08 010d4f90
%l4-7: 010d4fa0 010d1c00 4000 80001070
  0180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0)
%l0-3: 018ee000 70002000 70002000 0180bad0
%l4-7: 0190c4d8 0001001f56e0  80001070

  
  ERROR: Last Trap: Level 14 Interrupt
  [Exception handlers interrupted, please file a bug]
  [type 'resume' to attempt a normal recovery]

  
  Without "if=pflash" VM hangs:

  $ qemu-system-sparc64 -nographic -M niagara -L 
/home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive 
readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 4096
  cpu Probing I/O buses

  
  Sun Fire T2000, No Keyboard
  Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
  OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
  [mo23723 obp4.20.0 #0]
  Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.


  ok boot
  Boot device: vdisk  File and args: 
  qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state
  pc: 0040f01c  npc: 0040f020
  %g0-3:    00970280
  %g4-7: 1000   
  %o0-3:  8ffd6000 8000  
  %o4-7:  00f0 fff55701 f020d78c 
  %l0-3: 0002fd10 7ffe 8000  
  

[Bug 1898215] Re: [git][archlinux]Build process is busted in spice-display.c

[Frederic Bezies]

Fix released

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

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

Title:
  [git][archlinux]Build process is busted in spice-display.c

Status in QEMU:
  Fix Released

Bug description:
  Linux distribution: Archlinux. Crash log added is based on a build
  from scratch.

  Gcc version: 10.2.0

  Configure options used:

  configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --libexecdir=/usr/lib/qemu \
  --extra-ldflags="$LDFLAGS" \
  --smbd=/usr/bin/smbd \
  --enable-modules \
  --enable-sdl \
  --disable-werror \
  --enable-slirp=system \
  --enable-xfsctl \
  --audio-drv-list="pa alsa sdl"

  Crash log:

  ../ui/spice-display.c: In function 'interface_client_monitors_config':
  ../ui/spice-display.c:682:25: error: 
'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this 
function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'?
682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) {
| ^~~
| VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS
  ../ui/spice-display.c:682:25: note: each undeclared identifier is reported 
only once for each function it appears in
  ../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM'
683 | VDAgentMonitorMM *mm = (void 
*)>monitors[mc->num_of_monitors];
| ^~~~
  ../ui/spice-display.c:684:37: error: request for member 'width' in something 
not a structure or union
684 | info.width_mm = mm[head].width;
| ^
  ../ui/spice-display.c:685:38: error: request for member 'height' in something 
not a structure or union
685 | info.height_mm = mm[head].height;
|  ^
  make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1
  make: *** Waiting for unfinished jobs

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

[Bug 1751674] Re: qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: Confirmed => Incomplete

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

Title:
  qemu-system-arm segmentation fault using pmemsave on the interrupt
  controller registers

Status in QEMU:
  Incomplete

Bug description:
  Qemu segfaults trying to generate a VM memory dump:

  $ QEMU_AUDIO_DRV=none qemu-git-src/arm-softmmu/qemu-system-arm -M vexpress-a9 
-smp 4 -m 1024 -machine secure=off,dump-guest-core=on -kernel 
linux-4.9.75/arch/arm/boot/zImage -append "root=/dev/mmcblk0 rw rootfstype=ext4 
mem=1024M net.ifnames=0 console=ttyAMA0" -dtb vexpress-v2p-ca9.dtb -sd 
armv7-hd.qcow2 -netdev tap,ifname=tap_armv7,script=no,downscript=no,id=net0 
-device virtio-net-device,mac=00:AA:AD:BB:FF:02,netdev=net0  -monitor stdio 
-serial vc  -loadvm SS0
  QEMU 2.11.50 monitor - type 'help' for more information
  (qemu) pmemsave 0 0x3FFF memory.dmp
  Segmentation fault (core dumped)

  $ git rev-parse HEAD
  b384cd95eb9c6f73ad84ed1bb0717a26e29cc78f

  It's the second time I try to submit this bug, I think last time it
  failed because the attached core dump size (400M compressed). Have a
  look if you can get that file, otherwise I will try to update this
  ticket once it's created:

  (Error ID: OOPS-65553b72bc14be693eb1e37814ff9267)

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

[Bug 1919169] Re: [git]Startup crash when trying to use an EFI enabled VM in accel/kvm/kvm-all.c

[Frederic Bezies]

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

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

Title:
  [git]Startup crash when trying to use an EFI enabled VM in accel/kvm
  /kvm-all.c

Status in QEMU:
  Fix Released

Bug description:
  Hello.

  I build a git version based on commit
  6157b0e19721aadb4c7fdcfe57b2924af6144b14.

  When I try to launch an EFI enabled VM, it crashes on start. Here is
  the command line used:

  qemu-system-x86_64 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -enable-kvm
  -smp 4 -soundhw all -k fr -m 4096 -vga qxl -hda disk.img -cdrom
  archlinux-2021.03.01-x86_64.iso -boot cd &

  Here is the log I get:

  
  "qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: 
Assertion `QEMU_IS_ALIGNED(start | size, psize)' failed."

  
  ed2k-ovmf version: 202102

  I tried an older version, edk2-ovmf 202011, same crash on start.

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

[Bug 1901892] Re: qemu-img create corrupts the qcow2 if the file already exists

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  qemu-img create corrupts the qcow2 if the file already exists

Status in QEMU:
  Incomplete

Bug description:
  When creating a disk using qemu-img create command, if the destination
  path of the qcow2 file already exists, it will show the error saying
  that it cannot get a lock so it exits with exit status 1 but it will
  corrupt the qcow2 file anyway.

  Steps to reproduce:
  1. Have a guest running with a root (vda) and a second device (vdc).
  In my case is a clean Ubuntu 16.04 image with kernel 4.4.0-190-generic x86_64
  vdc disk is called testadddisk-3.qcow2
  2. vdc is an xfs over lvm.
  pvcreacte /dev/vdc
  vgcreate myVg /dev/vdc
  lvcreate -l+100%FREE -n myLv myVg
  mkfs.xfs /dev/mapper/myVg-myLv
  mount /dev/mapper/myVg-myLv /mnt
  3. Create disk IO on that device in the guest.
  while true ; do dd if=/dev/zero of=/mnt/testfile bs=1024 count=1000 ; sleep 
1; done
  4. Execute the command to create a new device but use the same name of the 
device attached:
  sudo qemu-img create -f qcow2 testadddisk-3.qcow2 20G
  The output of the command is this:
  Formatting 'testadddisk-3.qcow2', fmt=qcow2 size=21474836480 
cluster_size=65536 lazy_refcounts=off refcount_bits=16
  qemu-img: testadddisk-3.qcow2: Failed to get "write" lock
  Is another process using the image?

  The write continues in the guest but when it is shutdown, when it is powered 
on again you get this:
  error: Failed to start domain testadddisk
  error: internal error: process exited while connecting to monitor: 
2020-10-27T22:00:51.628374Z qemu-system-x86_64: -drive 
file=/var/lib/vmImages/testadddisk-3.qcow2,format=qcow2,if=none,id=drive-virtio-disk2:
 Image is not in qcow2 format

  I run the qemu-img create command with an strace and I believe that
  first it tries to open the file in write mode, then does a truncate on
  it and after that says it cannot get a lock. The output is in the file
  attached. As well as the guest xml just in case.

  The host: 
  Ubuntu 18.04.5 LTS
  4.15.0-112-generic x86_64
  qemu packages installed:
  ii  qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu7.32
 amd64extra block backend modules for qemu-system and 
qemu-utils
  ii  qemu-kvm   1:2.11+dfsg-1ubuntu7.31
 amd64QEMU Full virtualization on x86 hardware
  ii  qemu-system-common 1:2.11+dfsg-1ubuntu7.32
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-x861:2.11+dfsg-1ubuntu7.31
 amd64QEMU full system emulation binaries (x86)
  ii  qemu-utils 1:2.11+dfsg-1ubuntu7.32
 amd64QEMU utilities

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

[Bug 1902394] Re: Guest stuck in Paused state right after created It

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Guest stuck in Paused state right after created It

Status in QEMU:
  Incomplete

Bug description:
  Im using Centos 8 . I have try to use many Distribution such as :
  Centos, Ubuntum, Debian,.. on the guest but still all the the VM get
  into paused state immidiately after using virt-install ( I have tried
  using virt-manager too )

  CPU INFO :
  Architecture:x86_64
  CPU op-mode(s):  32-bit, 64-bit
  Byte Order:  Little Endian
  CPU(s):  8
  On-line CPU(s) list: 0-7
  Thread(s) per core:  1
  Core(s) per socket:  1
  Socket(s):   8
  NUMA node(s):1
  Vendor ID:   GenuineIntel
  CPU family:  6
  Model:   85
  Model name:  Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz
  Stepping:7
  CPU MHz: 2199.998
  BogoMIPS:4399.99
  Virtualization:  VT-x
  Hypervisor vendor:   KVM
  Virtualization type: full
  L1d cache:   32K
  L1i cache:   32K
  L2 cache:4096K
  L3 cache:16384K
  NUMA node0 CPU(s):   0-7
  Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm 
constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni 
pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 
3dnowprefetch invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority 
ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx 
avx512f rdseed adx smap clflushopt clwb avx512cd xsaveopt xsavec xgetbv1 arat

  VM Log :

  2020-10-31 08:29:51.737+: starting up libvirt version: 4.5.0, package: 
42.module_el8.2.0+320+13f867d7 (CentOS Buildsys , 
2020-05-28-17:13:31, ), qemu version: 
2.12.0qemu-kvm-2.12.0-99.module_el8.2.0+524+f765f7e0.4, kernel: 
4.18.0-193.28.1.el8_2.x86_64, hostname: interns.novalocal
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=cirros,debug-threads=on 
-S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-cirros/master-key.aes
 -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off 
-cpu 
Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,arch-capabilities=on,ibpb=on,skip-l1dfl-vmentry=on,invpcid=off,avx512dq=off,avx512bw=off,avx512vl=off,pku=off,avx512vnni=off,pdpe1gb=off
 -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
ef9573a3-a02d-4ef0-86cb-e38da7b7b20d -no-user-config -nodefaults -chardev 
socket,id=charmonitor,fd=29,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global 
kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global 
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/home/kvm/cirros-0.3.0-x86_64-disk.img,format=qcow2,if=none,id=drive-ide0-0-0
 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 
-netdev tap,fd=31,id=hostnet0 -device 

[Bug 1902451] Re: incorrect cpuid feature detection

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

** Tags added: i386

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

Title:
  incorrect cpuid feature detection

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  I am currently developing a x64 kernel and I wanted to check through
  cpuid if some features are available in the guest. When I try to
  enable cpu features like vmcb_clean or constant_tsc qemu is saying
  that my host doesn't support the requested features. However cat
  /proc/cpuinfo tells a different story:

  model name:  AMD Ryzen 5 3500U
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx 
f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb hw_pstate sme pti ssbd sev ibpb vmmcall fsgsbase bmi1 
avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves 
clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean 
flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif 
overflow_recov succor smca

  I also checked it myself by running cpuid and check the bits as in the
  AMD Manual. Everything checks out but qemu still fails.

  QEMU version: QEMU emulator version 4.2.0

  $ qemu-system-x86_64 -cpu host,+vmcb_clean,enforce -enable-kvm -drive 
format=raw,file=target/x86_64-os/debug/bootimage-my_kernel.bin -serial stdio 
-display none
  qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.800AH:EDX.vmcb-clean [bit 5]
  qemu-system-x86_64: Host doesn't support requested features

  or

  $ qemu-system-x86_64 -cpu host,+constant_tsc,enforce -enable-kvm -drive 
format=raw,file=target/x86_64-os/debug/bootimage-my_kernel.bin -serial stdio 
-display none
  qemu-system-x86_64: Property '.constant_tsc' not found

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

[Bug 1902777] Re: qemu with whpx acceleration crashes with vmx=on

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  qemu with whpx acceleration crashes with vmx=on

Status in QEMU:
  Incomplete

Bug description:
  Under Windows 10, qemu crashes when using whpx acceleration and the vmx=on 
option.  The reported error is
qemu-system-x86_64.exe: WHPX: Unexpected VP exit code 4
  Before the error, it reports
Windows Hypervisor Platform accelerator is operational

  The command line is the following:
"C:\Program Files\qemu\qemu-system-x86_64.exe" -accel whpx -cpu 
qemu64,vmx=on
  It crashes with any model of CPU as long as the "vmx=on" option is added.  
Without this option it runs fine (but no nested virtualization).

  My processor is an Intel i7-10510U, and I am running Windows 10 2004
  (build 19041.572).

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

[Bug 1835865] Re: piix crashes on mips when accessing acpi-pci-hotplug

[Thomas Huth]

Bug has been moved to the new issue tracker here:
https://gitlab.com/qemu-project/qemu/-/issues/221

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #221
   https://gitlab.com/qemu-project/qemu/-/issues/221

** Changed in: qemu
   Status: Confirmed => Invalid

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

Title:
  piix crashes on mips when accessing acpi-pci-hotplug

Status in QEMU:
  Invalid

Bug description:
  $ qemu-system-mips --version
  QEMU emulator version 4.0.50 (v4.0.0-1975-gf34edbc760)

  $ qemu-system-mips -machine malta -bios /dev/null -nodefaults -monitor stdio 
-S
  (qemu) o 0xaf00 0
  qemu-system-mips: hw/acpi/cpu.c:197: cpu_hotplug_hw_init: Assertion 
`mc->possible_cpu_arch_ids' failed.
  Aborted (core dumped)

  (gdb) bt
  #0  0x7f6fd748957f in raise () at /lib64/libc.so.6
  #1  0x7f6fd7473895 in abort () at /lib64/libc.so.6
  #2  0x7f6fd7473769 in _nl_load_domain.cold.0 () at /lib64/libc.so.6
  #3  0x7f6fd7481a26 in .annobin_assert.c_end () at /lib64/libc.so.6
  #4  0x5646d58ca7bd in cpu_hotplug_hw_init (as=0x5646d6ae3300, 
owner=0x5646d6fd5b10, state=0x5646d6fd7a30, base_addr=44800) at 
hw/acpi/cpu.c:197
  #5  0x5646d58c5284 in acpi_switch_to_modern_cphp (gpe_cpu=0x5646d6fd7910, 
cpuhp_state=0x5646d6fd7a30, io_port=44800) at hw/acpi/cpu_hotplug.c:107
  #6  0x5646d58c3431 in piix4_set_cpu_hotplug_legacy (obj=0x5646d6fd5b10, 
value=false, errp=0x5646d61cdb28 ) at hw/acpi/piix4.c:617
  #7  0x5646d5b00c70 in property_set_bool (obj=0x5646d6fd5b10, 
v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", 
opaque=0x5646d707d110, errp=0x5646d61cdb28 ) at qom/object.c:2076
  #8  0x5646d5afeee6 in object_property_set (obj=0x5646d6fd5b10, 
v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 
) at qom/object.c:1268
  #9  0x5646d5b01fb8 in object_property_set_qobject (obj=0x5646d6fd5b10, 
value=0x5646d75b5450, name=0x5646d5cf3a90 "cpu-hotplug-legacy", 
errp=0x5646d61cdb28 ) at qom/qom-qobject.c:26
  #10 0x5646d5aff1cb in object_property_set_bool (obj=0x5646d6fd5b10, 
value=false, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 
) at qom/object.c:1334
  #11 0x5646d58c4fce in cpu_status_write (opaque=0x5646d6fd7910, addr=0, 
data=0, size=1) at hw/acpi/cpu_hotplug.c:44
  #12 0x5646d569c707 in memory_region_write_accessor (mr=0x5646d6fd7920, 
addr=0, value=0x7ffc18053068, size=1, shift=0, mask=255, attrs=...) at 
memory.c:503
  #13 0x5646d569c917 in access_with_adjusted_size (addr=0, 
value=0x7ffc18053068, size=1, access_size_min=1, access_size_max=4, 
access_fn=0x5646d569c61e , mr=0x5646d6fd7920, 
attrs=...)
  at memory.c:569
  #14 0x5646d569f8f3 in memory_region_dispatch_write (mr=0x5646d6fd7920, 
addr=0, data=0, size=1, attrs=...) at memory.c:1497
  #15 0x5646d563e5c5 in flatview_write_continue (fv=0x5646d751b000, 
addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4, addr1=0, l=1, 
mr=0x5646d6fd7920) at exec.c:3324
  #16 0x5646d563e70a in flatview_write (fv=0x5646d751b000, addr=44800, 
attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3363
  #17 0x5646d563ea0f in address_space_write (as=0x5646d618abc0 
, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at 
exec.c:3453
  #18 0x5646d5696ee5 in cpu_outl (addr=44800, val=0) at ioport.c:80
  #19 0x5646d57585d0 in hmp_ioport_write (mon=0x5646d6bc70e0, 
qdict=0x5646d6cf7140) at monitor/misc.c:1058
  #20 0x5646d5a77b99 in handle_hmp_command (mon=0x5646d6bc70e0, 
cmdline=0x5646d6bc2542 "0xaf00 0") at monitor/hmp.c:1082
  #21 0x5646d5a7540a in monitor_command_cb (opaque=0x5646d6bc70e0, 
cmdline=0x5646d6bc2540 "o 0xaf00 0", readline_opaque=0x0) at monitor/hmp.c:47
  #22 0x5646d5c71450 in readline_handle_byte (rs=0x5646d6bc2540, ch=13) at 
util/readline.c:408
  #23 0x5646d5a7858f in monitor_read (opaque=0x5646d6bc70e0, 
buf=0x7ffc180533d0 "\rtc\327FV", size=1) at monitor/hmp.c:1312
  #24 0x5646d5bc8d17 in qemu_chr_be_write_impl (s=0x5646d6add000, 
buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:177
  #25 0x5646d5bc8d7b in qemu_chr_be_write (s=0x5646d6add000, 
buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:189
  #26 0x5646d5bcb6bf in fd_chr_read (chan=0x5646d6a80d60, cond=G_IO_IN, 
opaque=0x5646d6add000) at chardev/char-fd.c:68
  #27 0x5646d5bec485 in qio_channel_fd_source_dispatch 
(source=0x5646d765a480, callback=0x5646d5bcb561 , 
user_data=0x5646d6add000) at io/channel-watch.c:84
  #28 0x7f6fd9c1606d in g_main_context_dispatch () at 
/lib64/libglib-2.0.so.0
  #29 0x5646d5c5323a in glib_pollfds_poll () at util/main-loop.c:213
  #30 0x5646d5c532b4 in os_host_main_loop_wait (timeout=29821719) at 
util/main-loop.c:236
  #31 0x5646d5c533b9 in main_loop_wait (nonblocking=0) at 
util/main-loop.c:512
  #32 0x5646d581d1a1 in main_loop () at 

[Bug 1901359] Re: ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access

[Thomas Huth]

Yeah, the bug tracker here on Launchpad is somewhat neglected ... Therefore:
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access

Status in QEMU:
  Incomplete

Bug description:
  I'v recently stumbled upon a bug in the Plan9 PCI config space access
  routines for config mode #1.

  The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1
  access.

  This was most likely a misreading of the PCI local bus specification
  on our side.

  However, in the PCI local bus specification 3.0, it states the
  following:

  > 3.2.2.3.2 Software Generation of Configuration Transactions
  > ...
  > For Type 1 translations, the host bridge directly copies the contents of the
  > CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines 
during the
  > address phase of a configuration transaction making sure that AD[1::0] is 
"01".

  note the: "excluding bits 31 and 0"

  What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS
  register as part of the register offset (when it probably should ignore it)
  when translating from Type 1 to Type 0 address. So once it reaches the device
  behind the bridge the register address is off by one.

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

[Bug 1901068] Re: Deleted tests are still run if they exist in the build tree

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Deleted tests are still run if they exist in the build tree

Status in QEMU:
  Incomplete

Bug description:
  Steps to reproduce:
  1. Add a new device along with a qtest to exercise it.
  2. Run make check-qtest. It passes.
  3. Revert the commit that added the device and qtest.
  4. Run make check-qtest again. It now fails because the device no longer 
exists, but the test is somehow still there even though the source files are 
gone and it's not mentioned in tests/qtest/meson.build.

  After running make clean, make check-qtest passes again.

  $ git describe
  v5.1.0-2465-g4c5b97bfd0

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

[Bug 1900122] Re: Unsupported ioctl: cmd=0xffffffff80685600 when accessing /dev/video* in aarch64 guest

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Unsupported ioctl: cmd=0x80685600 when accessing /dev/video*
  in aarch64 guest

Status in QEMU:
  Incomplete

Bug description:
  **Description:**
  Any attempt to work with video in aarch64 architecture emulated on x86_64 
leads currently to the error "Function not implemented". For example:

  ```
  # v4l2-ctl -l --verbose
  Failed to open /dev/video0: Function not implemented

  root@12dd9b6fcfcb:/# ll /dev/video*
  crw-rw 1 root video 81, 0 Oct 16 09:23 /dev/video0
  crw-rw 1 root video 81, 1 Oct 16 09:23 /dev/video1

  ```

  **Steps to reproduce the issue:**

  I have a following setup:

  Host Hardware: x86_64 equipped with a webcam (tried different webcams)
  Host OS: Ubuntu 20.04.1

  Guest Architecture: aarch64
  Guest OS: Ubuntu 20.04 (also tried 16.x and 18.x)

  Emulation: quemu-user-static (also tried binfmt)

  Guest OS is running via Docker + QEMU

  ```
  ➜ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
  enabled
  interpreter /usr/bin/qemu-aarch64-static
  flags: F
  offset 0
  magic 7f454c46020101000200b700
  mask ff00feff
  ```

  **Results received:**
  see desrciption.

  
  **Environment:**

  * QEMU version: (if you can know it):

  ipxe-qemu-256k-compat-efi-roms/focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 
all [installed,automatic]
  ipxe-qemu/focal-updates,now 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all 
[installed,automatic]
  qemu-block-extra/focal-updates,now 1:4.2-3ubuntu6.7 amd64 
[installed,automatic]
  qemu-kvm/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed]
  qemu-system-common/focal-updates,now 1:4.2-3ubuntu6.7 amd64 
[installed,automatic]
  qemu-system-data/focal-updates,now 1:4.2-3ubuntu6.7 all [installed,automatic]
  qemu-system-gui/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic]
  qemu-system-x86/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic]
  qemu-user-binfmt/focal-updates,now 1:4.2-3ubuntu6.7 amd64 
[installed,automatic]
  qemu-user/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed]
  qemu-utils/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic]
  qemu/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed]

  * Container application: Docker

  **Output of `docker version`, `podman version` or `singularity
  version`**

  ```
  ➜ docker version
  Client: Docker Engine - Community
   Version:   20.10.0-beta1
   API version:   1.40
   Go version:go1.13.15
   Git commit:ac365d7
   Built: Tue Oct 13 18:15:22 2020
   OS/Arch:   linux/amd64
   Context:   default
   Experimental:  true

  Server: Docker Engine - Community
   Engine:
    Version:  19.03.13
    API version:  1.40 (minimum version 1.12)
    Go version:   go1.13.15
    Git commit:   4484c46d9d
    Built:Wed Sep 16 17:01:20 2020
    OS/Arch:  linux/amd64
    Experimental: false
   containerd:
    Version:  1.4.1
    GitCommit:c623d1b36f09f8ef6536a057bd658b3aa8632828
   runc:
    Version:  1.0.0-rc92
    GitCommit:ff819c7e9184c13b7c2607fe6c30ae19403a7aff
   docker-init:
    Version:  0.18.0
    GitCommit:fec3683

  ```

  Guest aarch64 runs in privileged mode:

  `docker run --privileged --device=/dev/video0:/dev/video0 --env
  DISPLAY=unix$DISPLAY -v $XAUTH:/root/.Xauthority  -v
  /tmp/.X11-unix:/tmp/.X11-unix -it --rm arm64v8/ubuntu:20.04 bash`

  **Additional information:**
  I tried 

[Bug 1900352] Re: no sound in spice when VNC enabled

[Thomas Huth]

So if this is libvirt's fault, can we close this ticket here? Has
anybody already reported this to in the libvirt bug tracker?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  no sound in spice when VNC enabled

Status in QEMU:
  Incomplete

Bug description:
  Running Fedora32 with virt-manager → libvirt → qemu  I noticed that I
  got no sound in my spice client. The VM is configured with a SPICE-
  server and a QXL display, and in addition a VNC display.

  Apparently when I remove the VNC display, then the sound is routed
  just fine to the spice client: I can hear it, and
  `G_MESSAGES_DEBUG=all remote-viewer --spice-debug
  spice://localhost:5900` mentions SpicePlaybackChannel and
  SpiceRecordChannel. With the VNC server configured, such messages are
  missing, and I cannot hear the sound (which is sent by the guest OS to
  the virtual hardware).

  qemu-4.2.1-1.fc32

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

[Bug 1899539] Re: keyboard errors in DOS, found links to similar errors for reference

[Thomas Huth]

Could you please check whether the patch mentioned in
https://bugs.launchpad.net/qemu/+bug/1897568 fixes this problem here,
too?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  keyboard errors in DOS, found links to similar errors for reference

Status in QEMU:
  Incomplete

Bug description:
  OS: slackware 14.2, updated. qemu version: 4.1.0 (from slackbuild
  script)

  command line: qemu-system-i386 -hda msdos.vhd

  Description of problem: MSDOS 6.22 disk image running gwbasic 3.23.
  Cursor keys and sometimes letter keys are repeated. Cursor keys
  seemingly always, letter keys seem to happen when typing too fast.
  Numpad arrows are not affected.  Also insert key doesnt seem to work
  at all.

  Have found one similar current bug, Bug #1574246 Drunken keyboard in
  go32v2 programs
  https://bugs.launchpad.net/qemu/+bug/1574246?comments=all and a much
  older vbox bug report that seems very similar,
  https://www.virtualbox.org/ticket/58 , and for some reason mentions a
  qemu patch.

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

[Bug 1900919] Re: PXB selected as root bus incorrectly

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  PXB selected as root bus incorrectly

Status in QEMU:
  Incomplete

Bug description:
  release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89

  qdev_device_add() will search for the "closest" bus possible, and bail out 
early if that bus is a root bus. pxb devices are considered root buses and so 
if you either
  1. Add a PCI device on the QEMU command line *after* a pxb device, or
  2. Add an integrated PCI device (like a watchdog)

  #1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device 
ahci,id=sata0,addr=0x8
  #2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52

  The PXB will get selected as the bus (instead of the real root bus)
  and this will cause an assertion failure with the message like "qemu-
  system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe
  bridges can be plugged into pxb-pcie"

  I think this is relatively solvable in the code base by determining if
  a bus is an expander, and skipping it if so. However, I wonder if it
  makes more sense to just allow expanders to have endpoint devices.

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

[Bug 1898215] Re: [git][archlinux]Build process is busted in spice-display.c

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  [git][archlinux]Build process is busted in spice-display.c

Status in QEMU:
  Incomplete

Bug description:
  Linux distribution: Archlinux. Crash log added is based on a build
  from scratch.

  Gcc version: 10.2.0

  Configure options used:

  configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --libexecdir=/usr/lib/qemu \
  --extra-ldflags="$LDFLAGS" \
  --smbd=/usr/bin/smbd \
  --enable-modules \
  --enable-sdl \
  --disable-werror \
  --enable-slirp=system \
  --enable-xfsctl \
  --audio-drv-list="pa alsa sdl"

  Crash log:

  ../ui/spice-display.c: In function 'interface_client_monitors_config':
  ../ui/spice-display.c:682:25: error: 
'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this 
function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'?
682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) {
| ^~~
| VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS
  ../ui/spice-display.c:682:25: note: each undeclared identifier is reported 
only once for each function it appears in
  ../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM'
683 | VDAgentMonitorMM *mm = (void 
*)>monitors[mc->num_of_monitors];
| ^~~~
  ../ui/spice-display.c:684:37: error: request for member 'width' in something 
not a structure or union
684 | info.width_mm = mm[head].width;
| ^
  ../ui/spice-display.c:685:38: error: request for member 'height' in something 
not a structure or union
685 | info.height_mm = mm[head].height;
|  ^
  make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1
  make: *** Waiting for unfinished jobs

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

[Bug 1898490] Re: gtk with virtio and opengl black screen

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  gtk with virtio and opengl black screen

Status in QEMU:
  Incomplete

Bug description:
  qemu-system-x86_64 -name manjaro -enable-kvm -cpu host -smp
  cores=4,threads=1 -M q35 -m 8G -cdrom /mnt/Storage/ISO/manjaro-
  gnome-20.0.3-minimal-200606-linux56.iso -machine type=pc,accel=kvm
  -vga virtio -display sdl,gl=on Boots properly and has working 3d
  acceleration with virgl.

  Running qemu-system-x86_64 -name manjaro -enable-kvm -cpu host -smp
  cores=4,threads=1 -M q35 -m 8G -cdrom /mnt/Storage/ISO/manjaro-
  gnome-20.0.3-minimal-200606-linux56.iso -machine type=pc,accel=kvm
  -vga virtio -display gtk,gl=on however, (difference being gtk instead
  of sdl), the screen is black, and the vm still starts.

  System Specs
  Gentoo Linux 64bit
  Gentoo-Sources 5.8.13 Kernel
  Qemu 5.10.0-r1 compiled with USE="aio bzip2 caps curl fdt filecaps gtk jpeg 
ncurses nls opengl oss pin-upstream-blobs png pulseaudio sdl seccomp slirp 
spice usb usbredir vhost-net virgl vnc xattr xkb" PYTHON_TARGETS="python3_7" 
QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64"

  Ryzen 7 2700x
  Nvidia 1070ti GPU

  I can confirm the same issue when using libvirt with opengl.

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

[Bug 1902365] Re: 3x 100% host CPU core usage while virtual machine is in idle

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  3x 100% host CPU core usage while virtual machine is in idle

Status in QEMU:
  Incomplete

Bug description:
  My Fedora 33 machine "top" command shows qemu-system-x86_64 process
  using ~300% CPU, that means 3x CPU cores at 100%. Since the virtual
  machine (named CentOS 8) is almost in idle (top command inside the VM
  shows ~0% CPU usage), there must be something wrong. I attach qemu
  process GDB backtrace, and virtual machine libvirt XML

  Host details:
  libvirt-6.6.0-2.fc33.x86_64
  qemu-system-x86-5.1.0-5.fc33.x86_64
  virt-manager-3.1.0-1.fc33.noarch
  kernel 5.8.16-300.fc33.x86_64
  CPU: AMD Ryzen 5 3600

  # gdb qemu-system-x86_64 405756
  GNU gdb (GDB) Fedora 9.2-7.fc33
  Copyright (C) 2020 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from qemu-system-x86_64...
  Reading symbols from .gnu_debugdata for /usr/bin/qemu-system-x86_64...
  (No debugging symbols found in .gnu_debugdata for /usr/bin/qemu-system-x86_64)
  Attaching to program: /usr/bin/qemu-system-x86_64, process 405756
  [New LWP 405788]
  [New LWP 405798]
  [New LWP 405799]
  [New LWP 405800]
  [New LWP 405801]
  [New LWP 405802]
  [New LWP 405804]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  0x7f549d0bdb0e in ppoll () from target:/lib64/libc.so.6
  (gdb) set height 0
  (gdb) set print elements 0
  (gdb) set print frame-arguments all
  (gdb) thread apply all backtrace

  Thread 8 (Thread 0x7f53837ff640 (LWP 405804)):
  #0  0x7f549d0bda0f in poll () from target:/lib64/libc.so.6
  #1  0x7f549e4c2d1e in g_main_context_iterate.constprop () from 
target:/lib64/libglib-2.0.so.0
  #2  0x7f549e4716ab in g_main_loop_run () from 
target:/lib64/libglib-2.0.so.0
  #3  0x7f549dcfcc66 in red_worker_main.lto_priv () from 
target:/lib64/libspice-server.so.1
  #4  0x7f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0
  #5  0x7f549d0c8b03 in clone () from target:/lib64/libc.so.6

  Thread 7 (Thread 0x7f5390dfd640 (LWP 405802)):
  #0  0x7f549d0bf58b in ioctl () from target:/lib64/libc.so.6
  #1  0x55a60728ec87 in kvm_vcpu_ioctl ()
  #2  0x55a60728edc1 in kvm_cpu_exec ()
  #3  0x55a60734dc04 in qemu_kvm_cpu_thread_fn ()
  #4  0x55a6076dc0ff in qemu_thread_start ()
  #5  0x7f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0
  #6  0x7f549d0c8b03 in clone () from target:/lib64/libc.so.6

  Thread 6 (Thread 0x7f53915fe640 (LWP 405801)):
  #0  0x7f549d0bf58b in ioctl () from target:/lib64/libc.so.6
  #1  0x55a60728ec87 in kvm_vcpu_ioctl ()
  #2  0x55a60728edc1 in kvm_cpu_exec ()
  #3  0x55a60734dc04 in qemu_kvm_cpu_thread_fn ()
  #4  0x55a6076dc0ff in qemu_thread_start ()
  #5  0x7f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0
  

[Bug 1898954] Re: x86 f1 opcode hangs qemu

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  x86 f1 opcode hangs qemu

Status in QEMU:
  Incomplete

Bug description:
  I have qemu installed and running in linux and windows
  in linux i execute the following simple code in real mode of cpu in my vm
  90 nop
  90 nop
  90 nop
  f1 ;this should conjure up my interrupt handler from ivt int 1
  - end of code 
  it works properly in vbox,qemu linux,and even in my boot loder
  on a real platform
 it doeas not work fine in windows 10 (32 bit efi) based qemu
  ---
  all of the below was retyped there may be typo
  so onwards to the flawed software 
  ** for qemu-system-x86_64.exe **
  info version 
  4.2.0v4.2.0.11797-g2890edc853-dirty
  ** for qemu-system-i386.exe **
  info version 
  4.2.0v4.2.0.11797-g2890edc853-dirty
  ***
  my startup code is
  "d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" 
-cpu Nehalem -machine pc
  ---
  also same flaw if i change above section to
  "d:\programs\qemu\qemu-system-i386.exe"

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

[Bug 1899082] Re: ReplayKernel.test_x86_64_pc fails intermittently

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  ReplayKernel.test_x86_64_pc fails intermittently

Status in QEMU:
  Incomplete

Bug description:
  Even though this acceptance test is already skipped on GitLab CI, the
  intermittent failures can be seen on other environments too.

  The record phase works fine, but during the replay phase fail to
  finish booting the kernel (until the expected place):

  16:34:47 DEBUG| [0.034498] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 
1GB 0
  16:34:47 DEBUG| [0.034790] Spectre V2 : Spectre mitigation: LFENCE not 
serializing, switching to generic retpoline
  16:34:47 DEBUG| [0.035093] Spectre V2 : Mitigation: Full generic retpoline
  16:34:47 DEBUG| [0.035347] Spectre V2 : Spectre v2 / SpectreRSB 
mitigation: Filling RSB on context switch
  16:34:47 DEBUG| [0.035667]
  16:36:02 ERROR| 
  16:36:02 ERROR| Reproduced traceback from: 
/home/cleber/src/avocado/avocado/avocado/core/test.py:767
  16:36:02 ERROR| Traceback (most recent call last):
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 92, 
in test_x86_64_pc
  16:36:02 ERROR| self.run_rr(kernel_path, kernel_command_line, 
console_pattern, shift=5)
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 73, 
in run_rr
  16:36:02 ERROR| False, shift, args, replay_path)
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 55, 
in run_vm
  16:36:02 ERROR| self.wait_for_console_pattern(console_pattern, vm)
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 
53, in wait_for_console_pattern
  16:36:02 ERROR| vm=vm)
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", 
line 130, in wait_for_console_pattern
  16:36:02 ERROR| _console_interaction(test, success_message, 
failure_message, None, vm=vm)
  16:36:02 ERROR|   File 
"/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", 
line 82, in _console_interaction
  16:36:02 ERROR| msg = console.readline().strip()
  16:36:02 ERROR|   File "/usr/lib64/python3.7/socket.py", line 575, in readinto
  16:36:02 ERROR| def readinto(self, b):
  16:36:02 ERROR|   File 
"/home/cleber/src/avocado/avocado/avocado/plugins/runner.py", line 77, in 
sigterm_handler
  16:36:02 ERROR| raise RuntimeError("Test interrupted by SIGTERM")
  16:36:02 ERROR| RuntimeError: Test interrupted by SIGTERM
  16:36:02 ERROR| 

  On my workstation, I can replicate the failure roughly once every 50
  runs.

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

[Bug 1902267] Re: CPU not support 32-bit stack in 32-bit unreal mode

[Thomas Huth]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  CPU not support 32-bit stack in 32-bit unreal mode

Status in QEMU:
  Incomplete

Bug description:
  QEMU version 5.0.0 supports 32-bit and 16-bit unreal mode. Great!
  Unfortunately, QEMU does not support 32-bit stack in unreal 32-bit mode.
  After the INT instruction, the stack is switched to 16-bit, which should not 
be the case. 
  At BOCHS, my code works 100%. At QEMU not works.

  Sample code to find out:

  use32
  cli
  mov ax,cs
  shl eax,16
  mov ax,NewInt80h
  mov [IDT32+4*80h],eax
  mov edx,esp
  mov esp,0x1
  int 80h
  NewInt80h:
  xchg esp,edx
  cmp edx,0x1-6
  jnz IsStack16Bit

  Stack selector loaded from GDT:
  GDT:
  real32_GDT
  dq 0
  dw 0x,0x,9A00h,0xCF ; 32-bit code descriptor
  dw 0x,0x,9200h,0x8F ;   4 GB data descriptor
  dw 0x,0x,9A00h,0x00 ; 16-bit code descriptor
  dw 0x,0x,9200h,0xCF ; 32-bit data descriptor stack

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

[Bug 1902262] Re: vmstate_load_state return error into virtio_load function

[Thomas Huth]

Can you also reproduce this with the latest version of QEMU? Anyway:
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Changed in: qemu
   Status: New => Incomplete

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

Title:
  vmstate_load_state return error into virtio_load function

Status in QEMU:
  Incomplete

Bug description:
  Qemu version 4.2.1

  In the function of virtio_load, the vmstate_load_state will return
  error in the following case.

  The virtio is legacy mode(disable-modern=on,disable-legacy=off),
  virtio_device is in reset state.

  In the the function of "vmstate_load_state", it will load all subsection. For 
the vmstate_virtio_extra_state subsection. 
  It will execute:
  vmstate_load_state   -->
ret = field->info->get(f, curr_elem, size, field);line 143  
vmstate.c.
 -->virtio_pci_load_extra_state
  -->  vmstate_load_state
   -->qemu_peek_byte
  But if the f->buf_index is same with buf_size, qemu_peek_byte function will 
set "-EIO" error. 
  the field->info->get will return 0, then it will get the error "ret = 
qemu_file_get_error(f);". then the vmstate_load_state will return error.

  It output is "Failed to load virtio/extra_state:extra_state"

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

[Bug 1902306] Re: Allow setting usb storage device ID parameters

[Thomas Huth]

** Tags added: usb

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

Title:
  Allow setting usb storage device ID parameters

Status in QEMU:
  New

Bug description:
  Some stubborn software requires certain VID/PID/Serial to authenticate
  and refuses to start in emulation. This poses a problem with
  unsupported programs which often require keeping an ancient hardware
  praying that the USB stick will not die before the (often defunct)
  company making it.

  Virtualizing such environment is desired. However, QEMU doesn't allow
  setting VID/PID/Serial/Name of emulated USB devices, but instead uses
  hardcoded values:
  
https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb
  /dev-storage.c#L95

  This request (including a patch) was already made in 2015 on the list
  but never got any response: https://lists.nongnu.org/archive/html
  /qemu-discuss/2015-07/msg00072.html

  
  WDYT of adding such functionality?

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

[Bug 1903493] Re: About wireless network card bridging

[Thomas Huth]

Sorry, but at least I have a hard time to understand what you exactly
are requesting here? Why should bridging via a wireless card on the host
be much different to bridging via an ethernet interface on the host? Or
do you expect to see a wireless network card in the guest?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  About wireless network card bridging

Status in QEMU:
  Incomplete

Bug description:
  As a rookie, I don’t know if I should ask this question here. If it’s
  not right, I hope people who see it can help submit it to the right
  place.Can Qemu or kvm add wireless network card bridging ? after all,
  now you see that vbox and vmware can directly choose wireless network
  card bridging, and even hyper-v can be easily set up, arp proxy is too
  difficult for us rookies . I hope that qemu or other links can add a
  function to bridge the wireless network card, which can be directly
  set in virt-manager (for so many years, it seems that I can only use
  bridge-utils to bridge the Ethernet,and Now more and more laptops
  don't have Ethernet ports)

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