date:20210506

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1887306

Title:
  qemu-user deadlocks when forked in a multithreaded process

Status in QEMU:
  Incomplete

Bug description:
  The following program (also attached) deadlocks when run under QEMU
  user on Linux.

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

  #define NUM_THREADS 100
  #define NUM_FORKS 10

  pthread_barrier_t barrier;

  void *t(void *arg) {
  for (int i = 0; i < NUM_FORKS; i++) {
  pid_t pid = fork();
  if (pid < 0)
  abort();
  if (!pid)
  _exit(0);
  if (waitpid(pid, NULL, 0) < 0)
  abort();
  }
  //pthread_barrier_wait();
  return NULL;
  }

  int main(void) {
  pthread_barrier_init(, NULL, NUM_THREADS);
  pthread_t ts[NUM_THREADS];
  for (size_t i = 0; i < NUM_THREADS; i++) {
  if (pthread_create([i], NULL, t, NULL))
  abort();
  }
  for (size_t i = 0; i < NUM_THREADS; i++) {
  pthread_join(ts[i], NULL);
  }
  printf("Done: %d\n", getpid());
  return 0;
  }

  To reproduce:
  $ gcc test.c -pthread
  $ while qemu-x86_64 ./a.out; do :; done

  (Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child).

  Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks.
  With the values above it often deadlocks on the first try on my
  machine. When it deadlocks, there is a child qemu process with two
  threads which is waited upon by one of the worker threads of the
  parent.

  I tried to avoid the deadlock by serializing fork() with a mutex, but
  it didn't help. However, ensuring that no thread exits until all forks
  are done (by adding a barrier to t()) does seem to help, at least, the
  program above could run for a half an hour until I terminated it.

  Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-
  user targets.

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

[Bug 1887604] Re: Forward host UNIX socket to guest TCP port

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1887604

Title:
  Forward host UNIX socket to guest TCP port

Status in QEMU:
  Incomplete

Bug description:
  Hello. I've been racking my brain trying to work out if this is
  possible.

  I would like to be able to forward to a guest TCP port, via a host
  UNIX socket to avoid opening a TCP port on the host. For example:

  qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22

  and then connect to the VM like:

  ssh -o "ProxyCommand socat - unix-connect:/path/to/socket"
  user@0.0.0.0

  QEMU, as versatile as it is, doesn't appreciate my intuited syntax
  "hostfwd=unix:...". It is also unhappy with:

  qemu-system-i386 [...] \
  -chardev socket,id=foo,path=/path/to/socket,server,nowait \
  -nic user,hostfwd=chardev:foo-:22

  And:

  qemu-system-i386 [...] \
  -nic user \
  -chardev socket,id=foo,path=/path/to/socket,server,nowait \
  -chardev socket,id=foo,host=10.0.2.15,port=22

  I already found out how to connect in the opposite direction, **from**
  guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like
  there ought to be a way.

  If this is not yet a feature I would like to request it, and if it is,
  please tell me how!

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

[Bug 1888303] Re: Intermittent buggines with user mode emulation of x86-64 on aarch64

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1888303

Title:
Intermittent buggines with user mode emulation of x86-64 on aarch64

Status in QEMU:
Incomplete

Bug description:
QEMU Version: 5.0.0
./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu
--static

Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm

aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built
for 4KB memory pages.

On aarch64 machine, invoke:

./qemu-x86_64-static /usr/local/percona/pmm-
client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000
-web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-
file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-
file=/usr/local/percona/pmm-client/server.crt

-collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile

Most of the time it will outright segfault within a few seconds,
seemingly when the prometheus server polls for data.

But, about once every 10 times, it will not sefault and will continue
working just fine forever.

The dynamically linked version of qemu (built without --static) always
works without segfaulting, but it just doesn't work, the prometheus
server gets no data from it. Again, once in a while it will work, but
even when it doesn't work it won't segfault.

This vaguely feels like a memory alignment issue somewhere, but my
debug-fu is not quite strong enough to attack the problem.

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

[Bug 1888467] Re: qemu-img http convert bug

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1888467

Title:
  qemu-img http convert bug

Status in QEMU:
  Incomplete

Bug description:
  Hello, Why the file sizes of http conversion and local conversion are
  inconsistent?

  Use the http method of qemu-img for conversion. The size of some formats 
after conversion is different from the local method of qemu-img. Such as vhd, 
vdi. qcow2 and vmdk are normal。
  My image size is 40 G, raw format.

  The source is the same file, but the access method is different
  http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx 
xxx.vdi（19G，after conversion）
  local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw 
xxx.vdi（3G，after conversion）

  thank you

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

[Bug 1888417] Re: Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot.

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1888417

Title:
  Latest QEMU git build on Arch linux causes PCI Passthrough host to
  hang on guest reboot.

Status in QEMU:
  Incomplete

Bug description:
  Current Arch linux release, up-to-date as of 7/21/2020.

  Running a windows 7 virtual machine (also happens with windows 10,
  possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is
  attempted to be restarted, either through the guest interface, or by
  libvirt's gui interface "Virtual Machine Manager", it hangs in a
  "paused" state once the VM shutsdown, and just before the reboot can
  take place.  A force-stop of the VM allows the VM to be properly
  booted without any disk error checks, alluding to a clean shutdown,
  but failed reboot.  The VM can be properly shutdown using the guests
  shutdown function, or the libvirt manager shutdown, without any hangs.
  Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue.

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

[Bug 1873339] Re: Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA palette in dos prompt and game crashing are not working

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1873339

Title:
  Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA
  palette in dos prompt and game crashing are not working

Status in QEMU:
  Incomplete

Bug description:
  I have problem make Quake Demo working with 640x480+, with 320x200 working 
fine.
  I tried 3 virtual videocards settings: -vga cirrus 640x480 is not available, 
probably emulated GPU has not enough VRAM or some Vesa2 utility is needed. For 
-vga std and -vga vmware // 640x480 is available in game menu, but when i tried 
to set it, im getting: Unable to load VESA palette in dos prompt and game 
crashing.
  With vmware svgaII other Q2DOS 640x480 and 1024x768 its working fine, so it 
not working only with some games.

Qemu 4.2, its same on Linux and Windows.

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

Re: [PATCH v3 1/4] hw/ppc: moved hcalls that depend on softmmu

On Thu, May 06, 2021 at 01:39:38PM -0300, Lucas Mateus Castro (alqotel) wrote:
> The hypercalls h_enter, h_remove, h_bulk_remove, h_protect, and h_read,
> have been moved to spapr_softmmu.c with the functions they depend on. The
> functions is_ram_address and push_sregs_to_kvm_pr are not static anymore
> as functions on both spapr_hcall.c and spapr_softmmu.c depend on them.
> The hypercalls h_resize_hpt_prepare and h_resize_hpt_commit have been
> divided, the KVM part stayed in spapr_hcall.c while the softmmu part
> was moved to spapr_softmmu.c
> 
> Signed-off-by: Lucas Mateus Castro (alqotel)
> 

Applied to ppc-for-6.1, thanks.

> ---
>  hw/ppc/meson.build |   3 +
>  hw/ppc/spapr_hcall.c   | 608 +++
>  hw/ppc/spapr_softmmu.c | 627 +
>  include/hw/ppc/spapr.h |   6 +
>  4 files changed, 668 insertions(+), 576 deletions(-)
>  create mode 100644 hw/ppc/spapr_softmmu.c
> 
> diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
> index 86d6f379d1..597d974dd4 100644
> --- a/hw/ppc/meson.build
> +++ b/hw/ppc/meson.build
> @@ -29,6 +29,9 @@ ppc_ss.add(when: 'CONFIG_PSERIES', if_true: files(
>'spapr_numa.c',
>'pef.c',
>  ))
> +ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_TCG'], if_true: files(
> +  'spapr_softmmu.c',
> +))
>  ppc_ss.add(when: 'CONFIG_SPAPR_RNG', if_true: files('spapr_rng.c'))
>  ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_LINUX'], if_true: files(
>'spapr_pci_vfio.c',
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 7275d0bba1..62dd015b70 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -27,18 +27,7 @@ static bool has_spr(PowerPCCPU *cpu, int spr)
>  return cpu->env.spr_cb[spr].name != NULL;
>  }
>  
> -static inline bool valid_ptex(PowerPCCPU *cpu, target_ulong ptex)
> -{
> -/*
> - * hash value/pteg group index is normalized by HPT mask
> - */
> -if (((ptex & ~7ULL) / HPTES_PER_GROUP) & ~ppc_hash64_hpt_mask(cpu)) {
> -return false;
> -}
> -return true;
> -}
> -
> -static bool is_ram_address(SpaprMachineState *spapr, hwaddr addr)
> +bool is_ram_address(SpaprMachineState *spapr, hwaddr addr)
>  {
>  MachineState *machine = MACHINE(spapr);
>  DeviceMemoryState *dms = machine->device_memory;
> @@ -54,355 +43,6 @@ static bool is_ram_address(SpaprMachineState *spapr, 
> hwaddr addr)
>  return false;
>  }
>  
> -static target_ulong h_enter(PowerPCCPU *cpu, SpaprMachineState *spapr,
> -target_ulong opcode, target_ulong *args)
> -{
> -target_ulong flags = args[0];
> -target_ulong ptex = args[1];
> -target_ulong pteh = args[2];
> -target_ulong ptel = args[3];
> -unsigned apshift;
> -target_ulong raddr;
> -target_ulong slot;
> -const ppc_hash_pte64_t *hptes;
> -
> -apshift = ppc_hash64_hpte_page_shift_noslb(cpu, pteh, ptel);
> -if (!apshift) {
> -/* Bad page size encoding */
> -return H_PARAMETER;
> -}
> -
> -raddr = (ptel & HPTE64_R_RPN) & ~((1ULL << apshift) - 1);
> -
> -if (is_ram_address(spapr, raddr)) {
> -/* Regular RAM - should have WIMG=0010 */
> -if ((ptel & HPTE64_R_WIMG) != HPTE64_R_M) {
> -return H_PARAMETER;
> -}
> -} else {
> -target_ulong wimg_flags;
> -/* Looks like an IO address */
> -/* FIXME: What WIMG combinations could be sensible for IO?
> - * For now we allow WIMG=010x, but are there others? */
> -/* FIXME: Should we check against registered IO addresses? */
> -wimg_flags = (ptel & (HPTE64_R_W | HPTE64_R_I | HPTE64_R_M));
> -
> -if (wimg_flags != HPTE64_R_I &&
> -wimg_flags != (HPTE64_R_I | HPTE64_R_M)) {
> -return H_PARAMETER;
> -}
> -}
> -
> -pteh &= ~0x60ULL;
> -
> -if (!valid_ptex(cpu, ptex)) {
> -return H_PARAMETER;
> -}
> -
> -slot = ptex & 7ULL;
> -ptex = ptex & ~7ULL;
> -
> -if (likely((flags & H_EXACT) == 0)) {
> -hptes = ppc_hash64_map_hptes(cpu, ptex, HPTES_PER_GROUP);
> -for (slot = 0; slot < 8; slot++) {
> -if (!(ppc_hash64_hpte0(cpu, hptes, slot) & HPTE64_V_VALID)) {
> -break;
> -}
> -}
> -ppc_hash64_unmap_hptes(cpu, hptes, ptex, HPTES_PER_GROUP);
> -if (slot == 8) {
> -return H_PTEG_FULL;
> -}
> -} else {
> -hptes = ppc_hash64_map_hptes(cpu, ptex + slot, 1);
> -if (ppc_hash64_hpte0(cpu, hptes, 0) & HPTE64_V_VALID) {
> -ppc_hash64_unmap_hptes(cpu, hptes, ptex + slot, 1);
> -return H_PTEG_FULL;
> -}
> -ppc_hash64_unmap_hptes(cpu, hptes, ptex, 1);
> -}
> -
> -spapr_store_hpte(cpu, ptex + slot, pteh | HPTE64_V_HPTE_DIRTY, ptel);
> -
> -args[0] = ptex + slot;
> -return H_SUCCESS;
> -}
> -
> -typedef enum {
> -REMOVE_SUCCESS = 0,
> -REMOVE_NOT_FOUND = 1,
> -

Re: [PATCH v3 4/4] hw/ppc: Altered calls from oea_read to read

On Thu, May 06, 2021 at 01:39:41PM -0300, Lucas Mateus Castro (alqotel) wrote:
> Changed spapr.c and pnv.c from calls of ppc_spr_t.oea_read to
> ppc_spr_t.name as oea_read is not available in !TCG builds.

This is correct, but I think we can do it a little more cleanly.  This
logic is identical to has_spr() in spapr_hcall.c.

Can you move has_spr() to the target/ppc logic instead and rename it
to, say, ppc_has_spr().  It's simple enough that it could just go
inline in target/ppc/cpu.h.  Then we can use that in these places as
well as the places its used in spapr_hcall.c.

> 
> Signed-off-by: Lucas Mateus Castro (alqotel) 
> ---
>  hw/ppc/pnv.c   | 2 +-
>  hw/ppc/spapr.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 77af846cdf..06849b8802 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -199,7 +199,7 @@ static void pnv_dt_core(PnvChip *chip, PnvCore *pc, void 
> *fdt)
>  _FDT((fdt_setprop_string(fdt, offset, "status", "okay")));
>  _FDT((fdt_setprop(fdt, offset, "64-bit", NULL, 0)));
>  
> -if (env->spr_cb[SPR_PURR].oea_read) {
> +if (env->spr_cb[SPR_PURR].name) {
>  _FDT((fdt_setprop(fdt, offset, "ibm,purr", NULL, 0)));
>  }
>  
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b37ceb8ee8..61653cbe2e 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -705,10 +705,10 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
> offset,
>  _FDT((fdt_setprop_string(fdt, offset, "status", "okay")));
>  _FDT((fdt_setprop(fdt, offset, "64-bit", NULL, 0)));
>  
> -if (env->spr_cb[SPR_PURR].oea_read) {
> +if (env->spr_cb[SPR_PURR].name) {
>  _FDT((fdt_setprop_cell(fdt, offset, "ibm,purr", 1)));
>  }
> -if (env->spr_cb[SPR_SPURR].oea_read) {
> +if (env->spr_cb[SPR_SPURR].name) {
>  _FDT((fdt_setprop_cell(fdt, offset, "ibm,spurr", 1)));
>  }
>  

-- 
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 v3 2/4] target/ppc: moved function out of mmu-hash64

On Thu, May 06, 2021 at 01:39:39PM -0300, Lucas Mateus Castro (alqotel) wrote:
> The function ppc_hash64_filter_pagesizes has been moved from a function
> with prototype in mmu-hash64.h and implemented in mmu-hash64.c to
> a static function in hw/ppc/spapr_caps.c as it's only used in that file.
> 
> Signed-off-by: Lucas Mateus Castro (alqotel)
> 

Applied to ppc-for-6.1, thanks.

> ---
>  hw/ppc/spapr_caps.c | 59 +
>  target/ppc/mmu-hash64.c | 57 ---
>  target/ppc/mmu-hash64.h |  3 ---
>  3 files changed, 59 insertions(+), 60 deletions(-)
> 
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index 9ea7ddd1e9..d0c419b392 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -371,6 +371,65 @@ static bool spapr_pagesize_cb(void *opaque, uint32_t 
> seg_pshift,
>  return true;
>  }
>  
> +static void ppc_hash64_filter_pagesizes(PowerPCCPU *cpu,
> + bool (*cb)(void *, uint32_t, uint32_t),
> + void *opaque)
> +{
> +PPCHash64Options *opts = cpu->hash64_opts;
> +int i;
> +int n = 0;
> +bool ci_largepage = false;
> +
> +assert(opts);
> +
> +n = 0;
> +for (i = 0; i < ARRAY_SIZE(opts->sps); i++) {
> +PPCHash64SegmentPageSizes *sps = >sps[i];
> +int j;
> +int m = 0;
> +
> +assert(n <= i);
> +
> +if (!sps->page_shift) {
> +break;
> +}
> +
> +for (j = 0; j < ARRAY_SIZE(sps->enc); j++) {
> +PPCHash64PageSize *ps = >enc[j];
> +
> +assert(m <= j);
> +if (!ps->page_shift) {
> +break;
> +}
> +
> +if (cb(opaque, sps->page_shift, ps->page_shift)) {
> +if (ps->page_shift >= 16) {
> +ci_largepage = true;
> +}
> +sps->enc[m++] = *ps;
> +}
> +}
> +
> +/* Clear rest of the row */
> +for (j = m; j < ARRAY_SIZE(sps->enc); j++) {
> +memset(>enc[j], 0, sizeof(sps->enc[j]));
> +}
> +
> +if (m) {
> +n++;
> +}
> +}
> +
> +/* Clear the rest of the table */
> +for (i = n; i < ARRAY_SIZE(opts->sps); i++) {
> +memset(>sps[i], 0, sizeof(opts->sps[i]));
> +}
> +
> +if (!ci_largepage) {
> +opts->flags &= ~PPC_HASH64_CI_LARGEPAGE;
> +}
> +}
> +
>  static void cap_hpt_maxpagesize_cpu_apply(SpaprMachineState *spapr,
>PowerPCCPU *cpu,
>uint8_t val, Error **errp)
> diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
> index d517a99832..be3596f27b 100644
> --- a/target/ppc/mmu-hash64.c
> +++ b/target/ppc/mmu-hash64.c
> @@ -1200,61 +1200,4 @@ const PPCHash64Options ppc_hash64_opts_POWER7 = {
>  }
>  };
>  
> -void ppc_hash64_filter_pagesizes(PowerPCCPU *cpu,
> - bool (*cb)(void *, uint32_t, uint32_t),
> - void *opaque)
> -{
> -PPCHash64Options *opts = cpu->hash64_opts;
> -int i;
> -int n = 0;
> -bool ci_largepage = false;
> -
> -assert(opts);
> -
> -n = 0;
> -for (i = 0; i < ARRAY_SIZE(opts->sps); i++) {
> -PPCHash64SegmentPageSizes *sps = >sps[i];
> -int j;
> -int m = 0;
>  
> -assert(n <= i);
> -
> -if (!sps->page_shift) {
> -break;
> -}
> -
> -for (j = 0; j < ARRAY_SIZE(sps->enc); j++) {
> -PPCHash64PageSize *ps = >enc[j];
> -
> -assert(m <= j);
> -if (!ps->page_shift) {
> -break;
> -}
> -
> -if (cb(opaque, sps->page_shift, ps->page_shift)) {
> -if (ps->page_shift >= 16) {
> -ci_largepage = true;
> -}
> -sps->enc[m++] = *ps;
> -}
> -}
> -
> -/* Clear rest of the row */
> -for (j = m; j < ARRAY_SIZE(sps->enc); j++) {
> -memset(>enc[j], 0, sizeof(sps->enc[j]));
> -}
> -
> -if (m) {
> -n++;
> -}
> -}
> -
> -/* Clear the rest of the table */
> -for (i = n; i < ARRAY_SIZE(opts->sps); i++) {
> -memset(>sps[i], 0, sizeof(opts->sps[i]));
> -}
> -
> -if (!ci_largepage) {
> -opts->flags &= ~PPC_HASH64_CI_LARGEPAGE;
> -}
> -}
> diff --git a/target/ppc/mmu-hash64.h b/target/ppc/mmu-hash64.h
> index 87729d48b3..5dfd7f8b93 100644
> --- a/target/ppc/mmu-hash64.h
> +++ b/target/ppc/mmu-hash64.h
> @@ -18,9 +18,6 @@ unsigned ppc_hash64_hpte_page_shift_noslb(PowerPCCPU *cpu,
>  void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val);
>  void ppc_hash64_init(PowerPCCPU *cpu);
>  void ppc_hash64_finalize(PowerPCCPU *cpu);
> -void ppc_hash64_filter_pagesizes(PowerPCCPU *cpu,
> - bool (*cb)(void

Re: [PATCH v3 3/4] target/ppc: moved ppc_store_lpcr to misc_helper.c

On Thu, May 06, 2021 at 01:39:40PM -0300, Lucas Mateus Castro (alqotel) wrote:
> Moved the function ppc_store from mmu-hash64.c to misc_helper.c and the
> prototype from mmu-hash64.h to cpu.h as it is a more appropriate place,
> but it will have to have its implementation moved to a new file as
> misc_helper.c should not be compiled in a !TCG environment.
> 
> Signed-off-by: Lucas Mateus Castro (alqotel)
> 

Applied to ppc-for-6.1, thanks.

> ---
>  target/ppc/cpu.h |  1 +
>  target/ppc/misc_helper.c | 10 ++
>  target/ppc/mmu-hash64.c  | 10 --
>  target/ppc/mmu-hash64.h  |  1 -
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 733a2168c4..a976e7f7b0 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1297,6 +1297,7 @@ void ppc_store_sdr1(CPUPPCState *env, target_ulong 
> value);
>  void ppc_store_ptcr(CPUPPCState *env, target_ulong value);
>  #endif /* !defined(CONFIG_USER_ONLY) */
>  void ppc_store_msr(CPUPPCState *env, target_ulong value);
> +void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val);
>  
>  void ppc_cpu_list(void);
>  
> diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
> index 002958be26..08a31da289 100644
> --- a/target/ppc/misc_helper.c
> +++ b/target/ppc/misc_helper.c
> @@ -261,6 +261,16 @@ void ppc_store_msr(CPUPPCState *env, target_ulong value)
>  hreg_store_msr(env, value, 0);
>  }
>  
> +void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val)
> +{
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +CPUPPCState *env = >env;
> +
> +env->spr[SPR_LPCR] = val & pcc->lpcr_mask;
> +/* The gtse bit affects hflags */
> +hreg_compute_hflags(env);
> +}
> +
>  /*
>   * This code is lifted from MacOnLinux. It is called whenever THRM1,2
>   * or 3 is read an fixes up the values in such a way that will make
> diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
> index be3596f27b..c4a4bc7cd2 100644
> --- a/target/ppc/mmu-hash64.c
> +++ b/target/ppc/mmu-hash64.c
> @@ -1120,16 +1120,6 @@ void ppc_hash64_tlb_flush_hpte(PowerPCCPU *cpu, 
> target_ulong ptex,
>  cpu->env.tlb_need_flush = TLB_NEED_GLOBAL_FLUSH | TLB_NEED_LOCAL_FLUSH;
>  }
>  
> -void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val)
> -{
> -PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> -CPUPPCState *env = >env;
> -
> -env->spr[SPR_LPCR] = val & pcc->lpcr_mask;
> -/* The gtse bit affects hflags */
> -hreg_compute_hflags(env);
> -}
> -
>  void helper_store_lpcr(CPUPPCState *env, target_ulong val)
>  {
>  PowerPCCPU *cpu = env_archcpu(env);
> diff --git a/target/ppc/mmu-hash64.h b/target/ppc/mmu-hash64.h
> index 5dfd7f8b93..4b8b8e7950 100644
> --- a/target/ppc/mmu-hash64.h
> +++ b/target/ppc/mmu-hash64.h
> @@ -15,7 +15,6 @@ void ppc_hash64_tlb_flush_hpte(PowerPCCPU *cpu,
> target_ulong pte0, target_ulong pte1);
>  unsigned ppc_hash64_hpte_page_shift_noslb(PowerPCCPU *cpu,
>uint64_t pte0, uint64_t pte1);
> -void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val);
>  void ppc_hash64_init(PowerPCCPU *cpu);
>  void ppc_hash64_finalize(PowerPCCPU *cpu);
>  #endif

-- 
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 1885247] Re: Build error in Intel 32-bit hosts

Fix had been included here:
https://gitlab.com/qemu-project/qemu/-/commit/8b39aa90e90
... thus closing this ticket now.

** 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/1885247

Title:
  Build error in Intel 32-bit hosts

Status in QEMU:
  Fix Released

Bug description:
  The code base is on master, checked out on Thursday June25th 2020,
  0250c595c9d. The build procedure:

  $ mkdir build-gcc
  $ cd build-gcc
  $ ../configure
  $ make

  The build error message is:

CC  x86_64-softmmu/hw/hyperv/hyperv.o
CC  x86_64-softmmu/hw/hyperv/hyperv_testdev.o
CC  x86_64-softmmu/hw/hyperv/vmbus.o
  /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’:
  /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer 
from integer of different size [-Werror=int-to-pointer-cast]
   p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | 
off_in_page);
   ^
  cc1: all warnings being treated as errors
  make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] 
Error 1
  make: *** [Makefile:527: x86_64-softmmu/all] Error 2

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

[Bug 1885553] Re: make-check test failed with "Segmentation fault"

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1885553

Title:
  make-check test failed with "Segmentation fault"

Status in QEMU:
  Incomplete

Bug description:
  While running the make-check testing on arm architecture the test failed with 
error:
  "kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core 
dumped)". Apart from that make-install test always passes.
  The problem doesn't reproduce in 100%
  qemu - from the master branch
  RHEL-8 kernel 4.18.0-221.el8.aarch64
  Logfile with an error you can to find in attachment

  Thanks

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

[Bug 1885827] Re: building plugin failed on Windows with mingw

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1885827

Title:
  building plugin failed on Windows with mingw

Status in QEMU:
  Incomplete

Bug description:
  I want to build QEMU 4.2.0's plugin module on Windows 7/10 with Mingw, but 
the building process faild.
   
  The step I follow is listed below:
  1. create "dsp_build" diretory under source file folder

  2.  change directory to dsp_build , and run ../configure 
--target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk 
--enable-sdl --enable-debug --enable-plugins
  3. build qemu project
  4. switch dir to /dsp_build, make -C tests/plugin, yeilds error: 
 CC  bb.o
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: 
error: variable 'qemu_plugin_version' definition is marked dllimport
 17 | QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
|^~~
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: 
warning: 'qemu_plugin_version' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In 
function 'vcpu_tb_exec':
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:33:29: 
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 33 | unsigned long n_insns = (unsigned long)udata;
| ^
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In 
function 'vcpu_tb_trans':
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:51:46: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
 51 |  (void *)n_insns);

  5.  Then , I modified the QEMU_flags and the compilation command
  arguments($(CC) ..) in  the  makefile :

  BUILD_DIR := $(CURDIR)/../..

include $(BUILD_DIR)/config-host.mak
include $(SRC_PATH)/rules.mak

  $(call set-vpath, $(SRC_PATH)/tests/plugin)

NAMES :=
NAMES += bb
NAMES += empty
NAMES += insn
NAMES += mem
NAMES += hotblocks
NAMES += howvec
NAMES += hotpages

  SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES)))

QEMU_CFLAGS += -fPIC-DBUILDING_DLL  #added  
-DBUILDING_DLL
QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu

  all: $(SONAMES)

lib%.so: %.o
$(CC) -fPIC -shared -o $@ $^ $(LDLIBS) -L 
/c/msys64/mingw64/lib/ -lglib-2.0
# original cmd: $(CC) -shared -Wl,-soname,$@ -o $@ $^ 
$(LDLIBS)

clean:
rm -f *.o *.so *.d
rm -Rf .libs

  .PHONY: all clean

  6.  Executing make yeilds:

  make: enter   
“/d/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/build_dsp/tests/plugin”
CC  bb.o
  x86_64-w64-mingw32-gcc -fPIC -shared -o libbb.so bb.o  -L 
/c/msys64/mingw64/lib/ -lglib-2.0
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 bb.o: in function `plugin_exit':
  D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:28: 
undefined reference to `qemu_plugin_outs'

[Bug 1885332] Re: Error in user-mode calculation of ELF aux vector's AT_PHDR

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1885332

Title:
  Error in user-mode calculation of ELF aux vector's AT_PHDR

Status in QEMU:
  Incomplete

Bug description:
  
  I have an (admittedly strange) statically-linked ELF binary for Linux that 
runs just fine on top of the Linux kernel in QEMU full-system emulation, but 
crashes before main in user-mode emulation. Specifically, it crashes when 
initializing thread-local storage in glibc's _dl_aux_init, because it reads out 
a strange value from the AT_PHDR entry of the ELF aux vector.

  The binary has these program headers:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX  0x065874 0x00075874 0x00075874 0x00570 0x00570 R   0x4
  PHDR   0x0a3000 0x0090 0x0090 0x00160 0x00160 R   0x1000
  LOAD   0x0a3000 0x0090 0x0090 0x00160 0x00160 R   0x1000
  LOAD   0x00 0x0001 0x0001 0x65de8 0x65de8 R E 0x1
  LOAD   0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x1
  NOTE   0x000114 0x00010114 0x00010114 0x00044 0x00044 R   0x4
  TLS0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x8
  GNU_RELRO  0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R   0x1
  LOAD   0x07e000 0x00089000 0x00089000 0x03f44 0x03f44 R E 0x1000
  LOAD   0x098000 0x0003 0x0003 0x01000 0x01000 RW  0x1000

  If I build the Linux kernel with the following patch to the very end
  of create_elf_tables in fs/binfmt_elf.c

/* Put the elf_info on the stack in the right place.  */
elf_addr_t *my_auxv = (elf_addr_t *) mm->saved_auxv;
int i;
for (i = 0; i < 15; i++) {
  printk("0x%x = 0x%x", my_auxv[2*i], my_auxv[(2*i)+ 1]);
}
if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t)))
return -EFAULT;
return 0;

  and run it like this:

qemu-system-arm \
  -M versatilepb \
  -nographic \
  -dtb ./dts/versatile-pb.dtb \
  -kernel zImage \
  -M versatilepb \
  -m 128M \
  -append "earlyprintk=vga,keep" \
  -initrd initramfs

  after I've built the kernel initramfs like this (where "init" is the
  binary in question):

make ARCH=arm versatile_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all -j10
cp "$1" arch/arm/boot/init
cd arch/arm/boot
echo init | cpio -o --format=newc > initramfs

  then I get the following output. This is the kernel's view of the aux
  vector for this binary:

0x10 = 0x1d7
0x6 = 0x1000
0x11 = 0x64
0x3 = 0x90
0x4 = 0x20
0x5 = 0xb
0x7 = 0x0
0x8 = 0x0
0x9 = 0x101b8
0xb = 0x0
0xc = 0x0
0xd = 0x0
0xe = 0x0
0x17 = 0x0
0x19 = 0xbec62fb5

  However, if I run "qemu-arm -g 12345 binary" and use GDB to peek at
  the aux vector at the beginning of __libc_start_init (for example,
  using this Python GDB API script: https://gist.github.com/langston-
  barrett/5573d64ae0c9953e2fa0fe26847a5e1e), then I see the following
  values:

AT_PHDR = 0xae000
AT_PHENT = 0x20
AT_PHNUM = 0xb
AT_PAGESZ = 0x1000
AT_BASE = 0x0
AT_FLAGS = 0x0
AT_ENTRY = 0x10230
AT_UID = 0x3e9
AT_EUID = 0x3e9
AT_GID = 0x3e9
AT_EGID = 0x3e9
AT_HWCAP = 0x1fb8d7
AT_CLKTCK = 0x64
AT_RANDOM = -0x103c0
AT_HWCAP2 = 0x1f
AT_NULL = 0x0

  The crucial difference is in AT_PHDR (0x3), which is indeed the
  virtual

[Bug 1886155] Re: error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1886155

Title:
  error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier

Status in QEMU:
  Incomplete

Bug description:
  GCC 11 reports the following errors:

  [  125s] In file included from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/seqlock.h:17,
  [  125s]  from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/qht.h:10,
  [  125s]  from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:69:
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_do_lookup':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:499:27: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   499 | void *p = atomic_rcu_read(>pointers[i]);
  [  125s]   |   ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:506:13: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   506 | b = atomic_rcu_read(>next);
  [  125s]   | ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_lookup_custom':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:534:11: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   534 | map = atomic_rcu_read(>map);
  [  125s]   |   ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_statistics_init':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 |

[Bug 1886097] Re: Error in user-mode calculation of ELF program's brk

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus won't get notified on changes anymore).

Thank you and sorry for the inconvenience.


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

** Tags added: linux-user

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

Title:
  Error in user-mode calculation of ELF program's brk

Status in QEMU:
  Incomplete

Bug description:
  There's a discrepancy between the way QEMU user-mode and Linux
  calculate the initial program break for statically-linked binaries. I
  have a binary with the following segments:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX  0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R   0x4
  PHDR   0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
  LOAD   0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
  LOAD   0x00 0x0001 0x0001 0x65fa0 0x65fa0 R E 0x1
  LOAD   0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x1
  NOTE   0x000114 0x00010114 0x00010114 0x00044 0x00044 R   0x4
  TLS0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x8
  GNU_RELRO  0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R   0x1
  LOAD   0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000
  LOAD   0x098000 0x0003 0x0003 0x01000 0x01000 RW  0x1000

  The call to set_brk in Linux's binfmt_elf.c receives these arguments:

set_brk(0xa3160, 0xa3160, 1)

  Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in 
QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM 
hardware. I think the trouble is that the program break is set to an address 
lower than the virtual address of a LOAD segment (the program headers, in this 
case).

  I believe that this discrepancy arises because in QEMU, info->brk is
  only incremented when the LOAD segment in question has PROT_WRITE. For
  this binary, the LOAD segment with write permissions and the highest
  virtual address is

LOAD   0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x1
  
  which overlaps with the TLS segment:

  TLS0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
  
  However, the Linux kernel puts the program break after the loadable segment 
with the highest virtual address, regardless of flags. So I think the fix is 
for QEMU to do the same.

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

[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

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 older bugs 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.

Thank you and sorry for the inconvenience.

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

** 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/1884684

Title:
QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Status in QEMU:
Incomplete

Bug description:
Setup:

Host: Debian/SID, Kernel 5.6, QEMU 5.0
Guest: Windows 10 VM with PCI and USB device passthrough.

Problem: Guest VM suddenly hangs when pulling USB device out from the
Host.

Observations:
- Issue appears to be related to QEMU 5.0
- It started after an upgrade to QEMU 5.0.
- Downgrading only QEMU on multiple systems fixes the issue.

- Issue is very reproducible.
- Most of the time within a few attempts of pulling/reconnecting the
device.
- Issue happens with multiple devices (I did try standard HID devices, a
webcam and an x-ray sensor).

- Guest just hangs.
- Display output remains on last frame shown.
- Ping to Guest immediately stops working.
- Logs in the Guest stop logging immediately.

- Host is fine and thinks the Guest is fine.
- Guest continues to show as running in "virsh list".
- No suspicious entries in the QEMU logs.
- No suspicious entries in Host syslogs/messages.
- Host can can kill guest "virsh destroy" and respawn fine.

- Issue seems widespread.
- Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2
for both Windows and Linux guests (First version that uses QEMU 5.0)

https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/
https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/

https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/

https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/

https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/

I'd be more than happy any debugs that might be helpful.

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

[Bug 1886285] Re: Provide SMB option to support Windows 2000

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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus won't get notified on changes anymore).

Thank you and sorry for the inconvenience.


** Tags added: feature-request

** 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/1886285

Title:
  Provide SMB option to support Windows 2000

Status in QEMU:
  Incomplete

Bug description:
  As of SAMBA 4.11
  (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is
  disabled by default (and may be removed in the future). This breaks
  SMB shares with Windows 2000 guests.

  Adding the following line to smb.conf fixes this:

  min protocol = NT1

  I would propose that an option be added to add this line to smb.conf
  to support these legacy operating systems.

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

[Bug 1884017] Re: Intermittently erratic mouse under Windows 95

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1884017

Title:
  Intermittently erratic mouse under Windows 95

Status in QEMU:
  Incomplete

Bug description:
  The mouse works fine maybe 75-80% of the time, but intermittently
  (every 20-30 seconds or so), moving the mouse will cause the pointer
  to fly around the screen at high speed, usually colliding with the
  edges, and much more problematically, click all the mouse buttons at
  random, even if you are not clicking. This causes random objects on
  the screen to be clicked and dragged around, rendering the system
  generally unusable.

  I don't know if this is related to #1785485 - it happens even if you
  never use the scroll wheel.

  qemu version: 5.0.0 (openSUSE Tumbleweed)

  Launch command line: qemu-system-i386 -hda win95.qcow2 -cpu pentium2
  -m 16 -vga cirrus -soundhw sb16 -nic user,model=pcnet -rtc
  base=localtime

  OS version: Windows 95 4.00.950 C

  I have made the disk image available here:
  https://home.gloveraoki.me/share/win95.qcow2.lz

  Setup notes: In order to make Windows 95 detect the system devices
  correctly, after first install you must change the driver for "Plug
  and Play BIOS" to "PCI bus". I have already done this in the above
  image.

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

[Bug 1885175] Re: memory.c range assertion hit at full invalidating

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1885175

Title:
  memory.c range assertion hit at full invalidating

Status in QEMU:
  Incomplete

Bug description:
  I am able to hit this assertion when a Red Hat 7 guest virtio_net
  device raises an "Invalidation" of all the TLB entries. This happens
  in the guest's startup if 'intel_iommu=on' argument is passed to the
  guest kernel and right IOMMU/ATS devices are declared in qemu's
  command line.

  Command line: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -name
  guest=rhel7-test,debug-threads=on -machine
  pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,kernel_irqchip=split
  -cpu
  Broadwell,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on
  ,tsc-adjust=on,umip=on,arch-
  capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-
  vmentry=on,rtm=on,hle=on -m 8096 -realtime mlock=off -smp
  2,sockets=2,cores=1,threads=1 -uuid d022ecbf-679e-4755-87ce-
  eb87fc5bbc5d -display none -no-user-config -nodefaults -rtc
  base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet
  -no-shutdown -global ICH9-LPC.disable_s3=1 -global
  ICH9-LPC.disable_s4=1 -boot strict=on -device intel-iommu,intremap=on
  ,device-iotlb=on -device pcie-root-
  port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1
  -device pcie-root-
  port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-
  root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device
  pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3
  -device pcie-root-
  port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 -device pcie-
  root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 -device
  pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6
  -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device
  virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive
  file=/home/virtio-test2.qcow2,format=qcow2,if=none,id=drive-virtio-
  disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-
  virtio-disk0,id=virtio-disk0,bootindex=1 -netdev
  tap,id=hostnet0,vhost=on,vhostforce=on -device virtio-net-
  
pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:1d:f2,bus=pci.1,addr=0x0,iommu_platform=on,ats=on
  -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-
  random,id=objrng0,filename=/dev/urandom -device virtio-rng-
  pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -s -msg timestamp=on

  Full backtrace:

  #0  0x7521370f in raise () at /lib64/libc.so.6
  #1  0x751fdb25 in abort () at /lib64/libc.so.6
  #2  0x751fd9f9 in _nl_load_domain.cold.0 () at /lib64/libc.so.6
  #3  0x7520bcc6 in .annobin_assert.c_end () at /lib64/libc.so.6
  #4  0x55888171 in memory_region_notify_one (notifier=0x7ffde05dfde8, 
entry=0x7ffde5dfe200) at /home/qemu/memory.c:1918
  #5  0x55888247 in memory_region_notify_iommu 
(iommu_mr=0x56f6c0b0, iommu_idx=0, entry=...) at /home/qemu/memory.c:1941
  #6  0x55951c8d in vtd_process_device_iotlb_desc (s=0x57609000, 
inv_desc=0x7ffde5dfe2d0)
  at /home/qemu/hw/i386/intel_iommu.c:2468
  #7  0x55951e6a in vtd_process_inv_desc (s=0x57609000) at 
/home/qemu/hw/i386/intel_iommu.c:2531
  #8  0x55951fa5 in vtd_fetch_inv_desc (s=0x57609000) at 
/home/qemu/hw/i386/intel_iommu.c:2563
  #9  0x559520e5 in vtd_handle_iqt_write (s=0x57609000) at 
/home/qemu/hw/i386/intel_iommu.c:2590
  #10 0x55952b45 in vtd_mem_write (opaque=0x57609000, addr=136, 
val=2688, size=4) at

[Bug 1884719] Re: Function not implemented when using libaio

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1884719

Title:
  Function not implemented when using libaio

Status in QEMU:
  Incomplete

Bug description:
  Hello

  I experience "Function not implemented" errors when trying to use
  Linux libaio library in foreign architecture, e.g. aarch64.

  I've faced this problem while using 
https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. 
  I understand that I do not use plain QEMU and you may count this report as a 
"distribution of QEMU"! Just let me know what are the steps to test it with 
plain QEMU and I will test and update this ticket!

  
  Here are the steps to reproduce the issue:

  1) On x86_64 machine register QEMU:

  `docker run -it --rm --privileged multiarch/qemu-user-static
  --reset --credential yes --persistent yes`

  2) Start a Docker image with foreign CPU architecture, e.g. aarch64

  `docker run -it arm64v8/centos:8 bash`

  3) Inside the Docker container install GCC and libaio

  `yum install gcc libaio libaio-devel`

  4) Compile the following C program

  ```
  #include 
  #include 
  #include 
  #include 

  struct io_control {
  io_context_t ioContext;
  };

  int main() {
  int queueSize = 10;

  struct io_control * theControl = (struct io_control *) 
malloc(sizeof(struct io_control));
  if (theControl == NULL) {
  printf("theControl is NULL");
  return 123;
  }

  int res = io_queue_init(queueSize, >ioContext);
  io_queue_release(theControl->ioContext);
  free(theControl);
  printf("res is: %d", res);
  }
  ```

  ```
  cat > test.c
  [PASTE THE CODE ABOVE HERE]
  ^D
  ```

  `gcc test.c -o out -laio && ./out`

  
  When executed directly on aarch64 machine (i.e. without emulation) or on 
x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully 
initialized a LibAIO queue.

  But when executed on Docker image with foreign/emulated CPU
  architecture it prints `res is: -38` (ENOSYS). `man io_queue_init`
  says that error ENOSYS is returned when "Not implemented."

  Environment:

  QEMU version: 5.0.0.2  
(https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28)
  Container application: Docker
  Output of `docker --version`:

  ```
  Client:
   Version:   19.03.8
   API version:   1.40
   Go version:go1.13.8
   Git commit:afacb8b7f0
   Built: Wed Mar 11 23:42:35 2020
   OS/Arch:   linux/amd64
   Experimental:  false

  Server:
   Engine:
Version:  19.03.8
API version:  1.40 (minimum version 1.12)
Go version:   go1.13.8
Git commit:   afacb8b7f0
Built:Wed Mar 11 22:48:33 2020
OS/Arch:  linux/amd64
Experimental: false
   containerd:
Version:  1.3.3-0ubuntu2
GitCommit:
   runc:
Version:  spec: 1.0.1-dev
GitCommit:
   docker-init:
Version:  0.18.0
GitCommit:
  ```

  Same happens with Ubuntu (arm64v8/ubuntu:focal).

  I've tried to `strace` it but :

  ```
  /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented
  /usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented
  /usr/bin/strace: detach: waitpid(112): No child processes
  /usr/bin/strace: Process 112 detached
  ```

  Here are the steps to reproduce the problem with strace:

   ```
   docker run --rm -it --security-opt seccomp:unconfined --security-opt 
apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash

[Bug 1884831] Re: qemu-nbd fails to discard bigger chunks

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1884831

Title:
  qemu-nbd fails to discard bigger chunks

Status in QEMU:
  Incomplete

Bug description:
  This report is moved from systemd to here:
  https://github.com/systemd/systemd/issues/16242

  A qemu-nbd device reports that it can discard a lot of bytes:

  cat /sys/block/nbd0/queue/discard_max_bytes
  2199023255040

  And indeed, discard works with small images:

  $ qemu-img create -f qcow2 /tmp/image.img 2M
  $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img
  $ sudo blkdiscard /dev/nbd0

  but not for bigger ones (still smaller than discard_max_bytes):

  $ qemu-img create -f qcow2 /tmp/image.img 5G
  $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img
  $ sudo blkdiscard /dev/nbd0

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

Re: [RESEND PATCH v5 2/4] target/ppc: move SPR R/W callbacks to translate.c

On Thu, May 06, 2021 at 04:08:37PM -0300, Bruno Larsen (billionai) wrote:
> Moved all read and write callbacks for SPRs away from
> translate_init.c.inc and into translate.c; these functions are
> TCG only, so this motion is required to enable building with
> the flag disable-tcg
> 
> Signed-off-by: Bruno Larsen (billionai) 
> Reviewed-by: Richard Henderson 

Applied to ppc-for-6.1, thanks.

> ---
>  target/ppc/translate.c  | 1037 ++-
>  target/ppc/translate_init.c.inc | 1011 --
>  2 files changed, 1028 insertions(+), 1020 deletions(-)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index a5e144d944..3d7454a125 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -369,6 +369,1034 @@ static inline void gen_sync_exception(DisasContext 
> *ctx)
>  }
>  #endif
>  
> +/*/
> +/* SPR READ/WRITE CALLBACKS */
> +
> +static void spr_noaccess(DisasContext *ctx, int gprn, int sprn)
> +{
> +#if 0
> +sprn = ((sprn >> 5) & 0x1F) | ((sprn & 0x1F) << 5);
> +printf("ERROR: try to access SPR %d !\n", sprn);
> +#endif
> +}
> +#define SPR_NOACCESS (_noaccess)
> +
> +/* #define PPC_DUMP_SPR_ACCESSES */
> +
> +/*
> + * Generic callbacks:
> + * do nothing but store/retrieve spr value
> + */
> +static void spr_load_dump_spr(int sprn)
> +{
> +#ifdef PPC_DUMP_SPR_ACCESSES
> +TCGv_i32 t0 = tcg_const_i32(sprn);
> +gen_helper_load_dump_spr(cpu_env, t0);
> +tcg_temp_free_i32(t0);
> +#endif
> +}
> +
> +static void spr_read_generic(DisasContext *ctx, int gprn, int sprn)
> +{
> +gen_load_spr(cpu_gpr[gprn], sprn);
> +spr_load_dump_spr(sprn);
> +}
> +
> +static void spr_store_dump_spr(int sprn)
> +{
> +#ifdef PPC_DUMP_SPR_ACCESSES
> +TCGv_i32 t0 = tcg_const_i32(sprn);
> +gen_helper_store_dump_spr(cpu_env, t0);
> +tcg_temp_free_i32(t0);
> +#endif
> +}
> +
> +static void spr_write_generic(DisasContext *ctx, int sprn, int gprn)
> +{
> +gen_store_spr(sprn, cpu_gpr[gprn]);
> +spr_store_dump_spr(sprn);
> +}
> +
> +#if !defined(CONFIG_USER_ONLY)
> +static void spr_write_generic32(DisasContext *ctx, int sprn, int gprn)
> +{
> +#ifdef TARGET_PPC64
> +TCGv t0 = tcg_temp_new();
> +tcg_gen_ext32u_tl(t0, cpu_gpr[gprn]);
> +gen_store_spr(sprn, t0);
> +tcg_temp_free(t0);
> +spr_store_dump_spr(sprn);
> +#else
> +spr_write_generic(ctx, sprn, gprn);
> +#endif
> +}
> +
> +static void spr_write_clear(DisasContext *ctx, int sprn, int gprn)
> +{
> +TCGv t0 = tcg_temp_new();
> +TCGv t1 = tcg_temp_new();
> +gen_load_spr(t0, sprn);
> +tcg_gen_neg_tl(t1, cpu_gpr[gprn]);
> +tcg_gen_and_tl(t0, t0, t1);
> +gen_store_spr(sprn, t0);
> +tcg_temp_free(t0);
> +tcg_temp_free(t1);
> +}
> +
> +static void spr_access_nop(DisasContext *ctx, int sprn, int gprn)
> +{
> +}
> +
> +#endif
> +
> +/* SPR common to all PowerPC */
> +/* XER */
> +static void spr_read_xer(DisasContext *ctx, int gprn, int sprn)
> +{
> +TCGv dst = cpu_gpr[gprn];
> +TCGv t0 = tcg_temp_new();
> +TCGv t1 = tcg_temp_new();
> +TCGv t2 = tcg_temp_new();
> +tcg_gen_mov_tl(dst, cpu_xer);
> +tcg_gen_shli_tl(t0, cpu_so, XER_SO);
> +tcg_gen_shli_tl(t1, cpu_ov, XER_OV);
> +tcg_gen_shli_tl(t2, cpu_ca, XER_CA);
> +tcg_gen_or_tl(t0, t0, t1);
> +tcg_gen_or_tl(dst, dst, t2);
> +tcg_gen_or_tl(dst, dst, t0);
> +if (is_isa300(ctx)) {
> +tcg_gen_shli_tl(t0, cpu_ov32, XER_OV32);
> +tcg_gen_or_tl(dst, dst, t0);
> +tcg_gen_shli_tl(t0, cpu_ca32, XER_CA32);
> +tcg_gen_or_tl(dst, dst, t0);
> +}
> +tcg_temp_free(t0);
> +tcg_temp_free(t1);
> +tcg_temp_free(t2);
> +}
> +
> +static void spr_write_xer(DisasContext *ctx, int sprn, int gprn)
> +{
> +TCGv src = cpu_gpr[gprn];
> +/* Write all flags, while reading back check for isa300 */
> +tcg_gen_andi_tl(cpu_xer, src,
> +~((1u << XER_SO) |
> +  (1u << XER_OV) | (1u << XER_OV32) |
> +  (1u << XER_CA) | (1u << XER_CA32)));
> +tcg_gen_extract_tl(cpu_ov32, src, XER_OV32, 1);
> +tcg_gen_extract_tl(cpu_ca32, src, XER_CA32, 1);
> +tcg_gen_extract_tl(cpu_so, src, XER_SO, 1);
> +tcg_gen_extract_tl(cpu_ov, src, XER_OV, 1);
> +tcg_gen_extract_tl(cpu_ca, src, XER_CA, 1);
> +}
> +
> +/* LR */
> +static void spr_read_lr(DisasContext *ctx, int gprn, int sprn)
> +{
> +tcg_gen_mov_tl(cpu_gpr[gprn], cpu_lr);
> +}
> +
> +static void spr_write_lr(DisasContext *ctx, int sprn, int gprn)
> +{
> +tcg_gen_mov_tl(cpu_lr, cpu_gpr[gprn]);
> +}
> +
> +/* CFAR */
> +#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
> +static void spr_read_cfar(DisasContext *ctx, int gprn, int sprn)
> +{
> +tcg_gen_mov_tl(cpu_gpr[gprn], cpu_cfar);
> +}
> +
> +static void spr_write_cfar(DisasContext *ctx, int sprn, int gprn)
> +{
> +

Re: [PATCH v2 9/9] target/ppc/kvm: Replace alloca() by g_malloc()

On Thu, May 06, 2021 at 03:37:58PM +0200, Philippe Mathieu-Daudé wrote:
> The ALLOCA(3) man-page mentions its "use is discouraged".
> 
> Replace it by a g_malloc() call.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/ppc/kvm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 104a308abb5..63c458e2211 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2698,11 +2698,10 @@ 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;
>  size_t chunksize = sizeof(*buf) + n_valid * HASH_PTE_SIZE_64;
> +g_autofree struct kvm_get_htab_header *buf = g_malloc(chunksize);

Um.. that doesn't look like it would compile, since you use
sizeof(*buf) before declaring buf.

>  ssize_t rc;
>  
> -buf = alloca(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 v5 4/4] target/ppc: isolated cpu init from translation logic

On Wed, May 05, 2021 at 12:53:10PM -0300, Bruno Larsen (billionai) wrote:
> finished isolation of CPU initialization logic from
> translation logic. CPU initialization now only has common code
> and may or may not call accelerator-specific code, as the
> build options require.
> 
> Signed-off-by: Bruno Larsen (billionai)
> 

Reviewed-by: David Gibson 

> ---
>  target/ppc/{translate_init.c.inc => cpu_init.c} | 6 ++
>  target/ppc/meson.build  | 1 +
>  target/ppc/spr_tcg.h| 2 ++
>  target/ppc/translate.c  | 4 ++--
>  4 files changed, 11 insertions(+), 2 deletions(-)
>  rename target/ppc/{translate_init.c.inc => cpu_init.c} (99%)
> 
> diff --git a/target/ppc/translate_init.c.inc b/target/ppc/cpu_init.c
> similarity index 99%
> rename from target/ppc/translate_init.c.inc
> rename to target/ppc/cpu_init.c
> index 2f4e463bb6..faece1dca2 100644
> --- a/target/ppc/translate_init.c.inc
> +++ b/target/ppc/cpu_init.c
> @@ -18,6 +18,7 @@
>   * License along with this library; if not, see 
> .
>   */
>  
> +#include "qemu/osdep.h"
>  #include "disas/dis-asm.h"
>  #include "exec/gdbstub.h"
>  #include "kvm_ppc.h"
> @@ -42,6 +43,11 @@
>  #include "fpu/softfloat.h"
>  #include "qapi/qapi-commands-machine-target.h"
>  
> +#include "exec/helper-proto.h"
> +#include "helper_regs.h"
> +#include "internal.h"
> +#include "spr_tcg.h"
> +
>  /* #define PPC_DEBUG_SPR */
>  /* #define USE_APPLE_GDB */
>  
> diff --git a/target/ppc/meson.build b/target/ppc/meson.build
> index 4079d01ee3..d1aa7d5d39 100644
> --- a/target/ppc/meson.build
> +++ b/target/ppc/meson.build
> @@ -2,6 +2,7 @@ ppc_ss = ss.source_set()
>  ppc_ss.add(files(
>'cpu-models.c',
>'cpu.c',
> +  'cpu_init.c',
>'dfp_helper.c',
>'excp_helper.c',
>'fpu_helper.c',
> diff --git a/target/ppc/spr_tcg.h b/target/ppc/spr_tcg.h
> index 1d2890dea0..0be5f347d5 100644
> --- a/target/ppc/spr_tcg.h
> +++ b/target/ppc/spr_tcg.h
> @@ -19,6 +19,8 @@
>  #ifndef SPR_TCG_H
>  #define SPR_TCG_H
>  
> +#define SPR_NOACCESS (_noaccess)
> +
>  /* 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);
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 8feececba0..cc209e5999 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -38,6 +38,8 @@
>  #include "qemu/atomic128.h"
>  #include "spr_tcg.h"
>  
> +#include "qemu/qemu-print.h"
> +#include "qapi/error.h"
>  
>  #define CPU_SINGLE_STEP 0x1
>  #define CPU_BRANCH_STEP 0x2
> @@ -380,7 +382,6 @@ void spr_noaccess(DisasContext *ctx, int gprn, int sprn)
>  printf("ERROR: try to access SPR %d !\n", sprn);
>  #endif
>  }
> -#define SPR_NOACCESS (_noaccess)
>  
>  /* #define PPC_DUMP_SPR_ACCESSES */
>  
> @@ -8617,7 +8618,6 @@ GEN_HANDLER2_E(trechkpt, "trechkpt", 0x1F, 0x0E, 0x1F, 
> 0x03FFF800, \
>  };
>  
>  #include "helper_regs.h"
> -#include "translate_init.c.inc"
>  
>  
> /*/
>  /* Misc PowerPC helpers */

-- 
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 v5 3/4] target/ppc: turned SPR R/W callbacks not static

On Wed, May 05, 2021 at 12:53:09PM -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)
> 

This no longer seems to apply clean after I applied your updated
version of patch 2/4.

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

[Bug 1883784] Re: [ppc64le] qemu behavior differs from ppc64le hardware

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1883784

Title:
  [ppc64le] qemu behavior differs from ppc64le hardware

Status in QEMU:
  Incomplete

Bug description:
  I have some code which passes my test suite on PPC64LE hardware when
  compiled with GCC 10, but the saem binary fails with both qemu-ppc64le
  4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing).

  I'm not getting any errors about illegal instructions or anything,
  like that; the results are just silently different on qemu.

  I've generated a reduced test case, which is attached along with the
  binaries (both are the same code, one is just statically linked).
  They should execute successufully on PPC64LE hardware, but on qemu
  they hit a __builtin_abort (because the computed value doesn't match
  the expected value).

  Without being familiar with PPC assembly I'm not sure what else I can
  do, but if there is anything please let me know.

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

[Bug 1923497] Re: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed

** Changed in: qemu
   Status: New => 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/1923497

Title:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed

Status in QEMU:
  Invalid

Bug description:
  Trying boot/start a Windows 10 VM.  Worked until recently when this
  error started showing up.

  I have the following installed on Fedora 33:
  qemu-kvm-5.1.0-9.fc33.x86_64

  This is the error:

  Error starting domain: internal error: process exited while connecting
  to monitor: qemu-system-x86_64:
  /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed.

  Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in 
cb_wrapper
  callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
  callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 
57, in newfn
  ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in 
startup
  self._backend.create()
File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create
  if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
  libvirt.libvirtError: internal error: process exited while connecting to 
monitor: qemu-system-x86_64: 
/builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: 
bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' 
failed.

  I see this were referenced in a patch from some time ago and
  supposedly fixed.  Here is the patch info I was able to find:

  http://next.patchew.org/QEMU/1515677902-23436-1-git-send-email-
  peter.mayd...@linaro.org/1515677902-23436-10-git-send-email-
  peter.mayd...@linaro.org/

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

[Bug 1870039] Re: windows qemu-img fails to convert vhdx, assertion failure

2021-05-06 Thread Rafael Rivera

Still a bug, resetting status per new bug tracker guidance.

Also, re-tested with  v6.0.0-11869-g800a25ea45-dirty. Results in error:
ERROR:../../../util/oslib-win32.c:61:qemu_try_memalign: assertion failed: 
(is_power_of_2(alignment))


** Changed in: qemu
   Status: Incomplete => 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/1870039

Title:
  windows qemu-img fails to convert vhdx, assertion failure

Status in QEMU:
  New

Bug description:
  When attempting to convert Microsoft's 10X emulator image (19563) vhdx
  [1], qemu-img terminates abruptly with an assertion failure. (Newer
  versions of the vhdx exhibit the same issue.)

  > qemu-img.exe convert flash.vhdx flash.vhd
  **
  ERROR:util/iov.c:335:qemu_iovec_concat_iov: assertion failed: (soffset == 0)
  Bail out! ERROR:util/iov.c:335:qemu_iovec_concat_iov: assertion failed: 
(soffset == 0)
  Exception code=0x8003 flags=0x0 at 0x7FFAFDC59302

  Tested with qemu-img.exe --version
  qemu-img version 4.2.50 (v4.2.0-676-g3a63b24a1b-dirty)

  Possibly related: 1719870

  Partial Powershell cmdlet output:

  PS> Get-Vhd flash.vhdx

  VhdFormat   : VHDX
  VhdType : Dynamic
  FileSize: 8365539328
  Size: 137438953472
  MinimumSize : 137438953472
  LogicalSectorSize   : 4096
  PhysicalSectorSize  : 4096
  BlockSize   : 1048576
  ParentPath  :
  DiskIdentifier  : 7BE7C459-AE5D-451A-9368-05875120F702
  FragmentationPercentage : 11
  Alignment   : 1
  Attached: False
  DiskNumber  :
  IsPMEMCompatible: False
  AddressAbstractionType  : None
  Number  :

  [1] https://1drv.ms/u/s!AnjdAnZZcu-GpNFK_-tcNAq_4Aug8w?e=5JB6s0

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

[Bug 1863200] Re: Reconnect failed with loopback virtio1.1 server mode test

2021-05-06 Thread xuan

** Changed in: qemu
   Status: Incomplete => 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/1863200

Title:
  Reconnect failed with loopback virtio1.1 server mode test

Status in QEMU:
  New

Bug description:
  Issue discription：
  Packed ring server mode is a new feature to enable the virtio-user or 
virtio-pmd(in VM) as the server, vhost as the client, then when the vhost-user 
is killed then re-launched, the vhost-user can connect back to 
virtio-user/virtio-pmd again. Test with dpdk 20.02 ,virtio-pmd loopback 
reconnect from vhost-user failed.

  Test Environment:
  DPDK version: DPDK v20.02
  Other software versions: virtio1.1
  Qemu versions:4.2.0
  OS: Linux 4.15.0-20-generic
  Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
  Hardware platform: R2208WFTZSR.

  The reproduce step is :
  Test Case: vhost-user/virtio-pmd loopback reconnect from vhost-user
  ===
  Flow: Vhost-user --> Virtio --> Vhost-user

  1. Launch vhost-user with client mode by below commands::

  ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 
'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1
  testpmd>set fwd mac

  2. Start VM with 1 virtio device, and set the qemu as server mode::

  ./qemu-system-x86_64 -name vm2 -enable-kvm -cpu host -smp 100 -m 8G \
  -object memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on 
\
  -numa node,memdev=mem -mem-prealloc -drive 
file=/home/xuan/dpdk_project/shell/u18.img  \
  -chardev socket,path=/tmp/vm2_qga0.sock,server,nowait,id=vm2_qga0 -device 
virtio-serial \
  -device virtserialport,chardev=vm2_qga0,name=org.qemu.guest_agent.2 
-daemonize \
  -monitor unix:/tmp/vm2_monitor.sock,server,nowait -net 
nic,macaddr=00:00:00:08:e8:aa,addr=1f \
  -net user,hostfwd=tcp:127.0.0.1:6002-:22 \
  -chardev socket,id=char0,path=/tmp/vhost-net,server \
  -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \
  -device 
virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,mrg_rxbuf=on,rx_queue_size=1024,tx_queue_size=1024,packed=on
 \
  -vnc :10

  3. On VM, bind virtio net to igb_uio and run testpmd::

  ./testpmd -c 0x3 -n 4 -- -i --nb-cores=1 --txd=1024 --rxd=1024
  testpmd>set fwd mac
  testpmd>start

  4. Send packets by vhost-user, check if packets can be RX/TX with
  virtio-pmd::

  testpmd>start tx_first 32
  testpmd>show port stats all

  5. On host, quit vhost-user, then re-launch the vhost-user with below
  command::

  testpmd>quit
  ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 
'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1
  testpmd>set fwd mac
  testpmd>start tx_first 32

  6. Check if the reconnection can work, still send packets by vhost-
  user, check if packets can be RX/TX with virtio-pmd::

  testpmd>show port stats all

  Expected result::

  After the vhost-user is killed then re-launched, the VM can connect
  back to vhost-user again with throughput.

  Real result::

  After the vhost-user is killed then re-launched, no throughput with
  PVP.

  Analysis::

  QEMU has its own way to handle reconnect function for virtio server
  mode. However, for packed ring, when reconnecting to virtio, vhost
  cannot get the status of descriptors via the descriptor ring. This bug
  is caused since the reconnection for packed ring need additional reset
  operation.

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

[Bug 1877015] Re: virtio only support packed ring size power of 2

2021-05-06 Thread xuan

** Changed in: qemu
   Status: Incomplete => 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/1877015

Title:
  virtio only support packed ring size power of 2

Status in QEMU:
  New

Bug description:
  Issue discription：
  When QEMU starts with "-device 
virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"

  It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
  between 256 and 1024

  Analysis:
  According to virtio1.1 spec, the packed queue size value does not have to be 
a power of 2.

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

Re: [PATCH 16/22] qapi/parser: add docstrings

2021-05-06 Thread John Snow


On 4/25/21 9:27 AM, Markus Armbruster wrote:

Another ignorant doc string markup question...  how am I supposed to see
that exprs and docs are attributes, and not global variables?



The syntax is apparently supposed to be :py:attr:`MyClass.attr`. Though, 
it doesn't seem to be working for me. I can write :py:attr:`bzbxglkdsgl` 
and the build succeeds. I gotta hunch:


Sphinx was designed to parse ReST written by hand. The " .. py:method::" 
directives are ones you'd use when using sphinx in that style. Those 
directives are what create an object in Sphinx's cross-reference system. 
Later, if you use :py:meth:`foo`, it references that specific object.


Sphinx autodoc is a system that parses your code and automatically 
generates py:method:: and py:class:: directives for you, allowing the 
reference syntax to work.


MY HUNCH is that for field list markup within a docstring -- things like 
:ivar: -- that there is not any corresponding object being created, 
rendering cross-references for things at that scope when using autodoc 
ineffective.


BOO, BOO, A THOUSAND TIMES BOO TO THIS.

Argh, yep.

If I use:

.. py:attribute:: exprs 




Resulting parsed expressions. 



instead of

:ivar exprs: Resulting parsed expressions

then the syntax :attr:`qapi.parser.QAPISchemaParser.exprs` does resolve 
into a clickable hyperlink on the rendered output.


    ___   ___   ___  _
| __ ) / _ \ / _ \ / _ \| |
|  _ \| | | | | | | | | | |
| |_) | |_| | |_| | |_| |_|
|/ \___/ \___/ \___/(_)


Sigh. Well, while I'm here doing the research and talking to myself, the 
syntax :attr:`exprs` also works when you have the target defined. It 
doesn't have to be as verbose. With my testing setup of using the 
default role of "any", even just `exprs` works.


I wonder if there's the possibility of having sphinx enhance :ivar: and 
:cvar: to automatically create the same kind of reference target as 
py:attribute:: does.


Problems for later.

For now ...

``.exprs`` and ``.docs``?

--js

Re: [PATCH v5 1/4] target/ppc: renamed SPR registration functions

On Wed, May 05, 2021 at 12:53:07PM -0300, Bruno Larsen (billionai) wrote:
> Renamed all gen_spr_* and gen_* functions specifically related to
> registering SPRs to register_*_sprs and register_*, to avoid future
> confusion with other TCG related code.
> 
> Signed-off-by: Bruno Larsen (billionai) 
> Reviewed-by: Richard Henderson 

Applied to ppc-for-6.1, thanks.

> ---
>  target/ppc/translate_init.c.inc | 860 
>  1 file changed, 430 insertions(+), 430 deletions(-)
> 
> diff --git a/target/ppc/translate_init.c.inc b/target/ppc/translate_init.c.inc
> index 5fed4e2bc5..261d168009 100644
> --- a/target/ppc/translate_init.c.inc
> +++ b/target/ppc/translate_init.c.inc
> @@ -842,7 +842,7 @@ static void _spr_register(CPUPPCState *env, int num, 
> const char *name,
>   oea_read, oea_write, 0, ival)
>  
>  /* Generic PowerPC SPRs */
> -static void gen_spr_generic(CPUPPCState *env)
> +static void register_generic_sprs(CPUPPCState *env)
>  {
>  /* Integer processing */
>  spr_register(env, SPR_XER, "XER",
> @@ -887,7 +887,7 @@ static void gen_spr_generic(CPUPPCState *env)
>  }
>  
>  /* SPR common to all non-embedded PowerPC, including 601 */
> -static void gen_spr_ne_601(CPUPPCState *env)
> +static void register_ne_601_sprs(CPUPPCState *env)
>  {
>  /* Exception processing */
>  spr_register_kvm(env, SPR_DSISR, "DSISR",
> @@ -906,7 +906,7 @@ static void gen_spr_ne_601(CPUPPCState *env)
>  }
>  
>  /* Storage Description Register 1 */
> -static void gen_spr_sdr1(CPUPPCState *env)
> +static void register_sdr1_sprs(CPUPPCState *env)
>  {
>  #ifndef CONFIG_USER_ONLY
>  if (env->has_hv_mode) {
> @@ -929,7 +929,7 @@ static void gen_spr_sdr1(CPUPPCState *env)
>  }
>  
>  /* BATs 0-3 */
> -static void gen_low_BATs(CPUPPCState *env)
> +static void register_low_BATs(CPUPPCState *env)
>  {
>  #if !defined(CONFIG_USER_ONLY)
>  spr_register(env, SPR_IBAT0U, "IBAT0U",
> @@ -1001,7 +1001,7 @@ static void gen_low_BATs(CPUPPCState *env)
>  }
>  
>  /* BATs 4-7 */
> -static void gen_high_BATs(CPUPPCState *env)
> +static void register_high_BATs(CPUPPCState *env)
>  {
>  #if !defined(CONFIG_USER_ONLY)
>  spr_register(env, SPR_IBAT4U, "IBAT4U",
> @@ -1073,7 +1073,7 @@ static void gen_high_BATs(CPUPPCState *env)
>  }
>  
>  /* Generic PowerPC time base */
> -static void gen_tbl(CPUPPCState *env)
> +static void register_tbl(CPUPPCState *env)
>  {
>  spr_register(env, SPR_VTBL,  "TBL",
>   _read_tbl, SPR_NOACCESS,
> @@ -1094,7 +1094,7 @@ static void gen_tbl(CPUPPCState *env)
>  }
>  
>  /* Softare table search registers */
> -static void gen_6xx_7xx_soft_tlb(CPUPPCState *env, int nb_tlbs, int nb_ways)
> +static void register_6xx_7xx_soft_tlb(CPUPPCState *env, int nb_tlbs, int 
> nb_ways)
>  {
>  #if !defined(CONFIG_USER_ONLY)
>  env->nb_tlb = nb_tlbs;
> @@ -1133,7 +1133,7 @@ static void gen_6xx_7xx_soft_tlb(CPUPPCState *env, int 
> nb_tlbs, int nb_ways)
>  }
>  
>  /* SPR common to MPC755 and G2 */
> -static void gen_spr_G2_755(CPUPPCState *env)
> +static void register_G2_755_sprs(CPUPPCState *env)
>  {
>  /* SGPRs */
>  spr_register(env, SPR_SPRG4, "SPRG4",
> @@ -1155,7 +1155,7 @@ static void gen_spr_G2_755(CPUPPCState *env)
>  }
>  
>  /* SPR common to all 7xx PowerPC implementations */
> -static void gen_spr_7xx(CPUPPCState *env)
> +static void register_7xx_sprs(CPUPPCState *env)
>  {
>  /* Breakpoints */
>  /* XXX : not implemented */
> @@ -1353,7 +1353,7 @@ static void spr_write_iamr(DisasContext *ctx, int sprn, 
> int gprn)
>  }
>  #endif /* CONFIG_USER_ONLY */
>  
> -static void gen_spr_amr(CPUPPCState *env)
> +static void register_amr_sprs(CPUPPCState *env)
>  {
>  #ifndef CONFIG_USER_ONLY
>  /*
> @@ -1385,7 +1385,7 @@ static void gen_spr_amr(CPUPPCState *env)
>  #endif /* !CONFIG_USER_ONLY */
>  }
>  
> -static void gen_spr_iamr(CPUPPCState *env)
> +static void register_iamr_sprs(CPUPPCState *env)
>  {
>  #ifndef CONFIG_USER_ONLY
>  spr_register_kvm_hv(env, SPR_IAMR, "IAMR",
> @@ -1406,7 +1406,7 @@ static void spr_read_thrm(DisasContext *ctx, int gprn, 
> int sprn)
>  }
>  #endif /* !CONFIG_USER_ONLY */
>  
> -static void gen_spr_thrm(CPUPPCState *env)
> +static void register_thrm_sprs(CPUPPCState *env)
>  {
>  /* Thermal management */
>  /* XXX : not implemented */
> @@ -1427,7 +1427,7 @@ static void gen_spr_thrm(CPUPPCState *env)
>  }
>  
>  /* SPR specific to PowerPC 604 implementation */
> -static void gen_spr_604(CPUPPCState *env)
> +static void register_604_sprs(CPUPPCState *env)
>  {
>  /* Processor identification */
>  spr_register(env, SPR_PIR, "PIR",
> @@ -1480,7 +1480,7 @@ static void gen_spr_604(CPUPPCState *env)
>  }
>  
>  /* SPR specific to PowerPC 603 implementation */
> -static void gen_spr_603(CPUPPCState *env)
> +static void register_603_sprs(CPUPPCState *env)
>  {
>  /* External access control */
>  /* XXX : not implemented */
> @@ -1498,7 +1498,7 @@ static

Re: [PATCH v7 2/6] target/i386: Enable XSS feature enumeration for CPUID

2021-05-06 Thread Eduardo Habkost

On Fri, Feb 26, 2021 at 10:20:54AM +0800, Yang Weijiang wrote:
> Currently, CPUID.(EAX=0DH,ECX=01H) doesn't enumerate features in
> XSS properly, add the support here. XCR0 bits indicate user-mode XSAVE
> components, and XSS bits indicate supervisor-mode XSAVE components.
> 
> Signed-off-by: Yang Weijiang 
> ---
>  target/i386/cpu.c | 48 ++-
>  target/i386/cpu.h | 12 
>  2 files changed, 55 insertions(+), 5 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 89edab4240..f3923988ed 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1058,6 +1058,24 @@ static FeatureWordInfo 
> feature_word_info[FEATURE_WORDS] = {
>  },
>  .tcg_features = TCG_XSAVE_FEATURES,
>  },
> +[FEAT_XSAVE_XSS_LO] = {
> +.type = CPUID_FEATURE_WORD,
> +.cpuid = {
> +.eax = 0xD,
> +.needs_ecx = true,
> +.ecx = 1,
> +.reg = R_ECX,
> +},
> +},
> +[FEAT_XSAVE_XSS_HI] = {
> +.type = CPUID_FEATURE_WORD,
> +.cpuid = {
> +.eax = 0xD,
> +.needs_ecx = true,
> +.ecx = 1,
> +.reg = R_EDX
> +},
> +},
>  [FEAT_6_EAX] = {
>  .type = CPUID_FEATURE_WORD,
>  .feat_names = {
> @@ -1478,6 +1496,9 @@ static uint32_t xsave_area_size(uint64_t mask)
>  for (i = 0; i < ARRAY_SIZE(x86_ext_save_areas); i++) {
>  const ExtSaveArea *esa = _ext_save_areas[i];
>  if ((mask >> i) & 1) {
> +if (i >= 2 && !esa->offset) {

Maybe a few comments at the definition of ExtSaveArea to explain
that offset can now be zero (and what it means when it's zero)
would be helpful.  I took a while to understand why this is safe.

Would it be valid to say "ExtSaveArea.offset has a valid offset
only if the component is in CPUID_XSTATE_XCR0_MASK"?  If so,
can't this check be simply replaced with:
  if ((1 << i) & CPUID_XSTATE_XCR0_MASK)
?

Or maybe this function should just contain a:
  assert(!(mask & CPUID_XSTATE_XCR0_MASK));
at the beginning?


> +continue;
> +}
>  ret = MAX(ret, esa->offset + esa->size);
>  }
>  }
> @@ -1489,12 +1510,18 @@ static inline bool accel_uses_host_cpuid(void)
>  return kvm_enabled() || hvf_enabled();
>  }
>  
> -static inline uint64_t x86_cpu_xsave_components(X86CPU *cpu)
> +static inline uint64_t x86_cpu_xsave_xcr0_components(X86CPU *cpu)
>  {
>  return ((uint64_t)cpu->env.features[FEAT_XSAVE_XCR0_HI]) << 32 |
> cpu->env.features[FEAT_XSAVE_XCR0_LO];
>  }
>  
> +static inline uint64_t x86_cpu_xsave_xss_components(X86CPU *cpu)
> +{
> +return ((uint64_t)cpu->env.features[FEAT_XSAVE_XSS_HI]) << 32 |
> +   cpu->env.features[FEAT_XSAVE_XSS_LO];
> +}
> +
>  const char *get_register_name_32(unsigned int reg)
>  {
>  if (reg >= CPU_NB_REGS32) {
> @@ -5716,7 +5743,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  }
>  
>  if (count == 0) {
> -*ecx = xsave_area_size(x86_cpu_xsave_components(cpu));
> +*ecx = xsave_area_size(x86_cpu_xsave_xcr0_components(cpu));
>  *eax = env->features[FEAT_XSAVE_XCR0_LO];
>  *edx = env->features[FEAT_XSAVE_XCR0_HI];
>  /*
> @@ -5728,11 +5755,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  *ebx = kvm_enabled() ? *ecx : xsave_area_size(env->xcr0);
>  } else if (count == 1) {
>  *eax = env->features[FEAT_XSAVE];
> +*ecx = env->features[FEAT_XSAVE_XSS_LO];
> +*edx = env->features[FEAT_XSAVE_XSS_HI];

What about EBX?  It is documented as "The size in bytes of the
XSAVE area containing all states enabled by XCRO | IA32_XSS".

The Intel SDM is not clear, but I assume this would be
necessarily the size of the area in compacted format?


>  } else if (count < ARRAY_SIZE(x86_ext_save_areas)) {
> -if ((x86_cpu_xsave_components(cpu) >> count) & 1) {
> -const ExtSaveArea *esa = _ext_save_areas[count];
> +const ExtSaveArea *esa = _ext_save_areas[count];
> +if ((x86_cpu_xsave_xcr0_components(cpu) >> count) & 1) {
>  *eax = esa->size;
>  *ebx = esa->offset;
> +} else if ((x86_cpu_xsave_xss_components(cpu) >> count) & 1) {
> +*eax = esa->size;
> +*ebx = 0;
> +*ecx = 1;
>  }
>  }
>  break;
> @@ -6059,6 +6092,9 @@ static void x86_cpu_reset(DeviceState *dev)
>  }
>  for (i = 2; i < ARRAY_SIZE(x86_ext_save_areas); i++) {
>  const ExtSaveArea *esa = _ext_save_areas[i];
> +if (!esa->offset) {
> +continue;

Most of the comments at the xsave_area_size() hunk would apply
here.  I miss some clarity on what esa->offset==0 really means.

Would it be valid

Re: [PATCH 2/2] vhost-vdpa: doorbell mapping support

2021-05-06 Thread Si-Wei Liu





On 5/5/2021 7:17 PM, Jason Wang wrote:


在 2021/5/1 上午6:32, Si-Wei Liu 写道:



On 4/15/2021 1:04 AM, Jason Wang wrote:

This patch implements the doorbell mapping support for
vhost-vDPA. This is simply done by using mmap()/munmap() for the
vhost-vDPA fd during device start/stop. For the device without
doorbell support, we fall back to eventfd based notification
gracefully.

Signed-off-by: Jason Wang 
---
  hw/virtio/vhost-vdpa.c | 85 
++

  include/hw/virtio/vhost-vdpa.h |  7 +++
  2 files changed, 92 insertions(+)

diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
index dd4321bac2..c3a3b7566f 100644
--- a/hw/virtio/vhost-vdpa.c
+++ b/hw/virtio/vhost-vdpa.c
@@ -285,12 +285,95 @@ static int vhost_vdpa_init(struct vhost_dev 
*dev, void *opaque)

  return 0;
  }
  +static void vhost_vdpa_host_notifier_uninit(struct vhost_dev *dev,
+    int queue_index)
+{
+    size_t page_size = qemu_real_host_page_size;
+    struct vhost_vdpa *v = dev->opaque;
+    VirtIODevice *vdev = dev->vdev;
+    VhostVDPAHostNotifier *n;
+
+    n = >notifier[queue_index];
+
+    if (n->addr) {
+    virtio_queue_set_host_notifier_mr(vdev, queue_index, 
>mr, false);

+    object_unparent(OBJECT(>mr));
+    munmap(n->addr, page_size);
+    n->addr = NULL;
+    }
+}
+
+static void vhost_vdpa_host_notifiers_uninit(struct vhost_dev *dev, 
int n)

+{
+    int i;
+
+    for (i = 0; i < n; i++) {
+    vhost_vdpa_host_notifier_uninit(dev, i);
+    }
+}
+
+static int vhost_vdpa_host_notifier_init(struct vhost_dev *dev, int 
queue_index)

+{
+    size_t page_size = qemu_real_host_page_size;
+    struct vhost_vdpa *v = dev->opaque;
+    VirtIODevice *vdev = dev->vdev;
+    VhostVDPAHostNotifier *n;
+    int fd = v->device_fd;
+    void *addr;
+    char *name;
+
+    vhost_vdpa_host_notifier_uninit(dev, queue_index);
+
+    n = >notifier[queue_index];
+
+    addr = mmap(NULL, page_size, PROT_WRITE, MAP_SHARED, fd,
+    queue_index * page_size);
+    if (addr == MAP_FAILED) {
+    goto err;
+    }
+
+    name = g_strdup_printf("vhost-vdpa/host-notifier@%p mmaps[%d]",
+   v, queue_index);
+    memory_region_init_ram_device_ptr(>mr, OBJECT(vdev), name,
+  page_size, addr);
+    g_free(name);
+
+    if (virtio_queue_set_host_notifier_mr(vdev, queue_index, 
>mr, true)) {

+    munmap(addr, page_size);
+    goto err;
+    }
+    n->addr = addr;
+
+    return 0;
+
+err:
+    return -1;
+}
+
+static void vhost_vdpa_host_notifiers_init(struct vhost_dev *dev)
+{
+    int i;
+
+    for (i = 0; i < dev->nvqs; i++) {
+    if (vhost_vdpa_host_notifier_init(dev, i)) {
Shouldn't (hdev->vq_index + i) be used instead of i? or it's assumed 
to be single QP for vhost-vdpa for the moment?



Only single queue pair is supported, I'm working on the multiqueue 
support.


OK, I see.




If the latter, would be good to add some comment.



I agree, and I think it's better to use vq_index + i to avoid future 
changes.


That'll be fine. I think that depends on the way how mq will be modeled 
for vhost-vdpa, i.e. it doesn't need to be 1:1 between struct vhost_dev 
and a queue pair, like what vhost-kernel is modeled after for mq.






+    goto err;
+    }
+    }
+
+    return;
+
+err:
+    vhost_vdpa_host_notifiers_uninit(dev, i);
I'm not sure if it is really the intent to leave other vqs behind - I 
presume that either none of them is mapped, or all mappable should be 
mapped. Why here just uninit the first unmappable vq?



I'm not sure I get here, there's a loop in 
vhost_vdpa_host_notifiers_uninit(), so we either:


1) map all doorbells

or

2) no doorell is mapped


Oops, I missed the 's' in vhost_vdpa_host_notifiers_uninit() and thought 
it was vhost_vdpa_host_notifier_uninit(). Sorry for the false alarm. The 
error handling looks fine then.


Thanks!
-Siwei







+    return;
+}
+
  static int vhost_vdpa_cleanup(struct vhost_dev *dev)
  {
  struct vhost_vdpa *v;
  assert(dev->vhost_ops->backend_type == VHOST_BACKEND_TYPE_VDPA);
  v = dev->opaque;
  trace_vhost_vdpa_cleanup(dev, v);
+    vhost_vdpa_host_notifiers_uninit(dev, dev->nvqs);
  memory_listener_unregister(>listener);
    dev->opaque = NULL;
@@ -467,6 +550,7 @@ static int vhost_vdpa_dev_start(struct vhost_dev 
*dev, bool started)

  if (started) {
  uint8_t status = 0;
  memory_listener_register(>listener, 
_space_memory);

+    vhost_vdpa_host_notifiers_init(dev);
  vhost_vdpa_set_vring_ready(dev);
  vhost_vdpa_add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
  vhost_vdpa_call(dev, VHOST_VDPA_GET_STATUS, );
@@ -476,6 +560,7 @@ static int vhost_vdpa_dev_start(struct vhost_dev 
*dev, bool started)

  vhost_vdpa_reset_device(dev);
  vhost_vdpa_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE |

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 ***
https://bugs.launchpad.net/bugs/1921948


** Attachment added: "libgcc_s.so.1"
   
https://bugs.launchpad.net/qemu/+bug/1927530/+attachment/5495299/+files/libgcc_s.so.1

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

Title:
  qemu-aarch64 MTE fails to report tag mismatch

Status in QEMU:
  New

Bug description:
  Hi,

  While running the GCC testsuite with qemu-6.0 as simulator, I noticed
  several errors in the hwasan testsuite (output pattern tests).

  I am attaching:
  bitfield-2.exe
  ld-linux-aarch64.so.1
  libc.so.6
  libdl.so.2
  libhwasan.so.0
  libm.so.6
  libpthread.so.0
  librt.so.1

  The testcase can be executed via:
  qemu-aarch64 -L . bitfield-2.exe

  it currently generates:
  HWAddressSanitizer:DEADLYSIGNAL
  ==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x00f0 
(pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
  ==21137==The signal is caused by a UNKNOWN memory access.
  ==21137==Hint: address points to the zero page.
  #0 0x550084e318 in GetAccessInfo 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
  #1 0x550084e318 in HwasanOnSIGTRAP 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
  #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
  #3 0x5f01651fec  ()
  #4 0x550084b508 in __hwasan_load2 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
  #5 0x400768 in f 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
  #6 0x4007d0 in main 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
  #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
  #8 0x400688  
(/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)

  HWAddressSanitizer can not provide additional info.
  SUMMARY: HWAddressSanitizer: SEGV 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
 in GetAccessInfo
  ==21146==ABORTING

  while the testcase expects HWAddressSanitizer: tag-mismatch on address
  0x.

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

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 ***
https://bugs.launchpad.net/bugs/1921948

Sorry, I didn't think about rpath when I tried to execute what I had extracted.
Here are the additional libstdc++.so.6 and libgcc_s.so.1.

I am using a more recent qemu version than 6.0, almost head:
d45a5270d075ea589f0b0ddcf963a5fea1f500ac


** Attachment added: "libstdc++.so.6"
   
https://bugs.launchpad.net/qemu/+bug/1927530/+attachment/5495298/+files/libstdc++.so.6

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

Title:
  qemu-aarch64 MTE fails to report tag mismatch

Status in QEMU:
  New

Bug description:
  Hi,

  While running the GCC testsuite with qemu-6.0 as simulator, I noticed
  several errors in the hwasan testsuite (output pattern tests).

  I am attaching:
  bitfield-2.exe
  ld-linux-aarch64.so.1
  libc.so.6
  libdl.so.2
  libhwasan.so.0
  libm.so.6
  libpthread.so.0
  librt.so.1

  The testcase can be executed via:
  qemu-aarch64 -L . bitfield-2.exe

  it currently generates:
  HWAddressSanitizer:DEADLYSIGNAL
  ==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x00f0 
(pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
  ==21137==The signal is caused by a UNKNOWN memory access.
  ==21137==Hint: address points to the zero page.
  #0 0x550084e318 in GetAccessInfo 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
  #1 0x550084e318 in HwasanOnSIGTRAP 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
  #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
  #3 0x5f01651fec  ()
  #4 0x550084b508 in __hwasan_load2 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
  #5 0x400768 in f 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
  #6 0x4007d0 in main 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
  #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
  #8 0x400688  
(/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)

  HWAddressSanitizer can not provide additional info.
  SUMMARY: HWAddressSanitizer: SEGV 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
 in GetAccessInfo
  ==21146==ABORTING

  while the testcase expects HWAddressSanitizer: tag-mismatch on address
  0x.

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

Re: [Virtio-fs] [PULL 01/12] virtiofsd: Fix side-effect in assert()

2021-05-06 Thread Edward McClanahan

Very nice catch David... Countless times I've gotten bit by this one!

Get Outlook for Android


From: virtio-fs-boun...@redhat.com  on behalf of 
Dr. David Alan Gilbert (git) 
Sent: Thursday, May 6, 2021 1:56:30 PM
To: qemu-devel@nongnu.org ; gr...@kaod.org 
; jose.carlos.venegas.mu...@intel.com 
; ma.mando...@gmail.com 

Cc: virtio...@redhat.com ; vgo...@redhat.com 

Subject: [Virtio-fs] [PULL 01/12] virtiofsd: Fix side-effect in assert()

External email: Use caution opening links or attachments


From: Greg Kurz 

It is bad practice to put an expression with a side-effect in
assert() because the side-effect won't happen if the code is
compiled with -DNDEBUG.

Use an intermediate variable. Consolidate this in an macro to
have proper line numbers when the assertion is hit.

virtiofsd: ../../tools/virtiofsd/passthrough_ll.c:2797: lo_getxattr:
 Assertion `fchdir_res == 0' failed.
Aborted

  2796  /* fchdir should not fail here */
=>2797  FCHDIR_NOFAIL(lo->proc_self_fd);
  2798  ret = getxattr(procname, name, value, size);
  2799  FCHDIR_NOFAIL(lo->root.fd);

Fixes: bdfd66788349 ("virtiofsd: Fix xattr operations")
Cc: misono.tomoh...@jp.fujitsu.com
Signed-off-by: Greg Kurz 
Message-Id: <20210409100627.451573-1-gr...@kaod.org>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Philippe Mathieu-Daudé 
---
 tools/virtiofsd/passthrough_ll.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 1553d2ef45..6592f96f68 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2723,6 +2723,11 @@ static int xattr_map_server(const struct lo_data *lo, 
const char *server_name,
 return -ENODATA;
 }

+#define FCHDIR_NOFAIL(fd) do { \
+int fchdir_res = fchdir(fd);   \
+assert(fchdir_res == 0);   \
+} while (0)
+
 static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *in_name,
 size_t size)
 {
@@ -2789,9 +2794,9 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 ret = fgetxattr(fd, name, value, size);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = getxattr(procname, name, value, size);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }

 if (ret == -1) {
@@ -2864,9 +2869,9 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, 
size_t size)
 ret = flistxattr(fd, value, size);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = listxattr(procname, value, size);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }

 if (ret == -1) {
@@ -3000,9 +3005,9 @@ static void lo_setxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 ret = fsetxattr(fd, name, value, size, flags);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = setxattr(procname, name, value, size, flags);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }

 saverr = ret == -1 ? errno : 0;
@@ -3066,9 +3071,9 @@ static void lo_removexattr(fuse_req_t req, fuse_ino_t 
ino, const char *in_name)
 ret = fremovexattr(fd, name);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = removexattr(procname, name);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }

 saverr = ret == -1 ? errno : 0;
--
2.31.1

___
Virtio-fs mailing list
virtio...@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: [PATCH] tests/qtest/ahci-test.c: Calculate iso_size with 64-bit arithmetic

2021-05-06 Thread John Snow


On 5/6/21 3:43 PM, Peter Maydell wrote:

Coverity notes that when calculating the 64-bit iso_size value in
ahci_test_cdrom() we actually only do it with 32-bit arithmetic.
This doesn't matter for the current test code because nsectors is
always small; but adding the cast avoids the coverity complaints.

Fixes: Coverity CID 1432343
Signed-off-by: Peter Maydell 
---
  tests/qtest/ahci-test.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qtest/ahci-test.c b/tests/qtest/ahci-test.c
index 5e1954852e7..8073ccc2052 100644
--- a/tests/qtest/ahci-test.c
+++ b/tests/qtest/ahci-test.c
@@ -1491,14 +1491,14 @@ static void ahci_test_cdrom(int nsectors, bool dma, 
uint8_t cmd,
  char *iso;
  int fd;
  AHCIOpts opts = {
-.size = (ATAPI_SECTOR_SIZE * nsectors),
+.size = ((uint64_t)ATAPI_SECTOR_SIZE * nsectors),
  .atapi = true,
  .atapi_dma = dma,
  .post_cb = ahci_cb_cmp_buff,
  .set_bcl = override_bcl,
  .bcl = bcl,
  };
-uint64_t iso_size = ATAPI_SECTOR_SIZE * (nsectors + 1);
+uint64_t iso_size = (uint64_t)ATAPI_SECTOR_SIZE * (nsectors + 1);
  
  /* Prepare ISO and fill 'tx' buffer */

  fd = prepare_iso(iso_size, , );



Whupps, thank you, Coverity.

Reviewed-by: John Snow

Re: [PATCH] virtio-blk: Convert QEMUBH callback to "bitops.h" API

On 5/6/21 9:42 PM, Philippe Mathieu-Daudé wrote:
> On 5/6/21 8:22 PM, Richard Henderson wrote:
>> On 5/6/21 8:54 AM, Philippe Mathieu-Daudé wrote:
>>>   static void notify_guest_bh(void *opaque)
>>>   {
>>>   VirtIOBlockDataPlane *s = opaque;
>>> -    unsigned nvqs = s->conf->num_queues;
>>> -    unsigned long bitmap[BITS_TO_LONGS(nvqs)];
>>> -    unsigned j;
>>>   -    memcpy(bitmap, s->batch_notify_vqs, sizeof(bitmap));
>>> -    memset(s->batch_notify_vqs, 0, sizeof(bitmap));
>>> -
>>> -    for (j = 0; j < nvqs; j += BITS_PER_LONG) {
>>> -    unsigned long bits = bitmap[j / BITS_PER_LONG];
>>> -
>>> -    while (bits != 0) {
>>> -    unsigned i = j + ctzl(bits);
>>> +    for (unsigned i = 0; i < s->conf->num_queues; i++) {
>>
>> Is this bitmap dense enough that you want to iterate by index,

The max is 1Kb:

#define VIRTIO_QUEUE_MAX 1024

> 
> By 'iterate by index' do you mean the actual iteration with 'j'?
> 
>> or is it
>> sparse enough to iterate via find_first_bit/find_next_bit?
> 
> I looked at find_first_bit/find_next_bit() but they seemed to do
> a lot more than test_and_clear_bit(). As Stefan said this is hot
> path, I thought this would be cheaper, but haven't profiled the
> performance.
> 
>> In either case, leave the copy of  s->conf->num_queues to a local variable.
> 
> That is sensible to do :)
>

Re: [PATCH] tests/qtest/ahci-test.c: Calculate iso_size with 64-bit arithmetic

On 5/6/21 9:43 PM, Peter Maydell wrote:
> Coverity notes that when calculating the 64-bit iso_size value in
> ahci_test_cdrom() we actually only do it with 32-bit arithmetic.
> This doesn't matter for the current test code because nsectors is
> always small; but adding the cast avoids the coverity complaints.
> 
> Fixes: Coverity CID 1432343
> Signed-off-by: Peter Maydell 
> ---
>  tests/qtest/ahci-test.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH] scripts: add a script to list virtio devices in a system

On 5/6/21 9:33 PM, Laurent Vivier wrote:
> Add "lsvirtio" that lists all virtio devices in a system
> the same way lspci does for the PCI cards.
> 
> For instance:
> 
>  $ ./lsvirtio
>  :01:00.0 virtio0 Red Hat, Inc. (PCI) Virtio Network Card
>Subsystem: virtio
>Modalias: virtio:d0001v1AF4

"ModAlias" maybe?

>Status: ACKNOWLEDGE DRIVER_OK DRIVER FEATURES_OK
>Feature: CSUM
>Feature: GUEST_CSUM
>Feature: CTRL_GUEST_OFFLOADS
>Feature: MAC
>Feature: GUEST_TSO4
>Feature: GUEST_TSO6
>Feature: GUEST_ECN
>Feature: GUEST_UFO
>Feature: HOST_TSO4
>Feature: HOST_TSO6
>Feature: HOST_ECN
>Feature: HOST_UFO
>Feature: MRG_RXBUF
>Feature: STATUS
>Feature: CTRL_VQ
>Feature: CTRL_RX
>Feature: CTRL_VLAN
>Feature: GUEST_ANNOUNCE
>Feature: CTRL_MAC_ADDR
>Feature: RING_INDIRECT_DESC
>Feature: RING_EVENT_IDX
>Feature: VERSION_1
>Kernel driver in use: virtio_net
>  Interfaces: enp1s0
> 
>  :03:00.0 virtio1 Red Hat, Inc. (PCI) Virtio Console
>Subsystem: virtio
>Modalias: virtio:d0003v1AF4
>Status: ACKNOWLEDGE DRIVER_OK DRIVER FEATURES_OK
>Feature: MULTIPORT
>Feature: RING_INDIRECT_DESC
>Feature: RING_EVENT_IDX
>Feature: VERSION_1
>Kernel driver in use: virtio_console
>  Interfaces: vport1p1
>  ...
> 
> This is useful to have the list of virtio devices when they are not
> mapped by a PCI card:
> 
>  $ ./lsvirtio
>  virtio-mmio.121 virtio0 Virt (MMIO) Virtio 9P transport
>Subsystem: virtio
>Modalias: virtio:d0009v554D4551
>Status: FEATURES_OK ACKNOWLEDGE DRIVER DRIVER_OK
>Feature: MOUNT_TAG
>Feature: RING_INDIRECT_DESC
>Feature: RING_EVENT_IDX
>Feature: VERSION_1
>Kernel driver in use: 9pnet_virtio
>  Interfaces: home0
> 
>  virtio-mmio.122 virtio1 Virt (MMIO) Virtio GPU Device
>Subsystem: virtio
>Modalias: virtio:d0010v554D4551
>Status: FEATURES_OK ACKNOWLEDGE DRIVER DRIVER_OK
>Feature: EDID
>Feature: RING_INDIRECT_DESC
>Feature: RING_EVENT_IDX
>Feature: VERSION_1
>Kernel driver in use: virtio_gpu
>  Interfaces: fb0
>  ...
> 
> Signed-off-by: Laurent Vivier 
> ---
>  scripts/lsvirtio | 317 +++
>  1 file changed, 317 insertions(+)
>  create mode 100755 scripts/lsvirtio

Can you add an entry for the file in MAINTAINERS?

Otherwise:
Reviewed-by: Philippe Mathieu-Daudé

[PATCH] tests/qtest/ahci-test.c: Calculate iso_size with 64-bit arithmetic

Coverity notes that when calculating the 64-bit iso_size value in
ahci_test_cdrom() we actually only do it with 32-bit arithmetic.
This doesn't matter for the current test code because nsectors is
always small; but adding the cast avoids the coverity complaints.

Fixes: Coverity CID 1432343
Signed-off-by: Peter Maydell 
---
 tests/qtest/ahci-test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qtest/ahci-test.c b/tests/qtest/ahci-test.c
index 5e1954852e7..8073ccc2052 100644
--- a/tests/qtest/ahci-test.c
+++ b/tests/qtest/ahci-test.c
@@ -1491,14 +1491,14 @@ static void ahci_test_cdrom(int nsectors, bool dma, 
uint8_t cmd,
 char *iso;
 int fd;
 AHCIOpts opts = {
-.size = (ATAPI_SECTOR_SIZE * nsectors),
+.size = ((uint64_t)ATAPI_SECTOR_SIZE * nsectors),
 .atapi = true,
 .atapi_dma = dma,
 .post_cb = ahci_cb_cmp_buff,
 .set_bcl = override_bcl,
 .bcl = bcl,
 };
-uint64_t iso_size = ATAPI_SECTOR_SIZE * (nsectors + 1);
+uint64_t iso_size = (uint64_t)ATAPI_SECTOR_SIZE * (nsectors + 1);
 
 /* Prepare ISO and fill 'tx' buffer */
 fd = prepare_iso(iso_size, , );
-- 
2.20.1

[PATCH] block/copy-on-read: use bdrv_drop_filter() and drop s->active

2021-05-06 Thread Vladimir Sementsov-Ogievskiy

Now, after huge update of block graph permission update algorithm, we
don't need this workaround with active state of the filter. Drop it and
use new smart bdrv_drop_filter() function.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/copy-on-read.c | 33 +
 1 file changed, 1 insertion(+), 32 deletions(-)

diff --git a/block/copy-on-read.c b/block/copy-on-read.c
index 9cad9e1b8c..c428682272 100644
--- a/block/copy-on-read.c
+++ b/block/copy-on-read.c
@@ -29,7 +29,6 @@
 
 
 typedef struct BDRVStateCOR {
-bool active;
 BlockDriverState *bottom_bs;
 bool chain_frozen;
 } BDRVStateCOR;
@@ -89,7 +88,6 @@ static int cor_open(BlockDriverState *bs, QDict *options, int 
flags,
  */
 bdrv_ref(bottom_bs);
 }
-state->active = true;
 state->bottom_bs = bottom_bs;
 
 /*
@@ -112,17 +110,6 @@ static void cor_child_perm(BlockDriverState *bs, BdrvChild 
*c,
uint64_t perm, uint64_t shared,
uint64_t *nperm, uint64_t *nshared)
 {
-BDRVStateCOR *s = bs->opaque;
-
-if (!s->active) {
-/*
- * While the filter is being removed
- */
-*nperm = 0;
-*nshared = BLK_PERM_ALL;
-return;
-}
-
 *nperm = perm & PERM_PASSTHROUGH;
 *nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
 
@@ -280,32 +267,14 @@ static BlockDriver bdrv_copy_on_read = {
 
 void bdrv_cor_filter_drop(BlockDriverState *cor_filter_bs)
 {
-BdrvChild *child;
-BlockDriverState *bs;
 BDRVStateCOR *s = cor_filter_bs->opaque;
 
-child = bdrv_filter_child(cor_filter_bs);
-if (!child) {
-return;
-}
-bs = child->bs;
-
-/* Retain the BDS until we complete the graph change. */
-bdrv_ref(bs);
-/* Hold a guest back from writing while permissions are being reset. */
-bdrv_drained_begin(bs);
-/* Drop permissions before the graph change. */
-s->active = false;
 /* unfreeze, as otherwise bdrv_replace_node() will fail */
 if (s->chain_frozen) {
 s->chain_frozen = false;
 bdrv_unfreeze_backing_chain(cor_filter_bs, s->bottom_bs);
 }
-bdrv_child_refresh_perms(cor_filter_bs, child, _abort);
-bdrv_replace_node(cor_filter_bs, bs, _abort);
-
-bdrv_drained_end(bs);
-bdrv_unref(bs);
+bdrv_drop_filter(cor_filter_bs, _abort);
 bdrv_unref(cor_filter_bs);
 }
 
-- 
2.29.2

Re: [PATCH] virtio-blk: Convert QEMUBH callback to "bitops.h" API

On 5/6/21 8:22 PM, Richard Henderson wrote:
> On 5/6/21 8:54 AM, Philippe Mathieu-Daudé wrote:
>>   static void notify_guest_bh(void *opaque)
>>   {
>>   VirtIOBlockDataPlane *s = opaque;
>> -    unsigned nvqs = s->conf->num_queues;
>> -    unsigned long bitmap[BITS_TO_LONGS(nvqs)];
>> -    unsigned j;
>>   -    memcpy(bitmap, s->batch_notify_vqs, sizeof(bitmap));
>> -    memset(s->batch_notify_vqs, 0, sizeof(bitmap));
>> -
>> -    for (j = 0; j < nvqs; j += BITS_PER_LONG) {
>> -    unsigned long bits = bitmap[j / BITS_PER_LONG];
>> -
>> -    while (bits != 0) {
>> -    unsigned i = j + ctzl(bits);
>> +    for (unsigned i = 0; i < s->conf->num_queues; i++) {
> 
> Is this bitmap dense enough that you want to iterate by index,

By 'iterate by index' do you mean the actual iteration with 'j'?

> or is it
> sparse enough to iterate via find_first_bit/find_next_bit?

I looked at find_first_bit/find_next_bit() but they seemed to do
a lot more than test_and_clear_bit(). As Stefan said this is hot
path, I thought this would be cheaper, but haven't profiled the
performance.

> In either case, leave the copy of  s->conf->num_queues to a local variable.

That is sensible to do :)

[PATCH] scripts: add a script to list virtio devices in a system

2021-05-06 Thread Laurent Vivier

Add "lsvirtio" that lists all virtio devices in a system
the same way lspci does for the PCI cards.

For instance:

 $ ./lsvirtio
 :01:00.0 virtio0 Red Hat, Inc. (PCI) Virtio Network Card
 Subsystem: virtio
 Modalias: virtio:d0001v1AF4
 Status: ACKNOWLEDGE DRIVER_OK DRIVER FEATURES_OK
 Feature: CSUM
 Feature: GUEST_CSUM
 Feature: CTRL_GUEST_OFFLOADS
 Feature: MAC
 Feature: GUEST_TSO4
 Feature: GUEST_TSO6
 Feature: GUEST_ECN
 Feature: GUEST_UFO
 Feature: HOST_TSO4
 Feature: HOST_TSO6
 Feature: HOST_ECN
 Feature: HOST_UFO
 Feature: MRG_RXBUF
 Feature: STATUS
 Feature: CTRL_VQ
 Feature: CTRL_RX
 Feature: CTRL_VLAN
 Feature: GUEST_ANNOUNCE
 Feature: CTRL_MAC_ADDR
 Feature: RING_INDIRECT_DESC
 Feature: RING_EVENT_IDX
 Feature: VERSION_1
 Kernel driver in use: virtio_net
 Interfaces: enp1s0

 :03:00.0 virtio1 Red Hat, Inc. (PCI) Virtio Console
 Subsystem: virtio
 Modalias: virtio:d0003v1AF4
 Status: ACKNOWLEDGE DRIVER_OK DRIVER FEATURES_OK
 Feature: MULTIPORT
 Feature: RING_INDIRECT_DESC
 Feature: RING_EVENT_IDX
 Feature: VERSION_1
 Kernel driver in use: virtio_console
 Interfaces: vport1p1
 ...

This is useful to have the list of virtio devices when they are not
mapped by a PCI card:

 $ ./lsvirtio
 virtio-mmio.121 virtio0 Virt (MMIO) Virtio 9P transport
 Subsystem: virtio
 Modalias: virtio:d0009v554D4551
 Status: FEATURES_OK ACKNOWLEDGE DRIVER DRIVER_OK
 Feature: MOUNT_TAG
 Feature: RING_INDIRECT_DESC
 Feature: RING_EVENT_IDX
 Feature: VERSION_1
 Kernel driver in use: 9pnet_virtio
 Interfaces: home0

 virtio-mmio.122 virtio1 Virt (MMIO) Virtio GPU Device
 Subsystem: virtio
 Modalias: virtio:d0010v554D4551
 Status: FEATURES_OK ACKNOWLEDGE DRIVER DRIVER_OK
 Feature: EDID
 Feature: RING_INDIRECT_DESC
 Feature: RING_EVENT_IDX
 Feature: VERSION_1
 Kernel driver in use: virtio_gpu
 Interfaces: fb0
 ...

Signed-off-by: Laurent Vivier 
---
 scripts/lsvirtio | 317 +++
 1 file changed, 317 insertions(+)
 create mode 100755 scripts/lsvirtio

diff --git a/scripts/lsvirtio b/scripts/lsvirtio
new file mode 100755
index ..f457d5b7344d
--- /dev/null
+++ b/scripts/lsvirtio
@@ -0,0 +1,317 @@
+#!/usr/bin/env python3
+#
+# Copyright (C) 2021 Red Hat, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+import os
+
+# Virtual I/O Device (VIRTIO) Version 1.1
+
+# 2.1 Device Status Field
+status_name = {
+( 1, 'ACKNOWLEDGE' ),
+( 2, 'DRIVER') ,
+( 4, 'DRIVER_OK' ),
+( 8, 'FEATURES_OK' ),
+( 64, 'DEVICE_NEEDS_RESET' ),
+( 128, 'FAILED' )
+}
+
+# 5 Device Types
+device_name = {
+1:'Network Card',
+2:'Block Device',
+3:'Console',
+4:'Entropy Source',
+5:'Memory Ballooning (traditional)',
+6:'ioMemory',
+7:'rpmsg',
+8:'SCSI host',
+9:'9P transport',
+10:'MAC80211 WLAN',
+11:'rproc serial',
+12:'CAIF',
+13:'Memory Balloon',
+16:'GPU Device',
+17:'Timer/Clock Device',
+18:'Input Device',
+19:'Socket Device',
+20:'Crypto Device',
+21:'Signal Distribution Module',
+22:'pstore Device',
+23:'IOMMU Device',
+24:'Memory Device',
+# From linux headers
+26:'Filesystem',
+27:'pmem',
+29:'mac80211-hwsim',
+}
+
+# 5.1 Network Device
+# 5.1.3 Feature bits
+net_feature_name = {
+0:'CSUM',
+1:'GUEST_CSUM',
+2:'CTRL_GUEST_OFFLOADS',
+3:'MTU',
+5:'MAC',
+6:'GSO',
+7:'GUEST_TSO4',
+8:'GUEST_TSO6',
+9:'GUEST_ECN',
+10:'GUEST_UFO',
+11:'HOST_TSO4',
+12:'HOST_TSO6',
+13:'HOST_ECN',
+14:'HOST_UFO',
+15:'MRG_RXBUF',
+16:'STATUS',
+17:'CTRL_VQ',
+18:'CTRL_RX',
+19:'CTRL_VLAN',
+21:'GUEST_ANNOUNCE',
+22:'MQ',
+23:'CTRL_MAC_ADDR',
+41:'GUEST_RSC4',
+42:'GUEST_RSC6',
+61:'RSC_EXT',
+62:'STANDBY',
+}
+
+def get_feature_net(feature):
+return net_feature_name[feature]
+
+# 5.2 Block Device
+# 5.2.3 Feature bits
+block_feature_name = {
+0:'BARRIER',
+1:'SIZE_MAX',
+2:'SEG_MAX',
+4:'GEOMETRY',
+5:'RO',
+6:'BLK_SIZE',
+7:'SCSI',
+9:'FLUSH',
+10:'TOPOLOGY',
+11:'CONFIG_WCE',
+13:'DISCARD',
+14:'WRITE_ZEROES',
+}
+
+def get_feature_block(feature):
+return block_feature_name[feature]
+
+# 5.3 Console Device
+# 5.3.3 Feature bits
+console_feature_name = {
+0:'SIZE',
+1:'MULTIPORT',
+2:'EMERG_WRITE',
+}
+
+def get_feature_console(feature):
+return console_feature_name[feature]
+
+# 5.4 Entropy Device
+# 5.4.3 Feature bits
+# No feature bits
+
+# 5.5 Traditional

Re: [PATCH v2 6/9] gdbstub: Only call cmd_parse_params() with non-NULL command schema

2021-05-06 Thread Alex Bennée



Philippe Mathieu-Daudé  writes:

> Move the NULL check on command schema buffer from the callee
> cmd_parse_params() to the single caller, process_string_cmd().
>
> This simplifies the process_string_cmd() logic.
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [PATCH v2 7/9] gdbstub: Replace alloca() + memset(0) by g_new0()

2021-05-06 Thread Alex Bennée



Philippe Mathieu-Daudé  writes:

> The ALLOCA(3) man-page mentions its "use is discouraged".
>
> Replace the alloca() and memset(0) calls by g_new0().
>
> Signed-off-by: Philippe Mathieu-Daudé 

Please see:

  Subject: [ALT PATCH] gdbstub: Replace GdbCmdContext with plain g_array()
  Date: Thu,  6 May 2021 17:07:41 +0100
  Message-Id: <20210506160741.9841-1-alex.ben...@linaro.org>

which also includes elements of 6/9 which can be kept split off.

> ---
>  gdbstub.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/gdbstub.c b/gdbstub.c
> index 7cee2fb0f1f..666053bf590 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1487,14 +1487,13 @@ static int process_string_cmd(void *user_ctx, const 
> char *data,
>  if (cmd->schema) {
>  int schema_len = strlen(cmd->schema);
>  int max_num_params = schema_len / 2;
> +g_autofree GdbCmdVariant *params = NULL;
>  
>  if (schema_len % 2) {
>  return -2;
>  }
>  
> -gdb_ctx.params = (GdbCmdVariant *)alloca(sizeof(*gdb_ctx.params)
> - * max_num_params);
> -memset(gdb_ctx.params, 0, sizeof(*gdb_ctx.params) * 
> max_num_params);
> +gdb_ctx.params = params = g_new0(GdbCmdVariant, max_num_params);
>  
>  if (cmd_parse_params([strlen(cmd->cmd)], cmd->schema,
>   gdb_ctx.params, _ctx.num_params)) {


-- 
Alex Bennée

[PATCH] tests/qtest/migration-test: Use g_autofree to avoid leaks on error paths

Coverity notices that several places in the migration-test code fail
to free memory in error-exit paths.  This is pretty unimportant in
test case code, but we can avoid having to manually free the memory
entirely by using g_autofree.

The places where Coverity spotted a leak were relating to early exits
not freeing 'uri' in test_precopy_unix(), do_test_validate_uuid(),
migrate_postcopy_prepare() and test_migrate_auto_converge().  This
patch converts all the string-allocation in the test code to
g_autofree for consistency.

Fixes: Coverity CID 1432313, 1432315, 1432352, 1432364
Signed-off-by: Peter Maydell 
---
 tests/qtest/migration-test.c | 61 
 1 file changed, 20 insertions(+), 41 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 3a711bb4929..a0c9b72b951 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -110,13 +110,12 @@ static void init_bootfile(const char *bootpath, void 
*content, size_t len)
  */
 static void wait_for_serial(const char *side)
 {
-char *serialpath = g_strdup_printf("%s/%s", tmpfs, side);
+g_autofree char *serialpath = g_strdup_printf("%s/%s", tmpfs, side);
 FILE *serialfile = fopen(serialpath, "r");
 const char *arch = qtest_get_arch();
 int started = (strcmp(side, "src_serial") == 0 &&
strcmp(arch, "ppc64") == 0) ? 0 : 1;
 
-g_free(serialpath);
 do {
 int readvalue = fgetc(serialfile);
 
@@ -274,10 +273,9 @@ static void check_guests_ram(QTestState *who)
 
 static void cleanup(const char *filename)
 {
-char *path = g_strdup_printf("%s/%s", tmpfs, filename);
+g_autofree char *path = g_strdup_printf("%s/%s", tmpfs, filename);
 
 unlink(path);
-g_free(path);
 }
 
 static char *SocketAddress_to_str(SocketAddress *addr)
@@ -374,11 +372,8 @@ static char *migrate_get_parameter_str(QTestState *who,
 static void migrate_check_parameter_str(QTestState *who, const char *parameter,
 const char *value)
 {
-char *result;
-
-result = migrate_get_parameter_str(who, parameter);
+g_autofree char *result = migrate_get_parameter_str(who, parameter);
 g_assert_cmpstr(result, ==, value);
-g_free(result);
 }
 
 static void migrate_set_parameter_str(QTestState *who, const char *parameter,
@@ -495,12 +490,14 @@ static void migrate_start_destroy(MigrateStart *args)
 static int test_migrate_start(QTestState **from, QTestState **to,
   const char *uri, MigrateStart *args)
 {
-gchar *arch_source, *arch_target;
-gchar *cmd_source, *cmd_target;
+g_autofree gchar *arch_source = NULL;
+g_autofree gchar *arch_target = NULL;
+g_autofree gchar *cmd_source = NULL;
+g_autofree gchar *cmd_target = NULL;
 const gchar *ignore_stderr;
-char *bootpath = NULL;
-char *shmem_opts;
-char *shmem_path;
+g_autofree char *bootpath = NULL;
+g_autofree char *shmem_opts = NULL;
+g_autofree char *shmem_path = NULL;
 const char *arch = qtest_get_arch();
 const char *machine_opts = NULL;
 const char *memory_size;
@@ -559,8 +556,6 @@ static int test_migrate_start(QTestState **from, QTestState 
**to,
 g_assert_not_reached();
 }
 
-g_free(bootpath);
-
 if (!getenv("QTEST_LOG") && args->hide_stderr) {
 ignore_stderr = "2>/dev/null";
 } else {
@@ -588,11 +583,9 @@ static int test_migrate_start(QTestState **from, 
QTestState **to,
  memory_size, tmpfs,
  arch_source, shmem_opts, args->opts_source,
  ignore_stderr);
-g_free(arch_source);
 if (!args->only_target) {
 *from = qtest_init(cmd_source);
 }
-g_free(cmd_source);
 
 cmd_target = g_strdup_printf("-accel kvm -accel tcg%s%s "
  "-name target,debug-threads=on "
@@ -605,18 +598,14 @@ static int test_migrate_start(QTestState **from, 
QTestState **to,
  memory_size, tmpfs, uri,
  arch_target, shmem_opts,
  args->opts_target, ignore_stderr);
-g_free(arch_target);
 *to = qtest_init(cmd_target);
-g_free(cmd_target);
 
-g_free(shmem_opts);
 /*
  * Remove shmem file immediately to avoid memory leak in test failed case.
  * It's valid becase QEMU has already opened this file
  */
 if (args->use_shmem) {
 unlink(shmem_path);
-g_free(shmem_path);
 }
 
 out:
@@ -662,7 +651,7 @@ static int migrate_postcopy_prepare(QTestState **from_ptr,
 QTestState **to_ptr,
 MigrateStart *args)
 {
-char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
+g_autofree char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
 QTestState *from, *to;
 
 if (test_migrate_start(, ,

[PULL 10/12] virtiofsd: Changed allocations of fv_VuDev & its internals to GLib functions

From: Mahmoud Mandour 

Changed the allocations of fv_VuDev structs, VuDev structs, and
fv_QueueInfo strcuts from using calloc()/realloc() & free() to using
the equivalent functions from GLib.

In instances, removed the pair of allocation and assertion for
non-NULL checking with a GLib function that aborts on error.

Removed NULL-checking for fv_VuDev struct allocation and used
a GLib function that crashes on error; namely, g_new0(). This
is because allocating one struct should not be a problem on an
healthy system. Also following the pattern of aborting-on-null
behaviour that is taken with allocating VuDev structs and
fv_QueueInfo structs.

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-6-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/fuse_virtio.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index a3d37ab696..828f0fa590 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -782,7 +782,7 @@ static void fv_queue_cleanup_thread(struct fv_VuDev *vud, 
int qidx)
 pthread_mutex_destroy(>vq_lock);
 close(ourqi->kill_fd);
 ourqi->kick_fd = -1;
-free(vud->qi[qidx]);
+g_free(vud->qi[qidx]);
 vud->qi[qidx] = NULL;
 }
 
@@ -813,15 +813,13 @@ static void fv_queue_set_started(VuDev *dev, int qidx, 
bool started)
 if (started) {
 /* Fire up a thread to watch this queue */
 if (qidx >= vud->nqueues) {
-vud->qi = realloc(vud->qi, (qidx + 1) * sizeof(vud->qi[0]));
-assert(vud->qi);
+vud->qi = g_realloc_n(vud->qi, qidx + 1, sizeof(vud->qi[0]));
 memset(vud->qi + vud->nqueues, 0,
sizeof(vud->qi[0]) * (1 + (qidx - vud->nqueues)));
 vud->nqueues = qidx + 1;
 }
 if (!vud->qi[qidx]) {
-vud->qi[qidx] = calloc(sizeof(struct fv_QueueInfo), 1);
-assert(vud->qi[qidx]);
+vud->qi[qidx] = g_new0(struct fv_QueueInfo, 1);
 vud->qi[qidx]->virtio_dev = vud;
 vud->qi[qidx]->qidx = qidx;
 } else {
@@ -1087,12 +1085,7 @@ int virtio_session_mount(struct fuse_session *se)
  __func__);
 
 /* TODO: Some cleanup/deallocation! */
-se->virtio_dev = calloc(sizeof(struct fv_VuDev), 1);
-if (!se->virtio_dev) {
-fuse_log(FUSE_LOG_ERR, "%s: virtio_dev calloc failed\n", __func__);
-close(data_sock);
-return -1;
-}
+se->virtio_dev = g_new0(struct fv_VuDev, 1);
 
 se->vu_socketfd = data_sock;
 se->virtio_dev->se = se;
@@ -1114,8 +1107,8 @@ void virtio_session_close(struct fuse_session *se)
 return;
 }
 
-free(se->virtio_dev->qi);
+g_free(se->virtio_dev->qi);
 pthread_rwlock_destroy(>virtio_dev->vu_dispatch_rwlock);
-free(se->virtio_dev);
+g_free(se->virtio_dev);
 se->virtio_dev = NULL;
 }
-- 
2.31.1

Re: [PATCH] Add missing coroutine_fn function signature to functions

2021-05-06 Thread cennedee

Thank you for the feedback. Here is an updated patch.
Added more functions related to do_sgio() as suggested. Also found one related 
to prh_co_entry()

I have removed (edits on) two files as there are many more functions I found in 
those. So I think another thread might be more appropriate (where I'll send 
patches flie by file). Focusing on two files here now.

For reference the path of calls that end up on a coroutine_fn below

do_pr_in() --> do_sgio()
do_pr_out() --> do_sgio()
mpath_reconstruct_sense() --> do_sgio()
multipath_pr_out() --> mpath_reconstruct_sense() --> do_sgio()
multipath_pr_in() --> mpath_reconstruct_sense() --> do_sgio()
accept_client() --> prh_co_entry()



>From 79f787c2ef5f713546b38a76367d273ff65742d6 Mon Sep 17 00:00:00 2001
From: Cenne Dee 
Date: Fri, 30 Apr 2021 15:52:28 -0400
Subject: [PATCH] Add missing coroutine_fn function signature to some _co()
 functions

Patch adds the signature for relevant functions ending with _co
or those that use them.

Signed-off-by: Cenne Dee 
---
 scsi/qemu-pr-helper.c | 14 +++---
 tests/unit/test-thread-pool.c |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c
index 7b9389b..695539b 100644
--- a/scsi/qemu-pr-helper.c
+++ b/scsi/qemu-pr-helper.c
@@ -175,7 +175,7 @@ static int do_sgio_worker(void *opaque)
 return status;
 }

-static int do_sgio(int fd, const uint8_t *cdb, uint8_t *sense,
+static int coroutine_fn do_sgio(int fd, const uint8_t *cdb, uint8_t *sense,
 uint8_t *buf, int *sz, int dir)
 {
 ThreadPool *pool = aio_get_thread_pool(qemu_get_aio_context());
@@ -318,7 +318,7 @@ static SCSISense mpath_generic_sense(int r)
 }
 }

-static int mpath_reconstruct_sense(int fd, int r, uint8_t *sense)
+static int coroutine_fn mpath_reconstruct_sense(int fd, int r, uint8_t *sense)
 {
 switch (r) {
 case MPATH_PR_SUCCESS:
@@ -370,7 +370,7 @@ static int mpath_reconstruct_sense(int fd, int r, uint8_t 
*sense)
 }
 }

-static int multipath_pr_in(int fd, const uint8_t *cdb, uint8_t *sense,
+static int coroutine_fn multipath_pr_in(int fd, const uint8_t *cdb, uint8_t 
*sense,
uint8_t *data, int sz)
 {
 int rq_servact = cdb[1];
@@ -425,7 +425,7 @@ static int multipath_pr_in(int fd, const uint8_t *cdb, 
uint8_t *sense,
 return mpath_reconstruct_sense(fd, r, sense);
 }

-static int multipath_pr_out(int fd, const uint8_t *cdb, uint8_t *sense,
+static int coroutine_fn multipath_pr_out(int fd, const uint8_t *cdb, uint8_t 
*sense,
 const uint8_t *param, int sz)
 {
 int rq_servact = cdb[1];
@@ -543,7 +543,7 @@ static int multipath_pr_out(int fd, const uint8_t *cdb, 
uint8_t *sense,
 }
 #endif

-static int do_pr_in(int fd, const uint8_t *cdb, uint8_t *sense,
+static int coroutine_fn do_pr_in(int fd, const uint8_t *cdb, uint8_t *sense,
 uint8_t *data, int *resp_sz)
 {
 #ifdef CONFIG_MPATH
@@ -561,7 +561,7 @@ static int do_pr_in(int fd, const uint8_t *cdb, uint8_t 
*sense,
SG_DXFER_FROM_DEV);
 }

-static int do_pr_out(int fd, const uint8_t *cdb, uint8_t *sense,
+static int coroutine_fn do_pr_out(int fd, const uint8_t *cdb, uint8_t *sense,
  const uint8_t *param, int sz)
 {
 int resp_sz;
@@ -804,7 +804,7 @@ out:
 g_free(client);
 }

-static gboolean accept_client(QIOChannel *ioc, GIOCondition cond, gpointer 
opaque)
+static gboolean coroutine_fn accept_client(QIOChannel *ioc, GIOCondition cond, 
gpointer opaque)
 {
 QIOChannelSocket *cioc;
 PRHelperClient *prh;
diff --git a/tests/unit/test-thread-pool.c b/tests/unit/test-thread-pool.c
index 70dc631..dbaf72c 100644
--- a/tests/unit/test-thread-pool.c
+++ b/tests/unit/test-thread-pool.c
@@ -72,7 +72,7 @@ static void test_submit_aio(void)
 g_assert_cmpint(data.ret, ==, 0);
 }

-static void co_test_cb(void *opaque)
+static void coroutine_fn co_test_cb(void *opaque)
 {
 WorkerTestData *data = opaque;

--
2.31.1

[PULL 12/12] virtiofsd/fuse_virtio.c: Changed allocations of locals to GLib

From: Mahmoud Mandour 

Replaced the allocation of local variables from malloc() to
GLib allocation functions.

In one instance, dropped the usage to an assert after a malloc()
call and used g_malloc() instead.

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-8-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/fuse_virtio.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 828f0fa590..1170f375a5 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -511,8 +511,7 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
  * They're spread over multiple descriptors in a scatter/gather set
  * and we can't trust the guest to keep them still; so copy in/out.
  */
-fbuf.mem = malloc(se->bufsize);
-assert(fbuf.mem);
+fbuf.mem = g_malloc(se->bufsize);
 
 fuse_mutex_init(>ch.lock);
 req->ch.fd = -1;
@@ -564,8 +563,8 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
 memcpy(fbuf.mem, , sizeof(struct fuse_in_header));
 
 /* Allocate the bufv, with space for the rest of the iov */
-pbufv = malloc(sizeof(struct fuse_bufvec) +
-   sizeof(struct fuse_buf) * out_num);
+pbufv = g_try_malloc(sizeof(struct fuse_bufvec) +
+ sizeof(struct fuse_buf) * out_num);
 if (!pbufv) {
 fuse_log(FUSE_LOG_ERR, "%s: pbufv malloc failed\n",
 __func__);
@@ -622,7 +621,7 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
 
 out:
 if (allocated_bufv) {
-free(pbufv);
+g_free(pbufv);
 }
 
 /* If the request has no reply, still recycle the virtqueue element */
@@ -641,7 +640,7 @@ out:
 }
 
 pthread_mutex_destroy(>ch.lock);
-free(fbuf.mem);
+g_free(fbuf.mem);
 free(req);
 }
 
-- 
2.31.1

Re: [PATCH v5 2/4] target/ppc: move SPR R/W callbacks to translate.c

2021-05-06 Thread Bruno Piazera Larsen



On 06/05/2021 15:57, Richard Henderson wrote:

On 5/5/21 8:53 AM, Bruno Larsen (billionai) wrote:

+/* SPR READ/RITE CALLBACKS */


Missed the spelling fix reported against v4.
And my r-b tags.


r~


:facepalm:

sorry, resending it now

--
Bruno Piazera Larsen
Instituto de Pesquisas ELDORADO 


Departamento Computação Embarcada
Analista de Software Trainee
Aviso Legal - Disclaimer

[RESEND PATCH v5 2/4] target/ppc: move SPR R/W callbacks to translate.c

2021-05-06 Thread Bruno Larsen (billionai)

Moved all read and write callbacks for SPRs away from
translate_init.c.inc and into translate.c; these functions are
TCG only, so this motion is required to enable building with
the flag disable-tcg

Signed-off-by: Bruno Larsen (billionai) 
Reviewed-by: Richard Henderson  
---
 target/ppc/translate.c  | 1037 ++-
 target/ppc/translate_init.c.inc | 1011 --
 2 files changed, 1028 insertions(+), 1020 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index a5e144d944..3d7454a125 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -369,6 +369,1034 @@ static inline void gen_sync_exception(DisasContext *ctx)
 }
 #endif
 
+/*/
+/* SPR READ/WRITE CALLBACKS */
+
+static void spr_noaccess(DisasContext *ctx, int gprn, int sprn)
+{
+#if 0
+sprn = ((sprn >> 5) & 0x1F) | ((sprn & 0x1F) << 5);
+printf("ERROR: try to access SPR %d !\n", sprn);
+#endif
+}
+#define SPR_NOACCESS (_noaccess)
+
+/* #define PPC_DUMP_SPR_ACCESSES */
+
+/*
+ * Generic callbacks:
+ * do nothing but store/retrieve spr value
+ */
+static void spr_load_dump_spr(int sprn)
+{
+#ifdef PPC_DUMP_SPR_ACCESSES
+TCGv_i32 t0 = tcg_const_i32(sprn);
+gen_helper_load_dump_spr(cpu_env, t0);
+tcg_temp_free_i32(t0);
+#endif
+}
+
+static void spr_read_generic(DisasContext *ctx, int gprn, int sprn)
+{
+gen_load_spr(cpu_gpr[gprn], sprn);
+spr_load_dump_spr(sprn);
+}
+
+static void spr_store_dump_spr(int sprn)
+{
+#ifdef PPC_DUMP_SPR_ACCESSES
+TCGv_i32 t0 = tcg_const_i32(sprn);
+gen_helper_store_dump_spr(cpu_env, t0);
+tcg_temp_free_i32(t0);
+#endif
+}
+
+static void spr_write_generic(DisasContext *ctx, int sprn, int gprn)
+{
+gen_store_spr(sprn, cpu_gpr[gprn]);
+spr_store_dump_spr(sprn);
+}
+
+#if !defined(CONFIG_USER_ONLY)
+static void spr_write_generic32(DisasContext *ctx, int sprn, int gprn)
+{
+#ifdef TARGET_PPC64
+TCGv t0 = tcg_temp_new();
+tcg_gen_ext32u_tl(t0, cpu_gpr[gprn]);
+gen_store_spr(sprn, t0);
+tcg_temp_free(t0);
+spr_store_dump_spr(sprn);
+#else
+spr_write_generic(ctx, sprn, gprn);
+#endif
+}
+
+static void spr_write_clear(DisasContext *ctx, int sprn, int gprn)
+{
+TCGv t0 = tcg_temp_new();
+TCGv t1 = tcg_temp_new();
+gen_load_spr(t0, sprn);
+tcg_gen_neg_tl(t1, cpu_gpr[gprn]);
+tcg_gen_and_tl(t0, t0, t1);
+gen_store_spr(sprn, t0);
+tcg_temp_free(t0);
+tcg_temp_free(t1);
+}
+
+static void spr_access_nop(DisasContext *ctx, int sprn, int gprn)
+{
+}
+
+#endif
+
+/* SPR common to all PowerPC */
+/* XER */
+static void spr_read_xer(DisasContext *ctx, int gprn, int sprn)
+{
+TCGv dst = cpu_gpr[gprn];
+TCGv t0 = tcg_temp_new();
+TCGv t1 = tcg_temp_new();
+TCGv t2 = tcg_temp_new();
+tcg_gen_mov_tl(dst, cpu_xer);
+tcg_gen_shli_tl(t0, cpu_so, XER_SO);
+tcg_gen_shli_tl(t1, cpu_ov, XER_OV);
+tcg_gen_shli_tl(t2, cpu_ca, XER_CA);
+tcg_gen_or_tl(t0, t0, t1);
+tcg_gen_or_tl(dst, dst, t2);
+tcg_gen_or_tl(dst, dst, t0);
+if (is_isa300(ctx)) {
+tcg_gen_shli_tl(t0, cpu_ov32, XER_OV32);
+tcg_gen_or_tl(dst, dst, t0);
+tcg_gen_shli_tl(t0, cpu_ca32, XER_CA32);
+tcg_gen_or_tl(dst, dst, t0);
+}
+tcg_temp_free(t0);
+tcg_temp_free(t1);
+tcg_temp_free(t2);
+}
+
+static void spr_write_xer(DisasContext *ctx, int sprn, int gprn)
+{
+TCGv src = cpu_gpr[gprn];
+/* Write all flags, while reading back check for isa300 */
+tcg_gen_andi_tl(cpu_xer, src,
+~((1u << XER_SO) |
+  (1u << XER_OV) | (1u << XER_OV32) |
+  (1u << XER_CA) | (1u << XER_CA32)));
+tcg_gen_extract_tl(cpu_ov32, src, XER_OV32, 1);
+tcg_gen_extract_tl(cpu_ca32, src, XER_CA32, 1);
+tcg_gen_extract_tl(cpu_so, src, XER_SO, 1);
+tcg_gen_extract_tl(cpu_ov, src, XER_OV, 1);
+tcg_gen_extract_tl(cpu_ca, src, XER_CA, 1);
+}
+
+/* LR */
+static void spr_read_lr(DisasContext *ctx, int gprn, int sprn)
+{
+tcg_gen_mov_tl(cpu_gpr[gprn], cpu_lr);
+}
+
+static void spr_write_lr(DisasContext *ctx, int sprn, int gprn)
+{
+tcg_gen_mov_tl(cpu_lr, cpu_gpr[gprn]);
+}
+
+/* CFAR */
+#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
+static void spr_read_cfar(DisasContext *ctx, int gprn, int sprn)
+{
+tcg_gen_mov_tl(cpu_gpr[gprn], cpu_cfar);
+}
+
+static void spr_write_cfar(DisasContext *ctx, int sprn, int gprn)
+{
+tcg_gen_mov_tl(cpu_cfar, cpu_gpr[gprn]);
+}
+#endif /* defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY) */
+
+/* CTR */
+static void spr_read_ctr(DisasContext *ctx, int gprn, int sprn)
+{
+tcg_gen_mov_tl(cpu_gpr[gprn], cpu_ctr);
+}
+
+static void spr_write_ctr(DisasContext *ctx, int sprn, int gprn)
+{
+tcg_gen_mov_tl(cpu_ctr, cpu_gpr[gprn]);
+}
+
+/* User read access to SPR */
+/* USPRx */
+/* UMMCRx */
+/* UPMCx */
+/* USIA */
+/* UDECR

Re: [PATCH v5 2/4] target/ppc: move SPR R/W callbacks to translate.c


On 5/5/21 8:53 AM, Bruno Larsen (billionai) wrote:

+/* SPR READ/RITE CALLBACKS */


Missed the spelling fix reported against v4.
And my r-b tags.


r~

[PULL 07/12] virtiofsd: Changed allocations of iovec to GLib's functions

From: Mahmoud Mandour 

Replaced the calls to malloc()/calloc() and their respective
calls to free() of iovec structs with GLib's allocation and
deallocation functions and used g_autofree when appropriate.

Replaced the allocation of in_sg_cpy to g_new() instead of a call
to calloc() and a null-checking assertion. Not g_new0()
because the buffer is immediately overwritten using memcpy.

Signed-off-by: Mahmoud Mandour 
Message-Id: <20210427181333.148176-1-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/fuse_lowlevel.c | 31 ---
 tools/virtiofsd/fuse_virtio.c   |  7 ++-
 2 files changed, 14 insertions(+), 24 deletions(-)

diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
index 812cef6ef6..88496f9560 100644
--- a/tools/virtiofsd/fuse_lowlevel.c
+++ b/tools/virtiofsd/fuse_lowlevel.c
@@ -217,9 +217,9 @@ static int send_reply(fuse_req_t req, int error, const void 
*arg,
 int fuse_reply_iov(fuse_req_t req, const struct iovec *iov, int count)
 {
 int res;
-struct iovec *padded_iov;
+g_autofree struct iovec *padded_iov = NULL;
 
-padded_iov = malloc((count + 1) * sizeof(struct iovec));
+padded_iov = g_try_new(struct iovec, count + 1);
 if (padded_iov == NULL) {
 return fuse_reply_err(req, ENOMEM);
 }
@@ -228,7 +228,6 @@ int fuse_reply_iov(fuse_req_t req, const struct iovec *iov, 
int count)
 count++;
 
 res = send_reply_iov(req, 0, padded_iov, count);
-free(padded_iov);
 
 return res;
 }
@@ -568,7 +567,7 @@ static struct fuse_ioctl_iovec *fuse_ioctl_iovec_copy(const 
struct iovec *iov,
 struct fuse_ioctl_iovec *fiov;
 size_t i;
 
-fiov = malloc(sizeof(fiov[0]) * count);
+fiov = g_try_new(struct fuse_ioctl_iovec, count);
 if (!fiov) {
 return NULL;
 }
@@ -586,8 +585,8 @@ int fuse_reply_ioctl_retry(fuse_req_t req, const struct 
iovec *in_iov,
size_t out_count)
 {
 struct fuse_ioctl_out arg;
-struct fuse_ioctl_iovec *in_fiov = NULL;
-struct fuse_ioctl_iovec *out_fiov = NULL;
+g_autofree struct fuse_ioctl_iovec *in_fiov = NULL;
+g_autofree struct fuse_ioctl_iovec *out_fiov = NULL;
 struct iovec iov[4];
 size_t count = 1;
 int res;
@@ -603,13 +602,14 @@ int fuse_reply_ioctl_retry(fuse_req_t req, const struct 
iovec *in_iov,
 /* Can't handle non-compat 64bit ioctls on 32bit */
 if (sizeof(void *) == 4 && req->ioctl_64bit) {
 res = fuse_reply_err(req, EINVAL);
-goto out;
+return res;
 }
 
 if (in_count) {
 in_fiov = fuse_ioctl_iovec_copy(in_iov, in_count);
 if (!in_fiov) {
-goto enomem;
+res = fuse_reply_err(req, ENOMEM);
+return res;
 }
 
 iov[count].iov_base = (void *)in_fiov;
@@ -619,7 +619,8 @@ int fuse_reply_ioctl_retry(fuse_req_t req, const struct 
iovec *in_iov,
 if (out_count) {
 out_fiov = fuse_ioctl_iovec_copy(out_iov, out_count);
 if (!out_fiov) {
-goto enomem;
+res = fuse_reply_err(req, ENOMEM);
+return res;
 }
 
 iov[count].iov_base = (void *)out_fiov;
@@ -628,15 +629,8 @@ int fuse_reply_ioctl_retry(fuse_req_t req, const struct 
iovec *in_iov,
 }
 
 res = send_reply_iov(req, 0, iov, count);
-out:
-free(in_fiov);
-free(out_fiov);
 
 return res;
-
-enomem:
-res = fuse_reply_err(req, ENOMEM);
-goto out;
 }
 
 int fuse_reply_ioctl(fuse_req_t req, int result, const void *buf, size_t size)
@@ -663,11 +657,11 @@ int fuse_reply_ioctl(fuse_req_t req, int result, const 
void *buf, size_t size)
 int fuse_reply_ioctl_iov(fuse_req_t req, int result, const struct iovec *iov,
  int count)
 {
-struct iovec *padded_iov;
+g_autofree struct iovec *padded_iov = NULL;
 struct fuse_ioctl_out arg;
 int res;
 
-padded_iov = malloc((count + 2) * sizeof(struct iovec));
+padded_iov = g_try_new(struct iovec, count + 2);
 if (padded_iov == NULL) {
 return fuse_reply_err(req, ENOMEM);
 }
@@ -680,7 +674,6 @@ int fuse_reply_ioctl_iov(fuse_req_t req, int result, const 
struct iovec *iov,
 memcpy(_iov[2], iov, count * sizeof(struct iovec));
 
 res = send_reply_iov(req, 0, padded_iov, count + 2);
-free(padded_iov);
 
 return res;
 }
diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 6dd73c9b72..a3d37ab696 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -331,6 +331,7 @@ int virtio_send_data_iov(struct fuse_session *se, struct 
fuse_chan *ch,
 VuVirtq *q = vu_get_queue(dev, qi->qidx);
 VuVirtqElement *elem = >elem;
 int ret = 0;
+g_autofree struct iovec *in_sg_cpy = NULL;
 
 assert(count >= 1);
 assert(iov[0].iov_len >= sizeof(struct fuse_out_header));
@@ -384,8 +385,7 @@ int virtio_send_data_iov(struct

[Bug 1923497] Re: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed

2021-05-06 Thread Ed Davison

Sorry, this has not recurred since you asked for the stack trace. Not
sure what "fixed" it.  Closing the bug.

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

Title:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed

Status in QEMU:
  New

Bug description:
  Trying boot/start a Windows 10 VM.  Worked until recently when this
  error started showing up.

  I have the following installed on Fedora 33:
  qemu-kvm-5.1.0-9.fc33.x86_64

  This is the error:

  Error starting domain: internal error: process exited while connecting
  to monitor: qemu-system-x86_64:
  /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed.

  Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in 
cb_wrapper
  callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
  callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 
57, in newfn
  ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in 
startup
  self._backend.create()
File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create
  if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
  libvirt.libvirtError: internal error: process exited while connecting to 
monitor: qemu-system-x86_64: 
/builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: 
bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' 
failed.

  I see this were referenced in a patch from some time ago and
  supposedly fixed.  Here is the patch info I was able to find:

  http://next.patchew.org/QEMU/1515677902-23436-1-git-send-email-
  peter.mayd...@linaro.org/1515677902-23436-10-git-send-email-
  peter.mayd...@linaro.org/

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

[Bug 1923497] Re: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed

2021-05-06 Thread Ed Davison

I guess I should say, you may close the bug.

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

Title:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed

Status in QEMU:
  New

Bug description:
  Trying boot/start a Windows 10 VM.  Worked until recently when this
  error started showing up.

  I have the following installed on Fedora 33:
  qemu-kvm-5.1.0-9.fc33.x86_64

  This is the error:

  Error starting domain: internal error: process exited while connecting
  to monitor: qemu-system-x86_64:
  /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239:
  bios_linker_loader_add_checksum: Assertion `start_offset <
  file->blob->len' failed.

  Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in 
cb_wrapper
  callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
  callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 
57, in newfn
  ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in 
startup
  self._backend.create()
File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create
  if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
  libvirt.libvirtError: internal error: process exited while connecting to 
monitor: qemu-system-x86_64: 
/builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: 
bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' 
failed.

  I see this were referenced in a patch from some time ago and
  supposedly fixed.  Here is the patch info I was able to find:

  http://next.patchew.org/QEMU/1515677902-23436-1-git-send-email-
  peter.mayd...@linaro.org/1515677902-23436-10-git-send-email-
  peter.mayd...@linaro.org/

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

[PULL 04/12] virtiofs: Fixup printf args

From: "Dr. David Alan Gilbert" 

Fixup some fuse_log printf args for 32bit compatibility.

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20210428110100.27757-2-dgilb...@redhat.com>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Stefan Hajnoczi 
---
 tools/virtiofsd/passthrough_ll.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 2c36f4ec46..93a49db3cd 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2011,10 +2011,10 @@ static void lo_getlk(fuse_req_t req, fuse_ino_t ino, 
struct fuse_file_info *fi,
 
 fuse_log(FUSE_LOG_DEBUG,
  "lo_getlk(ino=%" PRIu64 ", flags=%d)"
- " owner=0x%lx, l_type=%d l_start=0x%lx"
- " l_len=0x%lx\n",
- ino, fi->flags, fi->lock_owner, lock->l_type, lock->l_start,
- lock->l_len);
+ " owner=0x%" PRIx64 ", l_type=%d l_start=0x%" PRIx64
+ " l_len=0x%" PRIx64 "\n",
+ ino, fi->flags, fi->lock_owner, lock->l_type,
+ (uint64_t)lock->l_start, (uint64_t)lock->l_len);
 
 if (!lo->posix_lock) {
 fuse_reply_err(req, ENOSYS);
@@ -2061,10 +2061,10 @@ static void lo_setlk(fuse_req_t req, fuse_ino_t ino, 
struct fuse_file_info *fi,
 
 fuse_log(FUSE_LOG_DEBUG,
  "lo_setlk(ino=%" PRIu64 ", flags=%d)"
- " cmd=%d pid=%d owner=0x%lx sleep=%d l_whence=%d"
- " l_start=0x%lx l_len=0x%lx\n",
+ " cmd=%d pid=%d owner=0x%" PRIx64 " sleep=%d l_whence=%d"
+ " l_start=0x%" PRIx64 " l_len=0x%" PRIx64 "\n",
  ino, fi->flags, lock->l_type, lock->l_pid, fi->lock_owner, sleep,
- lock->l_whence, lock->l_start, lock->l_len);
+ lock->l_whence, (uint64_t)lock->l_start, (uint64_t)lock->l_len);
 
 if (!lo->posix_lock) {
 fuse_reply_err(req, ENOSYS);
@@ -3102,9 +3102,10 @@ static void lo_copy_file_range(fuse_req_t req, 
fuse_ino_t ino_in, off_t off_in,
 
 fuse_log(FUSE_LOG_DEBUG,
  "lo_copy_file_range(ino=%" PRIu64 "/fd=%d, "
- "off=%lu, ino=%" PRIu64 "/fd=%d, "
- "off=%lu, size=%zd, flags=0x%x)\n",
- ino_in, in_fd, off_in, ino_out, out_fd, off_out, len, flags);
+ "off=%ju, ino=%" PRIu64 "/fd=%d, "
+ "off=%ju, size=%zd, flags=0x%x)\n",
+ ino_in, in_fd, (intmax_t)off_in,
+ ino_out, out_fd, (intmax_t)off_out, len, flags);
 
 res = copy_file_range(in_fd, _in, out_fd, _out, len, flags);
 if (res < 0) {
-- 
2.31.1

[PULL 11/12] virtiofsd/passthrough_ll.c: Changed local allocations to GLib functions

From: Mahmoud Mandour 

Changed the allocations of some local variables to GLib's allocation
functions, such as g_try_malloc0(), and annotated those variables
as g_autofree. Subsequently, I was able to remove the calls to free().

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-7-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/passthrough_ll.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 406b5bd10e..49c21fd855 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -1653,7 +1653,7 @@ static void lo_do_readdir(fuse_req_t req, fuse_ino_t ino, 
size_t size,
 struct lo_data *lo = lo_data(req);
 struct lo_dirp *d = NULL;
 struct lo_inode *dinode;
-char *buf = NULL;
+g_autofree char *buf = NULL;
 char *p;
 size_t rem = size;
 int err = EBADF;
@@ -1669,7 +1669,7 @@ static void lo_do_readdir(fuse_req_t req, fuse_ino_t ino, 
size_t size,
 }
 
 err = ENOMEM;
-buf = calloc(1, size);
+buf = g_try_malloc0(size);
 if (!buf) {
 goto error;
 }
@@ -1755,7 +1755,6 @@ error:
 } else {
 fuse_reply_buf(req, buf, size - rem);
 }
-free(buf);
 }
 
 static void lo_readdir(fuse_req_t req, fuse_ino_t ino, size_t size,
@@ -2732,7 +2731,7 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 size_t size)
 {
 struct lo_data *lo = lo_data(req);
-char *value = NULL;
+g_autofree char *value = NULL;
 char procname[64];
 const char *name;
 char *mapped_name;
@@ -2773,7 +2772,7 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
  ino, name, size);
 
 if (size) {
-value = malloc(size);
+value = g_try_malloc(size);
 if (!value) {
 goto out_err;
 }
@@ -2812,8 +2811,6 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 fuse_reply_xattr(req, ret);
 }
 out_free:
-free(value);
-
 if (fd >= 0) {
 close(fd);
 }
@@ -2832,7 +2829,7 @@ out:
 static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
 {
 struct lo_data *lo = lo_data(req);
-char *value = NULL;
+g_autofree char *value = NULL;
 char procname[64];
 struct lo_inode *inode;
 ssize_t ret;
@@ -2854,7 +2851,7 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, 
size_t size)
  size);
 
 if (size) {
-value = malloc(size);
+value = g_try_malloc(size);
 if (!value) {
 goto out_err;
 }
@@ -2939,8 +2936,6 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, 
size_t size)
 fuse_reply_xattr(req, ret);
 }
 out_free:
-free(value);
-
 if (fd >= 0) {
 close(fd);
 }
-- 
2.31.1

[PULL 09/12] virtiofsd: Changed allocation of lo_map_elems to GLib's functions

From: Mahmoud Mandour 

Replaced (re)allocation of lo_map_elem structs from realloc() to
GLib's g_try_realloc_n() and replaced the respective free() call
with a g_free().

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-5-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/passthrough_ll.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 93a49db3cd..406b5bd10e 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -406,7 +406,7 @@ static void lo_map_init(struct lo_map *map)
 
 static void lo_map_destroy(struct lo_map *map)
 {
-free(map->elems);
+g_free(map->elems);
 }
 
 static int lo_map_grow(struct lo_map *map, size_t new_nelems)
@@ -418,7 +418,7 @@ static int lo_map_grow(struct lo_map *map, size_t 
new_nelems)
 return 1;
 }
 
-new_elems = realloc(map->elems, sizeof(map->elems[0]) * new_nelems);
+new_elems = g_try_realloc_n(map->elems, new_nelems, sizeof(map->elems[0]));
 if (!new_elems) {
 return 0;
 }
-- 
2.31.1

[PULL 08/12] virtiofsd: Changed allocations of fuse_session to GLib's functions

From: Mahmoud Mandour 

Replaced the allocation and deallocation of fuse_session structs
from calloc() and free() calls to g_try_new0() and g_free().

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-4-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/fuse_lowlevel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
index 88496f9560..7fe2cef1eb 100644
--- a/tools/virtiofsd/fuse_lowlevel.c
+++ b/tools/virtiofsd/fuse_lowlevel.c
@@ -2470,7 +2470,7 @@ void fuse_session_destroy(struct fuse_session *se)
 free(se->vu_socket_path);
 se->vu_socket_path = NULL;
 
-free(se);
+g_free(se);
 }
 
 
@@ -2493,7 +2493,7 @@ struct fuse_session *fuse_session_new(struct fuse_args 
*args,
 return NULL;
 }
 
-se = (struct fuse_session *)calloc(1, sizeof(struct fuse_session));
+se = g_try_new0(struct fuse_session, 1);
 if (se == NULL) {
 fuse_log(FUSE_LOG_ERR, "fuse: failed to allocate fuse object\n");
 goto out1;
@@ -2553,7 +2553,7 @@ struct fuse_session *fuse_session_new(struct fuse_args 
*args,
 out4:
 fuse_opt_free_args(args);
 out2:
-free(se);
+g_free(se);
 out1:
 return NULL;
 }
-- 
2.31.1

[PULL 00/12] virtiofs queue

From: "Dr. David Alan Gilbert" 

The following changes since commit d90f154867ec0ec22fd719164b88716e8fd48672:

  Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504' 
into staging (2021-05-05 20:29:14 +0100)

are available in the Git repository at:

  https://gitlab.com/dagrh/qemu.git tags/pull-virtiofs-20210506

for you to fetch changes up to 67a010f64cc9e33ba19ab389dedaa52013a9de8a:

  virtiofsd/fuse_virtio.c: Changed allocations of locals to GLib (2021-05-06 
19:47:44 +0100)


virtiofsd pull 2021-05-06

A pile of cleanups:

  Use of glib allocators from Mahmoud
  Virtio spec compliance and printf cleanup from me.
  Sugar to turn on xattr when defining xattr mapping from Carlos
  an assert cleanup from Greg

Signed-off-by: Dr. David Alan Gilbert 


Carlos Venegas (2):
  virtiofsd: Allow use "-o xattrmap" without "-o xattr"
  virtiofsd: Add help for -o xattr-mapping

Dr. David Alan Gilbert (2):
  virtiofs: Fixup printf args
  virtiofsd: Don't assume header layout

Greg Kurz (1):
  virtiofsd: Fix side-effect in assert()

Mahmoud Mandour (7):
  virtiofsd: Changed allocations of fuse_req to GLib functions
  virtiofsd: Changed allocations of iovec to GLib's functions
  virtiofsd: Changed allocations of fuse_session to GLib's functions
  virtiofsd: Changed allocation of lo_map_elems to GLib's functions
  virtiofsd: Changed allocations of fv_VuDev & its internals to GLib 
functions
  virtiofsd/passthrough_ll.c: Changed local allocations to GLib functions
  virtiofsd/fuse_virtio.c: Changed allocations of locals to GLib

 tools/virtiofsd/fuse_lowlevel.c  |  43 ++---
 tools/virtiofsd/fuse_virtio.c| 129 ++-
 tools/virtiofsd/helper.c |   3 +
 tools/virtiofsd/passthrough_ll.c |  64 +--
 4 files changed, 139 insertions(+), 100 deletions(-)

[PULL 05/12] virtiofsd: Don't assume header layout

From: "Dr. David Alan Gilbert" 

virtiofsd incorrectly assumed a fixed set of header layout in the virt
queue; assuming that the fuse and write headers were conveniently
separated from the data;  the spec doesn't allow us to take that
convenience, so fix it up to deal with it the hard way.

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20210428110100.27757-3-dgilb...@redhat.com>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Stefan Hajnoczi 
---
 tools/virtiofsd/fuse_virtio.c | 94 +++
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 3e13997406..6dd73c9b72 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -129,18 +129,55 @@ static void fv_panic(VuDev *dev, const char *err)
  * Copy from an iovec into a fuse_buf (memory only)
  * Caller must ensure there is space
  */
-static void copy_from_iov(struct fuse_buf *buf, size_t out_num,
-  const struct iovec *out_sg)
+static size_t copy_from_iov(struct fuse_buf *buf, size_t out_num,
+const struct iovec *out_sg,
+size_t max)
 {
 void *dest = buf->mem;
+size_t copied = 0;
 
-while (out_num) {
+while (out_num && max) {
 size_t onelen = out_sg->iov_len;
+onelen = MIN(onelen, max);
 memcpy(dest, out_sg->iov_base, onelen);
 dest += onelen;
+copied += onelen;
 out_sg++;
 out_num--;
+max -= onelen;
 }
+
+return copied;
+}
+
+/*
+ * Skip 'skip' bytes in the iov; 'sg_1stindex' is set as
+ * the index for the 1st iovec to read data from, and
+ * 'sg_1stskip' is the number of bytes to skip in that entry.
+ *
+ * Returns True if there are at least 'skip' bytes in the iovec
+ *
+ */
+static bool skip_iov(const struct iovec *sg, size_t sg_size,
+ size_t skip,
+ size_t *sg_1stindex, size_t *sg_1stskip)
+{
+size_t vec;
+
+for (vec = 0; vec < sg_size; vec++) {
+if (sg[vec].iov_len > skip) {
+*sg_1stskip = skip;
+*sg_1stindex = vec;
+
+return true;
+}
+
+skip -= sg[vec].iov_len;
+}
+
+*sg_1stindex = vec;
+*sg_1stskip = 0;
+return skip == 0;
 }
 
 /*
@@ -457,6 +494,7 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
 bool allocated_bufv = false;
 struct fuse_bufvec bufv;
 struct fuse_bufvec *pbufv;
+struct fuse_in_header inh;
 
 assert(se->bufsize > sizeof(struct fuse_in_header));
 
@@ -505,14 +543,15 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
  elem->index);
 assert(0); /* TODO */
 }
-/* Copy just the first element and look at it */
-copy_from_iov(, 1, out_sg);
+/* Copy just the fuse_in_header and look at it */
+copy_from_iov(, out_num, out_sg,
+  sizeof(struct fuse_in_header));
+memcpy(, fbuf.mem, sizeof(struct fuse_in_header));
 
 pbufv = NULL; /* Compiler thinks an unitialised path */
-if (out_num > 2 &&
-out_sg[0].iov_len == sizeof(struct fuse_in_header) &&
-((struct fuse_in_header *)fbuf.mem)->opcode == FUSE_WRITE &&
-out_sg[1].iov_len == sizeof(struct fuse_write_in)) {
+if (inh.opcode == FUSE_WRITE &&
+out_len >= (sizeof(struct fuse_in_header) +
+sizeof(struct fuse_write_in))) {
 /*
  * For a write we don't actually need to copy the
  * data, we can just do it straight out of guest memory
@@ -521,15 +560,15 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
  */
 fuse_log(FUSE_LOG_DEBUG, "%s: Write special case\n", __func__);
 
-/* copy the fuse_write_in header afte rthe fuse_in_header */
-fbuf.mem += out_sg->iov_len;
-copy_from_iov(, 1, out_sg + 1);
-fbuf.mem -= out_sg->iov_len;
-fbuf.size = out_sg[0].iov_len + out_sg[1].iov_len;
+fbuf.size = copy_from_iov(, out_num, out_sg,
+  sizeof(struct fuse_in_header) +
+  sizeof(struct fuse_write_in));
+/* That copy reread the in_header, make sure we use the original */
+memcpy(fbuf.mem, , sizeof(struct fuse_in_header));
 
 /* Allocate the bufv, with space for the rest of the iov */
 pbufv = malloc(sizeof(struct fuse_bufvec) +
-   sizeof(struct fuse_buf) * (out_num - 2));
+   sizeof(struct fuse_buf) * out_num);
 if (!pbufv) {
 fuse_log(FUSE_LOG_ERR, "%s: pbufv malloc failed\n",
 __func__);
@@ -540,24 +579,37 @@ static void fv_queue_worker(gpointer data, gpointer 
user_data)
 pbufv->count = 1;
 pbufv->buf[0] = fbuf;
 
-size_t iovindex, pbufvindex;
-iovindex = 2; /* 2 headers, separate iovs */
+

[PULL 06/12] virtiofsd: Changed allocations of fuse_req to GLib functions

From: Mahmoud Mandour 

Replaced the allocation and deallocation of fuse_req structs
using calloc()/free() call pairs to a GLib's g_try_new0()
and g_free().

Signed-off-by: Mahmoud Mandour 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20210420154643.58439-2-ma.mando...@gmail.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 tools/virtiofsd/fuse_lowlevel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
index 58e32fc963..812cef6ef6 100644
--- a/tools/virtiofsd/fuse_lowlevel.c
+++ b/tools/virtiofsd/fuse_lowlevel.c
@@ -106,7 +106,7 @@ static void list_add_req(struct fuse_req *req, struct 
fuse_req *next)
 static void destroy_req(fuse_req_t req)
 {
 pthread_mutex_destroy(>lock);
-free(req);
+g_free(req);
 }
 
 void fuse_free_req(fuse_req_t req)
@@ -130,7 +130,7 @@ static struct fuse_req *fuse_ll_alloc_req(struct 
fuse_session *se)
 {
 struct fuse_req *req;
 
-req = (struct fuse_req *)calloc(1, sizeof(struct fuse_req));
+req = g_try_new0(struct fuse_req, 1);
 if (req == NULL) {
 fuse_log(FUSE_LOG_ERR, "fuse: failed to allocate request\n");
 } else {
@@ -1684,7 +1684,7 @@ static struct fuse_req *check_interrupt(struct 
fuse_session *se,
 if (curr->u.i.unique == req->unique) {
 req->interrupted = 1;
 list_del_req(curr);
-free(curr);
+g_free(curr);
 return NULL;
 }
 }
-- 
2.31.1

[PULL 03/12] virtiofsd: Add help for -o xattr-mapping

From: Carlos Venegas 

The option is not documented in help.

Add small help about the option.

Signed-off-by: Carlos Venegas 
Message-Id: <20210414201207.3612432-3-jose.carlos.venegas.mu...@intel.com>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Connor Kuehl 
---
 tools/virtiofsd/helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/virtiofsd/helper.c b/tools/virtiofsd/helper.c
index 28243b51b2..5e98ed702b 100644
--- a/tools/virtiofsd/helper.c
+++ b/tools/virtiofsd/helper.c
@@ -172,6 +172,9 @@ void fuse_cmdline_help(void)
"   default: no_writeback\n"
"-o xattr|no_xattr  enable/disable xattr\n"
"   default: no_xattr\n"
+   "-o xattrmap=  Enable xattr mapping (enables 
xattr)\n"
+   "is a string consists of a 
series of rules\n"
+   "   e.g. -o 
xattrmap=:map::user.virtiofs.:\n"
"-o modcaps=CAPLIST Modify the list of capabilities\n"
"   e.g. -o modcaps=+sys_admin:-chown\n"
"--rlimit-nofile=  set maximum number of file 
descriptors\n"
-- 
2.31.1

[PULL 01/12] virtiofsd: Fix side-effect in assert()

From: Greg Kurz 

It is bad practice to put an expression with a side-effect in
assert() because the side-effect won't happen if the code is
compiled with -DNDEBUG.

Use an intermediate variable. Consolidate this in an macro to
have proper line numbers when the assertion is hit.

virtiofsd: ../../tools/virtiofsd/passthrough_ll.c:2797: lo_getxattr:
 Assertion `fchdir_res == 0' failed.
Aborted

  2796  /* fchdir should not fail here */
=>2797  FCHDIR_NOFAIL(lo->proc_self_fd);
  2798  ret = getxattr(procname, name, value, size);
  2799  FCHDIR_NOFAIL(lo->root.fd);

Fixes: bdfd66788349 ("virtiofsd: Fix xattr operations")
Cc: misono.tomoh...@jp.fujitsu.com
Signed-off-by: Greg Kurz 
Message-Id: <20210409100627.451573-1-gr...@kaod.org>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Philippe Mathieu-Daudé 
---
 tools/virtiofsd/passthrough_ll.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 1553d2ef45..6592f96f68 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2723,6 +2723,11 @@ static int xattr_map_server(const struct lo_data *lo, 
const char *server_name,
 return -ENODATA;
 }
 
+#define FCHDIR_NOFAIL(fd) do { \
+int fchdir_res = fchdir(fd);   \
+assert(fchdir_res == 0);   \
+} while (0)
+
 static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *in_name,
 size_t size)
 {
@@ -2789,9 +2794,9 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 ret = fgetxattr(fd, name, value, size);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = getxattr(procname, name, value, size);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }
 
 if (ret == -1) {
@@ -2864,9 +2869,9 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, 
size_t size)
 ret = flistxattr(fd, value, size);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = listxattr(procname, value, size);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }
 
 if (ret == -1) {
@@ -3000,9 +3005,9 @@ static void lo_setxattr(fuse_req_t req, fuse_ino_t ino, 
const char *in_name,
 ret = fsetxattr(fd, name, value, size, flags);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = setxattr(procname, name, value, size, flags);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }
 
 saverr = ret == -1 ? errno : 0;
@@ -3066,9 +3071,9 @@ static void lo_removexattr(fuse_req_t req, fuse_ino_t 
ino, const char *in_name)
 ret = fremovexattr(fd, name);
 } else {
 /* fchdir should not fail here */
-assert(fchdir(lo->proc_self_fd) == 0);
+FCHDIR_NOFAIL(lo->proc_self_fd);
 ret = removexattr(procname, name);
-assert(fchdir(lo->root.fd) == 0);
+FCHDIR_NOFAIL(lo->root.fd);
 }
 
 saverr = ret == -1 ? errno : 0;
-- 
2.31.1

[PULL 02/12] virtiofsd: Allow use "-o xattrmap" without "-o xattr"

From: Carlos Venegas 

When -o xattrmap is used, it will not work unless xattr is enabled.

This patch enables xattr when -o xattrmap is used.

Signed-off-by: Carlos Venegas 
Message-Id: <20210414201207.3612432-2-jose.carlos.venegas.mu...@intel.com>
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Connor Kuehl 
---
 tools/virtiofsd/passthrough_ll.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 6592f96f68..2c36f4ec46 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -3831,6 +3831,7 @@ int main(int argc, char *argv[])
 }
 
 if (lo.xattrmap) {
+lo.xattr = 1;
 parse_xattrmap();
 }
 
-- 
2.31.1

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 ***
https://bugs.launchpad.net/bugs/1921948

You missed including libstdc++.so.6.
I ran with whatever libstdc++ I had lying around.

With qemu head, this terminates with

~/qemu/bld/qemu-aarch64 -L . ./bitfield-2.exe 
*** stack smashing detected ***: terminated
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

I suspect the relevant MTE portion of this bug report
to be a duplicate of a kasan bug, the fix for which did
not make 6.0, but has since been committed as 09641ef93112.

** This bug has been marked a duplicate of bug 1921948
   MTE tags not checked properly for unaligned accesses at EL1

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

Title:
  qemu-aarch64 MTE fails to report tag mismatch

Status in QEMU:
  New

Bug description:
  Hi,

  While running the GCC testsuite with qemu-6.0 as simulator, I noticed
  several errors in the hwasan testsuite (output pattern tests).

  I am attaching:
  bitfield-2.exe
  ld-linux-aarch64.so.1
  libc.so.6
  libdl.so.2
  libhwasan.so.0
  libm.so.6
  libpthread.so.0
  librt.so.1

  The testcase can be executed via:
  qemu-aarch64 -L . bitfield-2.exe

  it currently generates:
  HWAddressSanitizer:DEADLYSIGNAL
  ==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x00f0 
(pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
  ==21137==The signal is caused by a UNKNOWN memory access.
  ==21137==Hint: address points to the zero page.
  #0 0x550084e318 in GetAccessInfo 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
  #1 0x550084e318 in HwasanOnSIGTRAP 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
  #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
  #3 0x5f01651fec  ()
  #4 0x550084b508 in __hwasan_load2 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
  #5 0x400768 in f 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
  #6 0x4007d0 in main 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
  #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
  #8 0x400688  
(/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)

  HWAddressSanitizer can not provide additional info.
  SUMMARY: HWAddressSanitizer: SEGV 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
 in GetAccessInfo
  ==21146==ABORTING

  while the testcase expects HWAddressSanitizer: tag-mismatch on address
  0x.

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

[Bug 1921948] Re: MTE tags not checked properly for unaligned accesses at EL1

** Changed in: qemu
   Status: In Progress => Fix Committed

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

Title:
  MTE tags not checked properly for unaligned accesses at EL1

Status in QEMU:
  Fix Committed

Bug description:
  For kernel memory accesses that span across two memory granules,
  QEMU's MTE implementation only checks the tag of the first granule but
  not of the second one.

  To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS
  enabled, apply the patch below, and boot the kernel:

  diff --git a/sound/last.c b/sound/last.c
  index f0bb98780e70..04745cb30b74 100644
  --- a/sound/last.c
  +++ b/sound/last.c
  @@ -5,12 +5,18 @@
*/
   
   #include 
  +#include 
   #include 
   
   static int __init alsa_sound_last_init(void)
   {
  struct snd_card *card;
  int idx, ok = 0;
  +
  +   char *ptr = kmalloc(128, GFP_KERNEL);
  +   pr_err("KASAN report should follow:\n");
  +   *(volatile unsigned long *)(ptr + 124);
  +   kfree(ptr);
  
  printk(KERN_INFO "ALSA device list:\n");
  for (idx = 0; idx < SNDRV_CARDS; idx++) {

  KASAN tags the 128 allocated bytes with the same tag as the returned
  pointer. The memory granule that follows the 128 allocated bytes has a
  different tag (with 1/15 probability).

  Expected result: a tag fault is detected and a KASAN report is printed when 
accessing bytes [124, 130).
  Observed result: no tag fault is detected and no KASAN report is printed.

  Here are the flags that I use to run QEMU if they matter:

  qemu-system-aarch64 -s -machine virt,mte=on -cpu max -m 2G -smp 2 -net
  user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic
  -nographic -kernel ./Image -append "console=ttyAMA0 root=/dev/vda
  earlyprintk=serial" -drive file=./fs.img,format=raw,if=virtio -no-
  shutdown -no-reboot

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

Re: [PATCH] virtio-blk: Convert QEMUBH callback to "bitops.h" API


On 5/6/21 8:54 AM, Philippe Mathieu-Daudé wrote:

  static void notify_guest_bh(void *opaque)
  {
  VirtIOBlockDataPlane *s = opaque;
-unsigned nvqs = s->conf->num_queues;
-unsigned long bitmap[BITS_TO_LONGS(nvqs)];
-unsigned j;
  
-memcpy(bitmap, s->batch_notify_vqs, sizeof(bitmap));

-memset(s->batch_notify_vqs, 0, sizeof(bitmap));
-
-for (j = 0; j < nvqs; j += BITS_PER_LONG) {
-unsigned long bits = bitmap[j / BITS_PER_LONG];
-
-while (bits != 0) {
-unsigned i = j + ctzl(bits);
+for (unsigned i = 0; i < s->conf->num_queues; i++) {


Is this bitmap dense enough that you want to iterate by index, or is it sparse 
enough to iterate via find_first_bit/find_next_bit?


In either case, leave the copy of  s->conf->num_queues to a local variable.


r~

Re: [PATCH 09/10] pckbd: correctly disable PS/2 communication

2021-05-06 Thread Volker Rümelin


Hi Volker,

On 5/5/21 9:21 PM, Volker Rümelin wrote:

Currently the PS/2 controller command KBD_CCMD_MOUSE_DISABLE
doesn't disable the PS/2 mouse communication at all, and the
PS/2 controller commands KBD_CCMD_KBD_DISABLE and
KBD_CCMD_KBD_ENABLE disable and enable the keyboard interrupt,
which is very different from what a real PS/2 controller does.
A guest may notice the difference.

Mask out pending data on disabled queues to correctly disable
the PS/2 controller communication.

Signed-off-by: Volker Rümelin 
---
  hw/input/pckbd.c | 48 +++-
  1 file changed, 35 insertions(+), 13 deletions(-)
+static uint8_t kbd_pending(KBDState *s)
+{
+return s->pending & (~s->mode | ~(KBD_PENDING_KBD | KBD_PENDING_AUX));
+}

Please introduce kbd_pending() in a preliminary patch.


OK, I will send a version 2 patch series with an additional patch.

With best regards,
Volker


  /* update irq and KBD_STAT_[MOUSE_]OBF */
  static void kbd_update_irq(KBDState *s)
  {
+uint8_t pending = kbd_pending(s);
+
  s->status &= ~(KBD_STAT_OBF | KBD_STAT_MOUSE_OBF);
  s->outport &= ~(KBD_OUT_OBF | KBD_OUT_MOUSE_OBF);
-if (s->pending) {
+if (pending) {
  s->status |= KBD_STAT_OBF;
  s->outport |= KBD_OUT_OBF;
-if (s->pending & KBD_PENDING_CTRL_KBD) {
+if (pending & KBD_PENDING_CTRL_KBD) {
  s->obsrc = KBD_OBSRC_CTRL;

Re: [PATCH v5 00/10] numa/exec/migration: Fix resizing RAM blocks while migrating

2021-05-06 Thread Dr. David Alan Gilbert

* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Thu, Apr 29, 2021 at 01:26:58PM +0200, David Hildenbrand wrote:
> > v4 has been floating around for a while. Let's see if we can find someone
> > to merge this; or at least give some more feedback ... all patches have
> > at least one RB.
> 
> Acked-by: Eduardo Habkost 
> 
> David Gilbert: I assume this should go through your tree?

Yep, I'm going to cook a migration pull next week.

Dave

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

Re: [PATCH] target/mips: Fix potential integer overflow (CID 1452921)


On 5/5/21 2:51 PM, Philippe Mathieu-Daudé wrote:

Use the BIT_ULL() macro to ensure we use 64-bit arithmetic.
This fixes the following Coverity issue (OVERFLOW_BEFORE_WIDEN):

   CID 1452921:  Integer handling issues:

 Potentially overflowing expression "1 << w" with type "int"
 (32 bits, signed) is evaluated using 32-bit arithmetic, and
 then used in a context that expects an expression of type
 "uint64_t" (64 bits, unsigned).

Fixes: 074cfcb4dae ("target/mips: Implement hardware page table walker")
Signed-off-by: Philippe Mathieu-Daudé
---
  target/mips/tcg/sysemu/tlb_helper.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Reviewed-by: Richard Henderson 

r~

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

I have re-tested at commit d45a5270d075ea589f0b0ddcf963a5fea1f500ac, and
the build succeeded, so it looks like the problem has been fixed.


** 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/1878348

Title:
  --static build fails in v5.0 (since
  5010cec2bc87dafab39b3913c8ca91f88df9c540)

Status in QEMU:
  Fix Released

Bug description:
  Hi,

  Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu
  fails when configured with --static (eg ../configure --target-
  list=x86_64-softmmu,x86_64-linux-user --enable-debug --static).

  On ubuntu 16.04, it fails to find -lffi and -lselinux.

  After I apt-get install libffi-dev libselinux1-dev, the build still fails:
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_pre_save':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:29: undefined 
reference to `_TRACE_DBUS_VMSTATE_PRE_SAVE_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_post_load':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:52: undefined 
reference to `_TRACE_DBUS_VMSTATE_POST_LOAD_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_loading':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:75: undefined 
reference to `_TRACE_DBUS_VMSTATE_LOADING_DSTATE'
  ../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_saving':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:98: undefined 
reference to `_TRACE_DBUS_VMSTATE_SAVING_DSTATE'
  collect2: error: ld returned 1 exit status

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

Re: [PATCH v5 00/10] numa/exec/migration: Fix resizing RAM blocks while migrating

2021-05-06 Thread Eduardo Habkost

On Thu, Apr 29, 2021 at 01:26:58PM +0200, David Hildenbrand wrote:
> v4 has been floating around for a while. Let's see if we can find someone
> to merge this; or at least give some more feedback ... all patches have
> at least one RB.

Acked-by: Eduardo Habkost 

David Gilbert: I assume this should go through your tree?

-- 
Eduardo

Re: [PATCH v2] tcg: Use correct trap number for page faults on *BSD systems

2021-05-06 Thread Warner Losh

On Thu, May 6, 2021 at 11:51 AM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 5/6/21 10:38 AM, Warner Losh wrote:
> > The trap number for a page fault on BSD systems is T_PAGEFLT not 0xe.
> 0xe is
> > used by Linux and represents the intel hardware trap vector. The BSD
> kernels,
> > however, translate this to T_PAGEFLT in their Xpage, Xtrap0e, Xtrap14,
> etc fault
> > handlers. This is true for i386 and x86_64, though the name of the trap
> hanlder
> > can very on the flavor of BSD. As far as I can tell, Linux doesn't
> provide a
> > define for this value. Invent a new one (PAGE_FAULT_TRAP) and use it
> instead to
> > avoid uglier ifdefs.
> >
> > Signed-off-by: Mark Johnston
> > Signed-off-by: Juergen Lock
> > [ Rework to avoid ifdefs and expand it to i386 ]
> > Signed-off-by: Warner Losh
> > ---
> >   accel/tcg/user-exec.c | 14 --
> >   1 file changed, 12 insertions(+), 2 deletions(-)
>
> Queued to tcg-next, thanks.
>
> Looks like this area could use a bit of cleanup...
>

No arguments from me there... Thanks!

Warner

Re: [PULL 00/46] ppc-for-6.1 queue 20210504

On Tue, 4 May 2021 at 06:53, David Gibson  wrote:
>
> The following changes since commit 15106f7dc3290ff3254611f265849a314a93eb0e:
>
>   Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-hex-20210502' 
> into staging (2021-05-02 16:23:05 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/dgibson/qemu.git tags/ppc-for-6.1-20210504
>
> for you to fetch changes up to 4bb32cd7b1e42c46d274b727c8be8e45b4df3814:
>
>   hw/ppc/pnv_psi: Use device_cold_reset() instead of device_legacy_reset() 
> (2021-05-04 13:12:59 +1000)
>
> 
> ppc patch queue 2021-05-04
>
> Here's the first ppc pull request for qemu-6.1.  It has a wide variety
> of stuff accumulated during the 6.0 freeze.  Highlights are:
>
>  * Multi-phase reset cleanups for PAPR
>  * Preliminary cleanups towards allowing !CONFIG_TCG for the ppc target
>  * Cleanup of AIL logic and extension to POWER10
>  * Further improvements to handling of hot unplug failures on PAPR
>  * Allow much larger numbers of CPU on pseries
>  * Support for the H_SCM_HEALTH hypercall
>  * Add support for the Pegasos II board
>  * Substantial cleanup to hflag handling
>  * Assorted minor fixes and cleanups
>


Applied, thanks.

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

-- PMM

Re: [PATCH v2] tcg: Use correct trap number for page faults on *BSD systems


On 5/6/21 10:38 AM, Warner Losh wrote:

The trap number for a page fault on BSD systems is T_PAGEFLT not 0xe. 0xe is
used by Linux and represents the intel hardware trap vector. The BSD kernels,
however, translate this to T_PAGEFLT in their Xpage, Xtrap0e, Xtrap14, etc fault
handlers. This is true for i386 and x86_64, though the name of the trap hanlder
can very on the flavor of BSD. As far as I can tell, Linux doesn't provide a
define for this value. Invent a new one (PAGE_FAULT_TRAP) and use it instead to
avoid uglier ifdefs.

Signed-off-by: Mark Johnston
Signed-off-by: Juergen Lock
[ Rework to avoid ifdefs and expand it to i386 ]
Signed-off-by: Warner Losh
---
  accel/tcg/user-exec.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)


Queued to tcg-next, thanks.

Looks like this area could use a bit of cleanup...


r~

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

FWIW, a configure line that works for me for static system-emulation
builds on Ubuntu 18.04 with QEMU 6.0 is:

'../../configure' '--target-list=arm-softmmu' '--enable-debug' '--
static' '--disable-tools' '--disable-sdl' '--disable-gtk' '--disable-
vnc' '--disable-virtfs' '--disable-attr' '--disable-libiscsi'
'--disable-libnfs' '--disable-libusb' '--disable-opengl' '--disable-
numa' '--disable-usb-redir' '--disable-bzip2' '--audio-drv-list='
'--disable-guest-agent' '--disable-vte' '--disable-mpath' '--disable-
libudev' '--disable-vhost-user' '--disable-curl'

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

Title:
  --static build fails in v5.0 (since
  5010cec2bc87dafab39b3913c8ca91f88df9c540)

Status in QEMU:
  Fix Released

Bug description:
  Hi,

  Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu
  fails when configured with --static (eg ../configure --target-
  list=x86_64-softmmu,x86_64-linux-user --enable-debug --static).

  On ubuntu 16.04, it fails to find -lffi and -lselinux.

  After I apt-get install libffi-dev libselinux1-dev, the build still fails:
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_pre_save':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:29: undefined 
reference to `_TRACE_DBUS_VMSTATE_PRE_SAVE_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_post_load':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:52: undefined 
reference to `_TRACE_DBUS_VMSTATE_POST_LOAD_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_loading':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:75: undefined 
reference to `_TRACE_DBUS_VMSTATE_LOADING_DSTATE'
  ../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_saving':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:98: undefined 
reference to `_TRACE_DBUS_VMSTATE_SAVING_DSTATE'
  collect2: error: ld returned 1 exit status

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

Re: [PATCH 7/7] virtiofsd: use GDateTime for formatting timestamp for debug messages

2021-05-06 Thread Dr. David Alan Gilbert

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > The GDateTime APIs provided by GLib avoid portability pitfalls, such
> > > as some platforms where 'struct timeval.tv_sec' field is still 'long'
> > > instead of 'time_t'. When combined with automatic cleanup, GDateTime
> > > often results in simpler code too.
> > > 
> > > Signed-off-by: Daniel P. Berrangé 
> > 
> > Reviewed-by: Dr. David Alan Gilbert 
> 
> Queued this 7/7 via virtiofsd

Hi Dan,
  I've had to drop this because it triggers seccomp:

#0  0x7f0afec4d21b in readlink () from /lib64/libc.so.6
#1  0x7f0afeecff24 in g_file_read_link () from /lib64/libglib-2.0.so.0
#2  0x7f0afef16390 in g_time_zone_new_identifier () from 
/lib64/libglib-2.0.so.0
#3  0x7f0afef16fe8 in g_time_zone_new_local () from /lib64/libglib-2.0.so.0
#4  0x7f0afeec9520 in g_date_time_new_now_local () from 
/lib64/libglib-2.0.so.0
#5  0x55a6bd6bc27a in log_func (level=FUSE_LOG_INFO, fmt=0x55a6bd6e3cda 
"%s: Entry\n", ap=0x7ffece4b2f50) at ../tools/virtiofsd/passthrough_ll.c:3578
#6  0x55a6bd6b3dd5 in fuse_log (level=level@entry=FUSE_LOG_INFO, 
fmt=fmt@entry=0x55a6bd6e3cda "%s: Entry\n") at ../tools/virtiofsd/fuse_log.c:37
#7  0x55a6bd6ba9fd in virtio_loop (se=se@entry=0x55a6bee29a30) at 
../tools/virtiofsd/fuse_virtio.c:878
#8  0x55a6bd6b2017 in main (argc=, argv=) at 
../tools/virtiofsd/passthrough_ll.c:3868


so you either need to add seccomp rules and/or persuade it not to moan;
maybe dropping down to UTC would work.

Dave

> > > ---
> > >  tools/virtiofsd/passthrough_ll.c | 25 -
> > >  1 file changed, 4 insertions(+), 21 deletions(-)
> > > 
> > > diff --git a/tools/virtiofsd/passthrough_ll.c 
> > > b/tools/virtiofsd/passthrough_ll.c
> > > index 1553d2ef45..cdd224918c 100644
> > > --- a/tools/virtiofsd/passthrough_ll.c
> > > +++ b/tools/virtiofsd/passthrough_ll.c
> > > @@ -3558,10 +3558,6 @@ static void setup_nofile_rlimit(unsigned long 
> > > rlimit_nofile)
> > >  static void log_func(enum fuse_log_level level, const char *fmt, va_list 
> > > ap)
> > >  {
> > >  g_autofree char *localfmt = NULL;
> > > -struct timespec ts;
> > > -struct tm tm;
> > > -char sec_fmt[sizeof "2020-12-07 18:17:54"];
> > > -char zone_fmt[sizeof "+0100"];
> > >  
> > >  if (current_log_level < level) {
> > >  return;
> > > @@ -3573,23 +3569,10 @@ static void log_func(enum fuse_log_level level, 
> > > const char *fmt, va_list ap)
> > >  localfmt = g_strdup_printf("[ID: %08ld] %s", 
> > > syscall(__NR_gettid),
> > > fmt);
> > >  } else {
> > > -/* try formatting a broken-down timestamp */
> > > -if (clock_gettime(CLOCK_REALTIME, ) != -1 &&
> > > -localtime_r(_sec, ) != NULL &&
> > > -strftime(sec_fmt, sizeof sec_fmt, "%Y-%m-%d %H:%M:%S",
> > > - ) != 0 &&
> > > -strftime(zone_fmt, sizeof zone_fmt, "%z", ) != 0) {
> > > -localfmt = g_strdup_printf("[%s.%02ld%s] [ID: %08ld] %s",
> > > -   sec_fmt,
> > > -   ts.tv_nsec / (10L * 1000 * 
> > > 1000),
> > > -   zone_fmt, 
> > > syscall(__NR_gettid),
> > > -   fmt);
> > > -} else {
> > > -/* fall back to a flat timestamp */
> > > -localfmt = g_strdup_printf("[%" PRId64 "] [ID: %08ld] 
> > > %s",
> > > -   get_clock(), 
> > > syscall(__NR_gettid),
> > > -   fmt);
> > > -}
> > > +g_autoptr(GDateTime) now = g_date_time_new_now_local();
> > > +g_autofree char *nowstr = g_date_time_format(now, "%Y-%m-%d 
> > > %H:%M:%S.%f%z");
> > > +localfmt = g_strdup_printf("[%s] [ID: %08ld] %s",
> > > +   nowstr, syscall(__NR_gettid), 
> > > fmt);
> > >  }
> > >  fmt = localfmt;
> > >  }
> > > -- 
> > > 2.31.1
> > > 
> > -- 
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > 
> > 
> -- 
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Bug 1873335] Re: Dos Keypad is not working for numbers - numlock is not working

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


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

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

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

Title:
  Dos Keypad is not working for numbers - numlock is not working

Status in QEMU:
  Expired

Bug description:
  Hello,
  i tried to use Qemu 4.2 for Dos, but there is problem what in Dos is not 
possible turn on Numlock for input numbers, so games need it.. Numlock only 
working as arrow keys.
    I tested bough Windows and Linux builds.

  With same setting, when i use Windows 98 or later os, numlock is
  working fine.

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

[Bug 1927530] [NEW] qemu-aarch64 MTE fails to report tag mismatch

Public bug reported:

Hi,

While running the GCC testsuite with qemu-6.0 as simulator, I noticed
several errors in the hwasan testsuite (output pattern tests).

I am attaching:
bitfield-2.exe
ld-linux-aarch64.so.1
libc.so.6
libdl.so.2
libhwasan.so.0
libm.so.6
libpthread.so.0
librt.so.1

The testcase can be executed via:
qemu-aarch64 -L . bitfield-2.exe

it currently generates:
HWAddressSanitizer:DEADLYSIGNAL
==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x00f0 (pc 
0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
==21137==The signal is caused by a UNKNOWN memory access.
==21137==Hint: address points to the zero page.
#0 0x550084e318 in GetAccessInfo 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
#1 0x550084e318 in HwasanOnSIGTRAP 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
#2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
#3 0x5f01651fec  ()
#4 0x550084b508 in __hwasan_load2 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
#5 0x400768 in f 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
#6 0x4007d0 in main 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
#7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
#8 0x400688  
(/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)

HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
 in GetAccessInfo
==21146==ABORTING

while the testcase expects HWAddressSanitizer: tag-mismatch on address
0x.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "binary and shared libs"
   
https://bugs.launchpad.net/bugs/1927530/+attachment/5495265/+files/qemu-bug-hwasan-aarch64.tar.xz

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

Title:
  qemu-aarch64 MTE fails to report tag mismatch

Status in QEMU:
  New

Bug description:
  Hi,

  While running the GCC testsuite with qemu-6.0 as simulator, I noticed
  several errors in the hwasan testsuite (output pattern tests).

  I am attaching:
  bitfield-2.exe
  ld-linux-aarch64.so.1
  libc.so.6
  libdl.so.2
  libhwasan.so.0
  libm.so.6
  libpthread.so.0
  librt.so.1

  The testcase can be executed via:
  qemu-aarch64 -L . bitfield-2.exe

  it currently generates:
  HWAddressSanitizer:DEADLYSIGNAL
  ==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x00f0 
(pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
  ==21137==The signal is caused by a UNKNOWN memory access.
  ==21137==Hint: address points to the zero page.
  #0 0x550084e318 in GetAccessInfo 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
  #1 0x550084e318 in HwasanOnSIGTRAP 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
  #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
  #3 0x5f01651fec  ()
  #4 0x550084b508 in __hwasan_load2 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
  #5 0x400768 in f 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
  #6 0x4007d0 in main 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
  #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
  #8 0x400688  
(/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)

  HWAddressSanitizer can not provide additional info.
  SUMMARY: HWAddressSanitizer: SEGV 
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
 in GetAccessInfo
  ==21146==ABORTING

  while the testcase expects HWAddressSanitizer: tag-mismatch on address
  0x.

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

[Bug 1873338] Re: Dos on the fly CD image replacement is not Working with DOS

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


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

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

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

Title:
  Dos on the fly CD image replacement is not Working with DOS

Status in QEMU:
  Expired

Bug description:
  Im not able to exchange CD image on the fly (needed for some games). I
  messed with command like - in console(ATL+CRTL+2) eject ide1-cd0 and
  change ide-cd0 D:/Games/!Emulators/Dos-QEMU/ISOs/TestChangeISO.iso ,
  but system so never able to find new CD data.. simply drive so empty..
  but when i reboot virtual machine, new change image is now working.

    Qemu 4.2. Linux Mint 19.3 and also Windows 10.

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

[PATCH v2] tcg: Use correct trap number for page faults on *BSD systems

2021-05-06 Thread Warner Losh

The trap number for a page fault on BSD systems is T_PAGEFLT not 0xe. 0xe is
used by Linux and represents the intel hardware trap vector. The BSD kernels,
however, translate this to T_PAGEFLT in their Xpage, Xtrap0e, Xtrap14, etc fault
handlers. This is true for i386 and x86_64, though the name of the trap hanlder
can very on the flavor of BSD. As far as I can tell, Linux doesn't provide a
define for this value. Invent a new one (PAGE_FAULT_TRAP) and use it instead to
avoid uglier ifdefs.

Signed-off-by: Mark Johnston 
Signed-off-by: Juergen Lock 
[ Rework to avoid ifdefs and expand it to i386 ]
Signed-off-by: Warner Losh 
---
 accel/tcg/user-exec.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 0d8cc27b21..959fec1257 100644
--- a/accel/tcg/user-exec.c
+++ b/accel/tcg/user-exec.c
@@ -260,6 +260,7 @@ void *probe_access(CPUArchState *env, target_ulong addr, 
int size,
 #define TRAP_sig(context)((context)->uc_mcontext.__gregs[_REG_TRAPNO])
 #define ERROR_sig(context)   ((context)->uc_mcontext.__gregs[_REG_ERR])
 #define MASK_sig(context)((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP  T_PAGEFLT
 #elif defined(__FreeBSD__) || defined(__DragonFly__)
 #include 
 
@@ -267,16 +268,19 @@ void *probe_access(CPUArchState *env, target_ulong addr, 
int size,
 #define TRAP_sig(context)((context)->uc_mcontext.mc_trapno)
 #define ERROR_sig(context)   ((context)->uc_mcontext.mc_err)
 #define MASK_sig(context)((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP  T_PAGEFLT
 #elif defined(__OpenBSD__)
 #define EIP_sig(context) ((context)->sc_eip)
 #define TRAP_sig(context)((context)->sc_trapno)
 #define ERROR_sig(context)   ((context)->sc_err)
 #define MASK_sig(context)((context)->sc_mask)
+#define PAGE_FAULT_TRAP  T_PAGEFLT
 #else
 #define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
 #define TRAP_sig(context)((context)->uc_mcontext.gregs[REG_TRAPNO])
 #define ERROR_sig(context)   ((context)->uc_mcontext.gregs[REG_ERR])
 #define MASK_sig(context)((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP  0xe
 #endif
 
 int cpu_signal_handler(int host_signum, void *pinfo,
@@ -302,7 +306,8 @@ int cpu_signal_handler(int host_signum, void *pinfo,
 pc = EIP_sig(uc);
 trapno = TRAP_sig(uc);
 return handle_cpu_signal(pc, info,
- trapno == 0xe ? (ERROR_sig(uc) >> 1) & 1 : 0,
+ trapno == PAGE_FAULT_TRAP ?
+ (ERROR_sig(uc) >> 1) & 1 : 0,
  _sig(uc));
 }
 
@@ -313,11 +318,13 @@ int cpu_signal_handler(int host_signum, void *pinfo,
 #define TRAP_sig(context) ((context)->uc_mcontext.__gregs[_REG_TRAPNO])
 #define ERROR_sig(context)((context)->uc_mcontext.__gregs[_REG_ERR])
 #define MASK_sig(context) ((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP   T_PAGEFLT
 #elif defined(__OpenBSD__)
 #define PC_sig(context)   ((context)->sc_rip)
 #define TRAP_sig(context) ((context)->sc_trapno)
 #define ERROR_sig(context)((context)->sc_err)
 #define MASK_sig(context) ((context)->sc_mask)
+#define PAGE_FAULT_TRAP   T_PAGEFLT
 #elif defined(__FreeBSD__) || defined(__DragonFly__)
 #include 
 
@@ -325,11 +332,13 @@ int cpu_signal_handler(int host_signum, void *pinfo,
 #define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno)
 #define ERROR_sig(context)((context)->uc_mcontext.mc_err)
 #define MASK_sig(context) ((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP   T_PAGEFLT
 #else
 #define PC_sig(context)   ((context)->uc_mcontext.gregs[REG_RIP])
 #define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
 #define ERROR_sig(context)((context)->uc_mcontext.gregs[REG_ERR])
 #define MASK_sig(context) ((context)->uc_sigmask)
+#define PAGE_FAULT_TRAP   0xe
 #endif
 
 int cpu_signal_handler(int host_signum, void *pinfo,
@@ -347,7 +356,8 @@ int cpu_signal_handler(int host_signum, void *pinfo,
 
 pc = PC_sig(uc);
 return handle_cpu_signal(pc, info,
- TRAP_sig(uc) == 0xe ? (ERROR_sig(uc) >> 1) & 1 : 
0,
+ TRAP_sig(uc) == PAGE_FAULT_TRAP ?
+ (ERROR_sig(uc) >> 1) & 1 : 0,
  _sig(uc));
 }
 
-- 
2.22.1

[Bug 1873337] Re: Arrow keys press is double in some programs in Dos

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


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

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

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

Title:
  Arrow keys press is double in some programs in Dos

Status in QEMU:
  Expired

Bug description:
  Hello,
  im trying to use Qemu for Dos machines.

   But there is problem with some programs that arrow key press is
  double in some problems. As advanced Filemanagers - Dos Navigator or
  File Wizard, same Scandisk.

  There is gif:
  https://www.vogons.org/download/file.php?id=77141=view

   Its blocking to use such problem, unless you use Numlock key for it,
  but im used 25+ years to arrow keys and its bug.. I guess that it
  would mess with some games too.

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

Re: [PATCH] tcg: Use correct trap number for page faults on *BSD systems

2021-05-06 Thread Warner Losh

On Thu, May 6, 2021 at 10:43 AM Warner Losh  wrote:

> The trap number for a page fault on BSD systems is T_PAGEFLT not 0xe. 0xe
> is
> used by Linux and represents the intel hardware trap vector. The BSD
> kernels,
> however, translate this to T_PAGEFLT in their Xpage, Xtrap0e, Xtrap14, etc
> fault
> handlers. This is true for i386 and x86_64, though the name of the trap
> hanlder
> can very on the flavor of BSD. As far as I can tell, Linux doesn't provide
> a
>

I've been burned by git's # comments in the commit message. This is missing
a line:

#define for this value. Invent a new one and use it instead to


> avoid uglier #ifdefs.
>

I'll amend and resend.


> Signed-off-by: Mark Johnston 
> Signed-off-by: Juergen Lock 
> [ Rework to avoid ifdefs and expand it to i386 ]
> Signed-off-by: Warner Losh 
> ---
>  accel/tcg/user-exec.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
> index 0d8cc27b21..959fec1257 100644
> --- a/accel/tcg/user-exec.c
> +++ b/accel/tcg/user-exec.c
> @@ -260,6 +260,7 @@ void *probe_access(CPUArchState *env, target_ulong
> addr, int size,
>  #define TRAP_sig(context)((context)->uc_mcontext.__gregs[_REG_TRAPNO])
>  #define ERROR_sig(context)   ((context)->uc_mcontext.__gregs[_REG_ERR])
>  #define MASK_sig(context)((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP  T_PAGEFLT
>  #elif defined(__FreeBSD__) || defined(__DragonFly__)
>  #include 
>
> @@ -267,16 +268,19 @@ void *probe_access(CPUArchState *env, target_ulong
> addr, int size,
>  #define TRAP_sig(context)((context)->uc_mcontext.mc_trapno)
>  #define ERROR_sig(context)   ((context)->uc_mcontext.mc_err)
>  #define MASK_sig(context)((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP  T_PAGEFLT
>  #elif defined(__OpenBSD__)
>  #define EIP_sig(context) ((context)->sc_eip)
>  #define TRAP_sig(context)((context)->sc_trapno)
>  #define ERROR_sig(context)   ((context)->sc_err)
>  #define MASK_sig(context)((context)->sc_mask)
> +#define PAGE_FAULT_TRAP  T_PAGEFLT
>  #else
>  #define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
>  #define TRAP_sig(context)((context)->uc_mcontext.gregs[REG_TRAPNO])
>  #define ERROR_sig(context)   ((context)->uc_mcontext.gregs[REG_ERR])
>  #define MASK_sig(context)((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP  0xe
>  #endif
>
>  int cpu_signal_handler(int host_signum, void *pinfo,
> @@ -302,7 +306,8 @@ int cpu_signal_handler(int host_signum, void *pinfo,
>  pc = EIP_sig(uc);
>  trapno = TRAP_sig(uc);
>  return handle_cpu_signal(pc, info,
> - trapno == 0xe ? (ERROR_sig(uc) >> 1) & 1 : 0,
> + trapno == PAGE_FAULT_TRAP ?
> + (ERROR_sig(uc) >> 1) & 1 : 0,
>   _sig(uc));
>  }
>
> @@ -313,11 +318,13 @@ int cpu_signal_handler(int host_signum, void *pinfo,
>  #define TRAP_sig(context)
>  ((context)->uc_mcontext.__gregs[_REG_TRAPNO])
>  #define ERROR_sig(context)((context)->uc_mcontext.__gregs[_REG_ERR])
>  #define MASK_sig(context) ((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP   T_PAGEFLT
>  #elif defined(__OpenBSD__)
>  #define PC_sig(context)   ((context)->sc_rip)
>  #define TRAP_sig(context) ((context)->sc_trapno)
>  #define ERROR_sig(context)((context)->sc_err)
>  #define MASK_sig(context) ((context)->sc_mask)
> +#define PAGE_FAULT_TRAP   T_PAGEFLT
>  #elif defined(__FreeBSD__) || defined(__DragonFly__)
>  #include 
>
> @@ -325,11 +332,13 @@ int cpu_signal_handler(int host_signum, void *pinfo,
>  #define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno)
>  #define ERROR_sig(context)((context)->uc_mcontext.mc_err)
>  #define MASK_sig(context) ((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP   T_PAGEFLT
>  #else
>  #define PC_sig(context)   ((context)->uc_mcontext.gregs[REG_RIP])
>  #define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
>  #define ERROR_sig(context)((context)->uc_mcontext.gregs[REG_ERR])
>  #define MASK_sig(context) ((context)->uc_sigmask)
> +#define PAGE_FAULT_TRAP   0xe
>  #endif
>
>  int cpu_signal_handler(int host_signum, void *pinfo,
> @@ -347,7 +356,8 @@ int cpu_signal_handler(int host_signum, void *pinfo,
>
>  pc = PC_sig(uc);
>  return handle_cpu_signal(pc, info,
> - TRAP_sig(uc) == 0xe ? (ERROR_sig(uc) >> 1) &
> 1 : 0,
> + TRAP_sig(uc) == PAGE_FAULT_TRAP ?
> + (ERROR_sig(uc) >> 1) & 1 : 0,
>   _sig(uc));
>  }
>
> --
> 2.22.1
>
>

[Bug 1882241] Re: file transfer over cifs to 64bit guest corrupts large files

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1882241

Title:
  file transfer over cifs to 64bit guest corrupts large files

Status in QEMU:
  Incomplete

Bug description:
  qemu 4.0 compiled fom source.
  vm called by
  qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive 
file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom 
/mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net 
nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k 
en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay

  copying large files eg 2.4gb or reading them on a cifs mount in the guest 
causes corruption every time. For smaller files 40-60mb corruption is more than 
50% of the time. tested by md5sum on cifs server, or on host machine vs. on 
guest vm.
  corruption is seen only with 64bit guest using cifs with i82551 emulated 
network device
  ie. 32bit guest using cifs with i82551 emulated network device gives no 
corruption.

  changing the emulated device to vmxnet3 removes the data corruption
  (see below)

  qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive
  file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom
  /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net
  nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0
  -enable-kvm -k en-gb -display vnc=:3 -monitor
  telnet:localhost:7103,server,nowait,nodelay

  this corruption is repeatable. ie. I created new vm, call using top example, 
installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then 
run md5sum "filecopied"
  the md5sum is different every time. copy same file to the host, or to a 32bit 
guest with the same virtual network device and bridge and md5sums are correct. 
The host pysical network adapter is
  lspci|grep Ether
  1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)

  physically connected via gigabit ethernet to cifs server (via gigabit
  switch)

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

[Bug 1881506] Re: TCG doesn't support a lot of features that should be supported

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.

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

Title:
TCG doesn't support a lot of features that should be supported

Status in QEMU:
Incomplete

Bug description:
This is quite odd, and I'm not sure about how to get around it. I'm writing
an OS in Rust and require APIC support. When I boot my kernel with
qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that
TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT,
misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr,
ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times
before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit
hash), as follows:
qemu-system-x86_64 -drive
format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial
stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu
EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic
-smp cpus=8 -soundhw all
I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to
my knowledge, automatically support RDRAND (and I don't know how to enable it).

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

[Bug 1881729] Re: target_read_memory in disas.c ignores possible errors

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system (but you won't be the reporter of the bug
in the new system and thus 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/1881729

Title:
  target_read_memory in disas.c ignores possible errors

Status in QEMU:
  Incomplete

Bug description:
  `target_read_memory` in `disas.c` ignores (possible) errors. This
  leads to disassembler possibly disassembling garbage.

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

[Bug 1880763] Re: Missing page crossing check in use_goto_tb() for rx target

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  Missing page crossing check in use_goto_tb() for rx target

Status in QEMU:
  Incomplete

Bug description:
  Currently the rx target doesn't have the page crossing check in its 
  use_goto_tb() function. 
  This is a required feature for stable system mode emulations that all 
  other targets implement.

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

[Bug 1880722] Re: Problems related to checking page crossing in use_goto_tb()

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  Problems related to checking page crossing in use_goto_tb()

Status in QEMU:
  Incomplete

Bug description:
  The discussion that led to this bug discovery can be found in this
  mailing list thread:
  https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html

  A workaround for this problem would be to check for page crossings for
  both the user and system modes in the use_goto_tb() function across
  targets. Some targets like "hppa" already implement this fix but others
  don't.

  To solve the root cause of this problem, the linux-user/mmap.c should
  be fixed to do all the invalidations required. By doing so, better
  performance results could be achieved, compared to the case of the
  workaround described above.

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

[Bug 1879590] Re: Using qemu-system-sparc64 no network interface seems to exist

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  Using qemu-system-sparc64 no network interface seems to exist

Status in QEMU:
  Incomplete

Bug description:
  Using boot command:

  qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/
  -nographic -m 256 -drive
  if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2

  After I log into solaris system I see no network devices other than the 
loopback device.
  All the docs I can see suggest it should come up with a default network 
device that allows communication via the hosts network. Host is ubuntu 64bit.  

  root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version
  QEMU emulator version 5.0.0
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

  
  dladm show-link
  ifconfig -a


  ok boot
  Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
  FCode UFS Reader 1.12 00/07/17 15:48:16.
  Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
  Loading: /platform/sun4v/ufsboot
  SunOS Release 5.10 Version Generic_118822-23 64-bit
  Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
  Use is subject to license terms.
  Hostname: unknown

  unknown console login: root
  Last login: Wed Feb  8 09:01:28 on console
  Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
  # dladm show-link
  # ifconfig -a
  lo0: flags=2001000849 mtu 8232 
index 1
  inet 127.0.0.1 netmask ff00

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

[Bug 1880066] Re: Microphone input dies in guest when switching evdev input

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  Microphone input dies in guest when switching evdev input

Status in QEMU:
  Incomplete
Status in qemu package in Fedora:
  New

Bug description:
  justin@justin-3900x:~$ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 20.04 LTS
  Release:  20.04
  Codename: focal


  justin@justin-3900x:~$ apt list --installed | egrep '*qemu*|*kvm*'

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  ipxe-qemu-256k-compat-efi-roms/focal,focal,now 
1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic]
  ipxe-qemu/focal,focal,now 1.0.0+git-20190109.133f4c4-0ubuntu3 all 
[installed,automatic]
  libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu8 amd64 
[installed,automatic]
  qemu-block-extra/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 
[installed,automatic]
  qemu-kvm/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed]
  qemu-system-common/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 
[installed,automatic]
  
qemu-system-data/focal-updates,focal-updates,focal-security,focal-security,now 
1:4.2-3ubuntu6.1 all [installed,automatic]
  qemu-system-gui/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 
[installed,automatic]
  qemu-system-x86/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 
[installed]
  qemu-utils/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 
[installed,automatic]
  qemu/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed]
  justin@justin-3900x:~$ 

  This did not happen in Eoan (qemu 4.0.0). I was able to switch in/out
  of a VM with my audio coming through fine. I enabled Eoan in my
  sources.list, downgraded all my qemu packages, and the issue was
  resolved.

  This happens on the latest Windows 10 guest when a sound device is
  listening for the microphone.

  /var/log/libvirt/qemu/.log spews this error out when I switch
  with evdev (which is just the keyboard and mouse, the audio is passed
  through I assume spice):

  
  audio: live=228193 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=228675 sw->hw->conv_buf->size=1920
  A bug was just triggered in audio_pcm_hw_get_live_in
  Context:
  audio: live=228675 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=229156 sw->hw->conv_buf->size=1920
  A bug was just triggered in audio_pcm_hw_get_live_in
  Context:
  audio: live=229156 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=229638 sw->hw->conv_buf->size=1920
  A bug was just triggered in audio_pcm_hw_get_live_in
  Context:
  audio: live=229638 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=230119 sw->hw->conv_buf->size=1920
  A bug was just triggered in audio_pcm_hw_get_live_in
  Context:
  audio: live=230119 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=230600 sw->hw->conv_buf->size=1920
  A bug was just triggered in audio_pcm_hw_get_live_in
  Context:
  audio: live=230600 hw->conv_buf->size=1920
  A bug was just triggered in audio_get_avail
  Context:
  audio: live=231081 sw->hw->conv_buf->size=1920

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

[Bug 1883593] Re: Windows XP takes much longer to boot in TCG mode since 5.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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  Windows XP takes much longer to boot in TCG mode since 5.0

Status in QEMU:
  Incomplete

Bug description:
  Since upgrading from 4.2 to 5.0, a Windows XP VM takes much longer to
  boot.

  It hangs about three minutes on "welcome" screen with the blue
  background, while previously the total boot time was less than a
  minute.

  The issue only happens in TCG mode (not with KVM) and also happens
  with the current master which includes the uring patches (7d3660e7).

  I can reproduce this issue with a clean XP install with no flags other
  than `-m 2G`. After booting, the performance seems to be normal.

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

[Bug 1882350] Re: it always create sdx device when I configure ide device with hdx name

Which kernel / linux distro are you using in the guest? Can you spot
something related in the output of "dmesg" 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/1882350

Title:
  it always create sdx device when I configure ide device with hdx name

Status in QEMU:
  Incomplete

Bug description:
  I have configured 2 ide disks with name starting with hd, but when the
  vm boots up, it shows disks whose name starting with sd.

  1. ide disks in vm xml:

  



  
  



  

  
  2. in VM:

  sda8:002G  0 disk
  sdb8:16   01G  0 disk

  
  3. from vm.log:

  le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-
  hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive
  file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device
  ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t

  
  4. rpm info: (I got the same issue on 2 diff envs)
  (1) env1
  qemu-kvm-1.5.3-105
  libvirt-3.2.0-14.el7
  (2) env2
  libvirt-5.9.0-1.el8
  qemu-4.1.0-1.el8

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

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

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 older bugs 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" within the next 60 days (otherwise it will get
closed as "Expired"). We will then eventually migrate the ticket auto-
matically to the new system.

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

Title:
  --static build fails in v5.0 (since
  5010cec2bc87dafab39b3913c8ca91f88df9c540)

Status in QEMU:
  Incomplete

Bug description:
  Hi,

  Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu
  fails when configured with --static (eg ../configure --target-
  list=x86_64-softmmu,x86_64-linux-user --enable-debug --static).

  On ubuntu 16.04, it fails to find -lffi and -lselinux.

  After I apt-get install libffi-dev libselinux1-dev, the build still fails:
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_pre_save':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:29: undefined 
reference to `_TRACE_DBUS_VMSTATE_PRE_SAVE_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_post_load':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:52: undefined 
reference to `_TRACE_DBUS_VMSTATE_POST_LOAD_DSTATE'
  ../backends/dbus-vmstate.o: In function 
`_nocheck__trace_dbus_vmstate_loading':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:75: undefined 
reference to `_TRACE_DBUS_VMSTATE_LOADING_DSTATE'
  ../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_saving':
  /home/christophe.lyon/src/qemu/build-static/backends/trace.h:98: undefined 
reference to `_TRACE_DBUS_VMSTATE_SAVING_DSTATE'
  collect2: error: ld returned 1 exit status

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

Re: [PATCH v6] i386/cpu_dump: support AVX512 ZMM regs dump

2021-05-06 Thread Eduardo Habkost

On Wed, Apr 21, 2021 at 02:23:52PM +0800, Robert Hoo wrote:
> Since commit fa4518741e (target-i386: Rename struct XMMReg to ZMMReg),
> CPUX86State.xmm_regs[] has already been extended to 512bit to support
> AVX512.
> Also, other qemu level supports for AVX512 registers are there for
> years.
> But in x86_cpu_dump_state(), still only dump XMM registers no matter
> YMM/ZMM is enabled.
> This patch is to complement this, let it dump XMM/YMM/ZMM accordingly.
> 
> Signed-off-by: Robert Hoo 
> Reviewed-by: Richard Henderson 

Queued, thanks!

-- 
Eduardo

[Bug 1877781] Re: TCG does not support x2APIC emulation