Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd.

[Jason Wang]

在 2021/6/22 上午11:29, Yuri Benditovich 写道:

On Mon, Jun 21, 2021 at 12:20 PM Jason Wang  wrote:


在 2021/6/19 上午4:03, Andrew Melnichenko 写道:

Hi Jason,
I've checked "kernel.unprivileged_bpf_disabled=0" on Fedora,  Ubuntu,
and Debian - no need permissions to update BPF maps.


How about RHEL :) ?

If I'm not mistaken, the RHEL releases do not use modern kernels yet
(for BPF we need 5.8+).
So this will be (probably) relevant for RHEL 9. Please correct me if I'm wrong.



Adding Toke for more ideas on this.

Thanks






Thanks



On Wed, Jun 16, 2021 at 1:18 AM Andrew Melnichenko mailto:and...@daynix.com>> wrote:

 Hi,

 I may miss something.

 But RSS requires to update the map. This won't work if you
 don't grant
 any permission to qemu.

 Thanks


 Partly - with "kernel.unprivileged_bpf_disabled=0" capabilities is
 not required to update maps.
 With "kernel.unprivileged_bpf_disabled=1" - setting maps will
 fail(without CAP_BPF) and "in-qemu" RSS will be used.

 On Tue, Jun 15, 2021 at 12:13 PM Jason Wang mailto:jasow...@redhat.com>> wrote:


 在 2021/6/12 上午12:49, Andrew Melnichenko 写道:
 > Hi,
 >
 > So I think the series is for unprivileged_bpf disabled.
 If I'm not
 > wrong, I guess the policy is to grant CAP_BPF but do
 fine grain
 > checks
 > via LSM.
 >
 >
 > The main idea is to run eBPF RSS with qemu without any
 permission.
 > Libvirt should handle everything and pass proper eBPF file
 descriptors.
 > For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations)
 > also required, and in the future may be other permissions.


 I may miss something.

 But RSS requires to update the map. This won't work if you
 don't grant
 any permission to qemu.

 Thanks


 >
 > I'm not sure this is the best. We have several examples
 that let
 > libvirt
 > to involve. Examples:
 >
 > 1) create TAP device (and the TUN_SETIFF)
 >
 > 2) open vhost devices
 >
 >
 > Technically TAP/vhost not related to a particular qemu
 emulator. So common
 > TAP creation should fit any modern qemu. eBPF fds(program
 and maps) should
 > suit the interface for current qemu, g.e. some qemu builds
 may have
 > different map
 > structures or their count. It's necessary that the qemu got fds
 > prepared by the helper
 > that was built with the qemu.
 >
 > I think we need an example on the detail steps for how
 libvirt is
 > expected to use this.
 >
 >
 > The simplified workflow looks like this:
 >
 >  1. Libvirt got "emulator" from domain document.
 >  2. Libvirt queries for qemu capabilities.
 >  3. One of the capabilities is "qemu-ebpf-rss-helper"
 path(if present).
 >  4. On NIC preparation Libvirt checks for virtio-net + rss
 configurations.
 >  5. If required, the "qemu-ebpf-rss-helper" called and fds are
 > received through unix fd.
 >  6. Those fds are for eBPF RSS, which passed to child
 process - qemu.
 >  7. Qemu launched with virtio-net-pci property "rss" and
 "ebpf_rss_fds".
 >
 >
 > On Fri, Jun 11, 2021 at 8:36 AM Jason Wang
 mailto:jasow...@redhat.com>
 > >>
 wrote:
 >
 >
 > 在 2021/6/10 下午2:55, Yuri Benditovich 写道:
 > > On Thu, Jun 10, 2021 at 9:41 AM Jason
 Wangmailto:jasow...@redhat.com>
 > >> wrote:
 > >> 在 2021/6/9 下午6:04, Andrew Melnychenko 写道:
 > >>> Libvirt usually launches qemu with strict permissions.
 > >>> To enable eBPF RSS steering, qemu-ebpf-rss-helper
 was added.
 > >> A silly question:
 > >>
 > >> Kernel had the following permission checks in bpf
 syscall:
 > >>
 > >>  if (sysctl_unprivileged_bpf_disabled &&
 !bpf_capable())
 > >>   return -EPERM;
 > >> ...
 > >>
 > >>   err = security_bpf(cmd, , size);
 > >>   if (err < 0)
 > >>   return err;
 > >>
 > >> So if I understand the code correctly, bpf syscall
 can only be
 > done if:
 > >>
 > >> 1) unprivileged_bpf is enabled or
 > >> 2) has the capability  and pass the LSM checks
 > >>
 > 

[Bug 1396497] Re: 'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot

[Launchpad Bug Tracker]

[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  'qemu-img snapshot' allows new snapshot to be created with the name of
  an existing snapshot

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  qemu-img _may_ be working as designed, but it feels like this could be
  a bug. I'd certainly prefer to only allow unique snapshot names
  (unless maybe something like a "--force-non-unique-snapshot-names" was
  also specified).

  If this really is correct behaviour, it should be documented as qemu-
  img(1) currently specifies no details whatsoever regarding expected
  behaviour or valid snapshot names.

  $ qemu-img snapshot -l image.cow 
  $ qemu-img snapshot -c foo image.cow
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  $ qemu-img snapshot -c foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  $ qemu-img snapshot -c foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow 
  $ qemu-img snapshot -l image.cow 
  $

  Note also how snapshot deletion works in reverse order - the oldest
  snapshot with a given name is deleted first.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: qemu-utils 2.1+dfsg-4ubuntu9
  ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
  Uname: Linux 3.16.0-25-generic x86_64
  ApportVersion: 2.14.7-0ubuntu10
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Nov 26 08:28:16 2014
  InstallationDate: Installed on 2014-04-11 (228 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409)
  KvmCmdLine:
   COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
   kvm-irqfd-clean S<   0 0   719 2  0.0 [kvm-irqfd-clean]
  MachineType: LENOVO 20AQCTO1WW
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  SourcePackage: qemu
  UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago)
  dmi.bios.date: 02/10/2014
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GJET71WW (2.21 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20AQCTO1WW
  dmi.board.vendor: LENOVO
  dmi.board.version: 0B98405 STD
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 20AQCTO1WW
  dmi.product.version: ThinkPad T440s
  dmi.sys.vendor: LENOVO

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

[Bug 1388735] Re: QEMU no longer allows to use full TCP port range for VNC

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  QEMU no longer allows to use full TCP port range for VNC

Status in QEMU:
  Expired

Bug description:
  After upgrade to QEMU version 2.1.0 (Debian 2.1+dfsg-4ubuntu6), I am no 
longer able to use any TCP port for VNC display.
  For example, if I need to assign VNC server a TCP port 443, I used to run:
  # qemu-system-x86_64 -vnc :-5457
  qemu-system-x86_64: Failed to start VNC server on `:-1000': can't convert to 
a number:-5457
  expected behavior: as any VNC software, take port base of 5900, substract 
5457 display number, and use TCP port 443

  I ask to change vnc port conversion routine to allow input values in
  range of all TCP ports, from 1 to 65535.

  I really depend on ability to use full TCP range for VNC port numbers,
  and inablity to do so in new version of QEMU is very disappointing.

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

[Bug 1136477] Re: qemu doesn't sanitize command line options carrying plaintext passwords

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu doesn't sanitize command line options carrying plaintext
  passwords

Status in QEMU:
  Expired

Bug description:
  A slight security problem exists with qemu's lack of sanitization of
  argv[], for cases where the user may have specified a plaintext
  password for spice/vnc authorization.  (Yes, it's not great to use
  this facility, but it's convenient and not grotesquely unsafe, were it
  not for this bug.)  It would be nice if those plaintext passwords were
  nuked from the command line, so a subsequent "ps awux" didn't show
  them for all to see.

  See also https://bugzilla.redhat.com/show_bug.cgi?id=916279

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

[Bug 612452] Re: Problems with the number of serial ports for more than two

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Problems with the number of serial ports for more than two

Status in QEMU:
  Expired

Bug description:
  qemu --version
  QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard

  Command line:

  qemu -serial null -serial null -serial file:test1 hd.img

  Error:

  isa irq 4 already assigned

  echo $?
  1

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

[Bug 1451067] Re: -smb option requires full path for Samba sharing to work

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  -smb option requires full path for Samba sharing to work

Status in QEMU:
  Expired

Bug description:
  This issue has been reported on qemu-devel a looong time ago:
  https://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00141.html

  QEMU version 2.2.1-4 on Arch Linux x86_64

  Steps to reproduce:

  host$ mkdir share
  host$ chmod o+rwx share
  host$ qemu  -smb share

  vm$ smbclient //10.0.2.4/qemu -N
  smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
  Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1]
  tree connect failed: NT_STATUS_BAD_NETWORK_NAME
  vm$ poweroff

  Workaround:

  host$ qemu  -smb /full/path/to/share

  vm$ $ smbclient //10.0.2.4/qemu -N
  smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
  Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1]
  smb: \> ls
.   D0  Sat May  2 19:57:31 2015
..  D0  Sat May  2 19:57:31 2015

961302540 blocks of size 1024. 637557248 blocks available
  smb: \> quit

  Please, please fix this gotcha, whether in the documentation or in
  code. it can cause some serious bouts of hair-pulling.

  -Alain

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

[Bug 1396497] Re: 'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  'qemu-img snapshot' allows new snapshot to be created with the name of
  an existing snapshot

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  qemu-img _may_ be working as designed, but it feels like this could be
  a bug. I'd certainly prefer to only allow unique snapshot names
  (unless maybe something like a "--force-non-unique-snapshot-names" was
  also specified).

  If this really is correct behaviour, it should be documented as qemu-
  img(1) currently specifies no details whatsoever regarding expected
  behaviour or valid snapshot names.

  $ qemu-img snapshot -l image.cow 
  $ qemu-img snapshot -c foo image.cow
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  $ qemu-img snapshot -c foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  $ qemu-img snapshot -c foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  1 foo   0 2014-11-26 08:30:53   00:00:00.000
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  2 foo   0 2014-11-26 08:30:58   00:00:00.000
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow 
  $ qemu-img snapshot -l image.cow
  Snapshot list:
  IDTAG VM SIZEDATE   VM CLOCK
  3 foo   0 2014-11-26 08:31:00   00:00:00.000
  $ qemu-img snapshot -d foo image.cow 
  $ qemu-img snapshot -l image.cow 
  $

  Note also how snapshot deletion works in reverse order - the oldest
  snapshot with a given name is deleted first.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: qemu-utils 2.1+dfsg-4ubuntu9
  ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
  Uname: Linux 3.16.0-25-generic x86_64
  ApportVersion: 2.14.7-0ubuntu10
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Nov 26 08:28:16 2014
  InstallationDate: Installed on 2014-04-11 (228 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409)
  KvmCmdLine:
   COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
   kvm-irqfd-clean S<   0 0   719 2  0.0 [kvm-irqfd-clean]
  MachineType: LENOVO 20AQCTO1WW
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  SourcePackage: qemu
  UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago)
  dmi.bios.date: 02/10/2014
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GJET71WW (2.21 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20AQCTO1WW
  dmi.board.vendor: LENOVO
  dmi.board.version: 0B98405 STD
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 20AQCTO1WW
  dmi.product.version: ThinkPad T440s
  dmi.sys.vendor: LENOVO

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

[Bug 1191326] Re: QNX 4 doesn't boot on qemu >= 1.3

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  QNX 4 doesn't boot on qemu >= 1.3

Status in QEMU:
  Expired

Bug description:
  I am using virtual machine with QNX4 operating system installed on it.  I 
updated my qemu from version
  to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I 
try to use any newer version
  (1.3, 1.4, 1.5)  QNX4 doesn't boot.  I tried on windows and linux ubuntu 
hosts - effects are the same.

  When virtual machine boots qnx bootloader loads and starts operating system. 
In the next step
  qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem 
starts when operating system
  tries mount partition - an error occur and qnx stop booting procedure:

  mount -p "No bios signature in partition sector on /dev/hd0"

  I have tried install qnx from cdrom but it seems that there is the same 
problem. QNX installer boot from
  cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next 
step of installation procedure.

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

[Bug 1527765] Re: sh4: ghc randomly segfaults on qemu-sh4-static

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  sh4: ghc randomly segfaults on qemu-sh4-static

Status in QEMU:
  Expired

Bug description:
  Hello!

  I am currently in the process of bootstrapping ghc for the Debian sh4
  port and ran into a strange problem with qemu-sh4-static which
  randomly segfaults when running ghc to compile a Haskell source:

  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls
  Main.hi  Main.hs  Setup.hs  ghc-pwd.cabal  ghc.mk
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  [1 of 1] Compiling Main ( Main.hs, Main.o )
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  [1 of 1] Compiling Main ( Main.hs, Main.o )
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  [1 of 1] Compiling Main ( Main.hs, Main.o )
  Bad interface file: 
/usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi
  ghc: panic! (the 'impossible' happened)
    (GHC version 7.10.3 for sh4-unknown-linux):
   getSymtabName:unknown known-key unique
  <>

  Please report this as a GHC bug:
  http://www.haskell.org/ghc/reportabug

  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  [1 of 1] Compiling Main ( Main.hs, Main.o )
  Linking Main ...
  root@jessie32:~/ghc-7.8.4/utils/ghc-pwd#

  As seen above, compiling a Haskell source code often results in a
  segfault but simply by retrying to run ghc over and over again, the
  compile process will eventually succeed and no segfault occurs.

  I have created a tarball which contains the sh4 chroot from the
  example above which also includes ghc, gcc and the source code in
  question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a
  good idea to replace the qemu-sh4-static binary in /usr/bin with a
  current git snapshot (which I tried but didn't help).

  > http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz

  In case anyone wants to try ghc with their own sh4 chroot, here's my
  version of ghc:

  > https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-
  ghc-7.10.3.tar.gz

  Just extract this tarball into the root directory of the sh4 chroot.

  Please note, that it might be advisable on sh4 to apply the patches
  from these two bug reports as otherwise qemu-sh4-static won't work
  properly on amd64 and misses syscall 186:

  > https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824
  > https://bugs.launchpad.net/qemu/+bug/1516408

  The above issue is reproducible with the two patches applied and
  without. It's also reproducible with both libc6 2.19 and 2.21 in the
  chroot. Thus, I am currently out of ideas what else to test.

  Cheers,
  Adrian

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

[Bug 1453612] Re: set_password command of monitor has poor feedback on failure

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  set_password command of monitor has poor feedback on failure

Status in QEMU:
  Expired

Bug description:
  running `set_password vnc NkkmEz5icvTAGo6MECzBVEUxP` in qemu monitor
  (which is the appropriate way to set a vnc password according to `man
  qemu-system-x86_64`) started with `-monitor stdio` gives feedback
  `Could not set password` which is unhelpful because it doesn't specify
  the reason of the failure.

  experienced with 2.3.0

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

[Bug 1600563] Re: min_io_size is currently limited to size uint16_t

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  min_io_size is currently limited to size uint16_t

Status in QEMU:
  Expired

Bug description:
  I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the
  host, a VG looks like this:

  Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 4096 bytes
  I/O size (minimum/optimal): 131072 bytes / 131072 bytes

  In order to replicate the block device characteristics in the guest, I
  am using the following extra parameters:

  -set device.scsi0-0-0-0.logical_block_size=512
  -set device.scsi0-0-0-0.physical_block_size=4096
  -set device.scsi0-0-0-0.min_io_size=131072

  This doesn't work as qemu complains that min_io_size needs to be of
  type uint16_t.

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

[Bug 1568621] Re: input-linux misdetects Logitech keyboard as a mouse

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  input-linux misdetects Logitech keyboard as a mouse

Status in QEMU:
  Expired

Bug description:
  The new input-linux.c code misdetects my Logitech K350 keyboard as a
  mouse.  The bug is in the input_linux_complete function.  The evdev
  for this keyboard returns an "evtmap" with the EV_REL bit set.  Full
  evtmap is 0x0012001F.  Using a different keyboard everything works as
  intended, so my configuration and setup are correct otherwise.

  
  Suggestion:

  I suggest adding an object property called something like "type" where
  the user can specify what the device type is manually.  This K350
  keyboard shows that "evtmap" cannot be used to reliably detect the
  device type.  Since specifying the device type manually is not an
  undue burden, perhaps it should be a required option and there should
  be no autodetection?

  
  System:

  Arch linux, using qemu-git AUR package installed 20160409.

  
  Command line:

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
  QEMU_AUDIO_DRV=none /usr/sbin/qemu-system-x86_64 -name win10,debug-
  threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu
  host,kvm=off -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-
  efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive
  file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1
  -m 8196 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid
  58623778-9d9d-4d30-8ec0-b37e12a30fdc -nographic -no-user-config
  -nodefaults -chardev
  
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-17-win10/monitor.sock,server,nowait
  -mon chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard
  -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global
  PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-
  ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-
  uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6
  -device ich9-usb-
  uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9
  -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive
  
file=/var/lib/libvirt/images/ISOs/Win10_1511_English_x64.iso,format=raw,if=none,id
  =drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive
  =drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/ISOs
  /virtio-win-0.1.112.iso,format=raw,if=none,id=drive-
  ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-
  ide0-1-0,id=ide0-1-0 -drive file=/dev/sda,format=raw,if=none,id=drive-
  virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive
  =drive-virtio-disk1,id=virtio-disk1,bootindex=1 -netdev
  tap,fd=26,id=hostnet0 -device
  rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:8a:db,bus=pci.0,addr=0x3
  -netdev tap,fd=28,id=hostnet1 -device
  rtl8139,netdev=hostnet1,id=net1,mac=d4:be:d9:56:2e:35,bus=pci.0,addr=0x9
  -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
  duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device vfio-
  pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-
  balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object input-
  linux,id=kbd1,evdev=/dev/input/event19,grab_all=on -object input-
  linux,id=kbb2,evdev=/dev/input/event2 -msg timestamp=on

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

[Bug 1574246] Re: Drunken keyboard in go32v2 programs

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Drunken keyboard in go32v2 programs

Status in QEMU:
  Expired

Bug description:
  QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a
  while, though.

  Steps to reproduce:

  # Create a VM image, install DOS in it (doesn't matter which) and launch it.
  # Launch a "bare DOS" DPMI host (not an operating system) in it; I tested 
with CWSDPMI and HDPMI32.
  # Run a go32v2 program which reads keyboard input (say, the Lua interpreter: 
;
 the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem 
unaffected).
  # Quickly type in something random (e.g. alternate between hitting "p" and 
"q"), then optionally move the cursor left and right.
  # Observe how some keystrokes are missed, and some are caught twice.

  The issue does NOT arise:
  * on bare metal DOS,
  * in VirtualBox,
  * in Bochs with stock Plex86 BIOS,
  * in Bochs with SeaBIOS,
  * in DOSEMU,
  * in DOSBox,
  * in QEMU when the DPMI host is Windows 3.11/9x
  so at this point I'm reasonably sure that it's the fault of either QEMU or 
SeaBIOS, and probably the former. The issue arises regardless of whether KVM is 
enabled.

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

[Bug 1624896] Re: [PPC] SegFault due to Stack Overflow in E500

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  [PPC] SegFault due to Stack Overflow in E500

Status in QEMU:
  Expired

Bug description:
  
  I am getting a Segmentation Fault while simulating a PowerPC e500. I've tried 
to debug the problem and I've found that it occurs when you have a 0 value 
decrementer. The function trace is the following:

  1) __cpu_ppc_store_decr (ppc.c) is called with value = 0 and 
raise_excp=booke_decr_cb;
  2) Since value < 3, booke_decr_cb is called;
  3) booke_decr_cb then calls booke_update_irq() and cpu_ppc_store_decr();
  4) cpu_ppc_store_decr calls __cpu_ppc_store_decr

  You're stuck on this infinite cycle until your stack overflows
  eventually.

  Command Line:
  qemu-system-ppc -cpu e500v2 -d guest_errors,unimp -m 2048 -M ppce500 
-nographic -bios ../cc/share/qem
  u/u-boot.e500 -kernel XKYAPP.exe

  Platform where the bug occured: Bash ubuntu on Windows;

  Revision where the bug was found:
  e3571ae30cd26d19efd4554c25e32ef64d6a36b3 (16 Set 2016)


  Thanks!

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

[Bug 1587211] Re: qemu-system-i386/x86_64 crash with 1 MB guest RAM

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-system-i386/x86_64 crash with 1 MB guest RAM

Status in QEMU:
  Expired

Bug description:
  When launching qemu-system-i386 or qemu-system-x86_64 with 1 MB of RAM
  allocated to the guest (-m 1) and no guest image specified, QEMU will
  crash while trying to "execute code outside of RAM or ROM" after
  approximately 10 minutes. I discovered this while using QEMU 2.5.0,
  but I verified that it also occurs with 2.5.1.1 and the latest source
  available in git (2.6.50, commit
  d6550e9ed2e1a60d889dfb721de00d9a4e3bafbe). I built all of these
  different versions of QEMU on the same 64-bit Ubuntu 14.04.3 host
  using the distro's default GCC 4.8.4.

  Two observations:

  1. This only occurs when allocating 1 MB of RAM to the guest. When I
  allocate 2 MB, this does not happen. I tried running both i386/x86_64
  QEMUs for hours with 2 MB and didn't observe this crash.

  2. This may be a SeaBIOS bug, as there is no guest code to execute.
  After enabling the SeaBIOS debug at the ISA 0x402 port and redirecting
  it to stdio, the last SeaBIOS state transition reported ("Booting from
  ROM... Booting from c980:0361") occurs immediately at QEMU startup
  with no further logging messages seen prior to the crash ten minutes
  later. My captured SeaBIOS debug output is here:
  http://pastebin.com/GXm2L44E

  To reproduce, use the following command lines:

  ./i386-softmmu/qemu-system-i386 -display none -m 1 -monitor stdio
  ./x86_64-softmmu/qemu-system-x86_64 -display none -m 1 -monitor stdio

  For both 32/64-bit QEMUs, the output is the same. After running for
  about 10 minutes (I've seen it take between 7m 15s (v2.5.1.1) to 10m
  25s (v2.6.50) of runtime to occur by using the "time" command), the
  following output is shown:

  --- OUTPUT BEGINS ---
  e1000: Reading register at offset: 0x2410. It is not fully implemented.
  e1000: Reading register at offset: 0x2410. It is not fully implemented.
  e1000: Reading register at offset: 0x2410. It is not fully implemented.
  e1000: Reading register at offset: 0x2410. It is not fully implemented.
  e1000: Reading register at offset: 0x2418. It is not fully implemented.
  e1000: Reading register at offset: 0x2418. It is not fully implemented.
  e1000: Reading register at offset: 0x2418. It is not fully implemented.
  e1000: Reading register at offset: 0x2418. It is not fully implemented.
  e1000: Reading register at offset: 0x2420. It is not fully implemented.
  e1000: Reading register at offset: 0x2420. It is not fully implemented.
  e1000: Reading register at offset: 0x2420. It is not fully implemented.
  e1000: Reading register at offset: 0x2420. It is not fully implemented.
  e1000: Reading register at offset: 0x2428. It is not fully implemented.
  e1000: Reading register at offset: 0x2428. It is not fully implemented.
  e1000: Reading register at offset: 0x2428. It is not fully implemented.
  e1000: Reading register at offset: 0x2428. It is not fully implemented.
  e1000: Reading register at offset: 0x2430. It is not fully implemented.
  e1000: Reading register at offset: 0x2430. It is not fully implemented.
  e1000: Reading register at offset: 0x2430. It is not fully implemented.
  e1000: Reading register at offset: 0x2430. It is not fully implemented.
  e1000: Reading register at offset: 0x3410. It is not fully implemented.
  e1000: Reading register at offset: 0x3410. It is not fully implemented.
  e1000: Reading register at offset: 0x3410. It is not fully implemented.
  e1000: Reading register at offset: 0x3410. It is not fully implemented.
  e1000: Reading register at offset: 0x3418. It is not fully implemented.
  e1000: Reading register at offset: 0x3418. It is not fully implemented.
  e1000: Reading register at offset: 0x3418. It is not fully implemented.
  e1000: Reading register at offset: 0x3418. It is not fully implemented.
  e1000: Reading register at offset: 0x3420. It is not fully implemented.
  e1000: Reading register at offset: 0x3420. It is not fully implemented.
  e1000: Reading register at offset: 0x3420. It is not fully implemented.
  e1000: Reading register at offset: 0x3420. It is not fully implemented.
  e1000: Reading register at offset: 0x3428. It is not fully implemented.
  e1000: Reading register at offset: 0x3428. It is not fully implemented.
  e1000: Reading register at offset: 0x3428. It is not fully implemented.
  e1000: Reading register at offset: 0x3428. It is not fully implemented.
  e1000: Reading register at offset: 0x3430. It is not fully implemented.
  e1000: Reading register at offset: 

[Bug 1556372] Re: Superfluous popup on Cocoa to verify quit, cannot be disabled.

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Superfluous popup on Cocoa to verify quit, cannot be disabled.

Status in QEMU:
  Expired

Bug description:
  This patch severely reduces the quality of life for developers using QEMU in 
a rapid Edit-Compile-Test cycle.
  Any method of quitting QEMU via the UI triggers this dialogue, whose default 
option is "cancel" -- necessitating the use of the mouse to click "Confirm".

  This dialogue cannot be disabled by any flag, and is highly annoying.
  Recommend a flag to disable this confirmation, or in fact disable it
  by default and enable it with a flag.

  Patch in question:

  https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html

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

[Bug 1703506] Re: SMT not supported by QEMU on AMD Ryzen CPU

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  SMT not supported by QEMU on AMD Ryzen CPU

Status in QEMU:
  Expired

Bug description:
  HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this
  message when setting the topology to threads=2:

  qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please
  configure -smp options properly.

  Checking in a Windows 10 guest reveals that SMT is not enabled, and
  from what I understand, QEMU converts the topology from threads to
  cores internally on AMD CPUs. This appears to cause performance
  problems in the guest perhaps because programs are assuming that these
  threads are actual cores.

  Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro
  guest

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

[Bug 1574346] Re: TCG: mov to segment register is incorrectly emulated for AMD CPUs

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  TCG: mov to segment register is incorrectly emulated for AMD CPUs

Status in QEMU:
  Expired

Bug description:
  In TCG mode, the effect of:

  xorl %eax, %eax
  movl %eax, %gs

  is to mark the GS segment unusable and set its base to zero.  After
  doing this, reading MSR_GS_BASE will return zero and using a GS prefix
  in long mode will treat the GS base as zero.

  This is correct for Intel CPUs but is incorrect for AMD CPUs.  On an
  AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave
  the base unchanged.

  To make it easier to use TCG to validate behavior on different CPUs,
  please consider changing the TCG behavior to match actual CPU behavior
  when emulating an AMD CPU.

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

[Bug 1596832] Re: e500 -bios/-kernel broken with big images

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  e500 -bios/-kernel broken with big images

Status in QEMU:
  Expired

Bug description:
  This is tested using qemu 2.4.1, but it looks like the code
  qemu/hw/ppc/e500.c has not changed since. This looks like the source
  of the problem:
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3812c71ffaa2cf733c3087792b859fef30b7545f

  
  What works:
  --

  Basic invocation qemu-system-ppc -machine ppce500  -monitor stdio
  -bios u-boot.e500 works, I get the uboot prompt and this:

  (qemu) info roms
  addr=00f0 size=0x044b8c mem=ram name="phdr #0: 
.../qemu/share/qemu/u-boot.e500"
  addr=00f81000 size=0x006b00 mem=ram name="phdr #1: 
.../qemu/share/qemu/u-boot.e500"

  
  Passing u-boot.e500 image as kernel (-bios u-boot.e500 -kernel u-boot.e500) 
appears to work, $qemu_kernel_addr is filled in, though (as expected) uboot 
complains about the image format.

  (qemu) info roms
  addr=00f0 size=0x044b8c mem=ram name="phdr #0: 
.../qemu/share/qemu/u-boot.e500"
  addr=00f81000 size=0x006b00 mem=ram name="phdr #1: 
.../qemu/share/qemu/u-boot.e500"
  addr=0200 size=0x054e8c mem=ram 
name=".../qemu/share/qemu/u-boot.e500


  What doesn't work:
  -

  However, once I try to load a big image (>=32 MiB), uboot doesn't even
  show anything:

  qemu-system-ppc -machine ppce500  -monitor stdio -bios u-boot.e500
  -kernel boot/vmlinux -m 1024

  (qemu) info roms
  addr=00f0 size=0x044b8c mem=ram name="phdr #0: 
.../qemu/share/qemu/u-boot.e500"
  addr=00f81000 size=0x006b00 mem=ram name="phdr #1: 
.../qemu/share/qemu/u-boot.e500"
  addr=0200 size=0x27aeedc mem=ram name="boot/vmlinux"

  ...
  (gdb) bt
  #0  0x00f2efcc in ?? ()
  #1  0x00f31554 in ?? ()
  #2  0x00f03f4c in ?? ()
  #3  0x00f04458 in ?? ()
  #4  0x00f028dc in ?? ()
  #5  0x00f01080 in ?? ()


  The thing is, this used to work +- before the commit, where I'd just
  pass the image as -kernel option, and it booted.

  
  If I do that now (w/o the -bios option, using the exact same image), the 
kernel gets loaded twice, only at different addresses (the cause is obvious 
from the commit), causing overlap error:

  qemu-system-ppc -machine ppce500  -monitor stdio  -kernel boot/vmlinux -m 1024
  QEMU 2.4.1 monitor - type 'help' for more information
  (qemu) rom: requested regions overlap (rom boot/vmlinux. 
free=0x027492fc, addr=0x0200)

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

[Bug 1737444] Re: gccgo setcontext conftest crashes qemu-sh4

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  gccgo setcontext conftest crashes qemu-sh4

Status in QEMU:
  Expired

Bug description:
  While testing gccgo on sh4 to add SH platform definitions to libgo, I
  discovered that the following conftest program which is part of the
  libgo configure script crashes on qemu-sh4:

  (sid-sh4-sbuild)root@z6:/# cat setcontext.c
  #include   


 
  #include


 
  #include  


 
  #include


 

  __thread int tls;

  static char stack[10 * 1024 * 1024];
  static ucontext_t c;

  /* Called via makecontext/setcontext.  */

  static void
  cfn (void)
  {
exit (tls);
  }

  /* Called via pthread_create.  */

  static void *
  tfn (void *dummy)
  {
/* The thread should still see this value after calling
   setcontext.  */
tls = 0;

setcontext ();

/* The call to setcontext should not return.  */
abort ();
  }

  int
  main ()
  {
pthread_t tid;

/* The thread should not see this value.  */
tls = 1;

if (getcontext () < 0)
  abort ();

c.uc_stack.ss_sp = stack;
  #ifdef MAKECONTEXT_STACK_TOP  


 
c.uc_stack.ss_sp += sizeof stack;
  #endif


 
c.uc_stack.ss_flags = 0;
c.uc_stack.ss_size = sizeof stack;
c.uc_link = NULL;
makecontext (, cfn, 0);

if (pthread_create (, NULL, tfn, NULL) != 0)
  abort ();

if (pthread_join (tid, NULL) != 0)
  abort ();

/* The thread should have called exit.  */
abort ();
  }

  (sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c
  (sid-sh4-sbuild)root@z6:/# ./setcontext 
  Unhandled trap: 0x180
  pc=0x7f69235e sr=0x pr=0x00400710 fpscr=0x0008
  spc=0x ssr=0x gbr=0x7f658478 vbr=0x
  sgr=0x dbr=0x delayed_pc=0x7f692320 fpul=0x
  r0=0x00e11158 r1=0x r2=0x0001 r3=0x72e0
  r4=0x00e11068 r5=0x7314 r6=0x731c r7=0x
  r8=0x004007b0 r9=0x r10=0x r11=0x
  r12=0x7f79ac54 r13=0x r14=0x7288 r15=0x7288
  r16=0x r17=0x r18=0x r19=0x
  r20=0x r21=0x r22=0x r23=0x
  (sid-sh4-sbuild)root@z6:/#

  The same code works fine on my Renesas SH7785LCR evaluation board:

  root@tirpitz:~> uname -a
  Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a 
GNU/Linux
  root@tirpitz:~> gcc -o setcontext setcontext.c  -lpthread
  root@tirpitz:~> ./setcontext 
  root@tirpitz:~> echo $?
  0
  root@tirpitz:~>

  Due to this bug, it is not possible to compile gcc-7 with the Go
  frontend enabled on qemu-sh4.

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

[Bug 1612908] Re: qom-[list, tree, get, set] don't accept tcp endpoint arg

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qom-[list,tree,get,set] don't accept tcp endpoint arg

Status in QEMU:
  Expired

Bug description:
  Hi,

  I'm using origin/master [60ac13...]. When I run any of the
  commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text
  says that it can connect to a QEMU instance by passing either a path
  to a unix socket or a tcp endpoint in the format "host:port". The unix
  socket variant works but the tcp endpoint variant does not.
  QEMUMonitorProtocol accepts either a string (unix socket) or a tuple
  (host,port). None of the qom-* scripts actually massage the '-s'
  argument into a tuple.

  I have a patch to fix this issue that I can submit to the developer
  list.

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

[Bug 1765970] Re: qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to
  2.11.x

Status in QEMU:
  Expired

Bug description:
  I use a qemu-user chroot + binfmt to build software targetting a
  raspberry pi.  After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo
  host), I noticed that on my uclibc-ng chroot qemu-arm will segfault
  when running python and importing the portage module.

  I have bisected qemu down to this commit:

  https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07

  If I recompile and change MAX_RESERVED_VA (from the above commit) back
  to 0x7700 the problem goes away.  NB I have no idea what that
  does, I just thought I'd see.

  
  Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the 
uclibc-ng one.  Not sure why.

  
  The following backtrace was generated from running qemu-arm in gdb and 
recreating the segfault:

  (gdb) where
  #0  0x60726046 in static_code_gen_buffer ()
  #1  0x60048789 in cpu_tb_exec (cpu=0x6278e310, 
  itb=0x60725f80 )
  at 
/usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167
  #2  0x6004937f in cpu_loop_exec_tb (cpu=0x6278e310, 
  tb=0x60725f80 , last_tb=0x7fffd138, 
  tb_exit=0x7fffd130)
  at 
/usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627
  #3  0x60049600 in cpu_exec (cpu=0x6278e310)
  at 
/usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736
  #4  0x600511c3 in cpu_loop (env=0x627965b0)
  at 
/usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585
  #5  0x600534eb in main (argc=4, argv=0x7fffd9b8, 
  envp=0x7fffd9e0)
  at 
/usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882


  (gdb) info reg
  rax0x627965b0   1652123056
  rbx0x62717870   1651603568
  rcx0x606da000   1617797120
  rdx0x60726000   1618108416
  rsi0x60726000   1618108416
  rdi0x627965b0   1652123056
  rbp0x7fffd0c0   0x7fffd0c0
  rsp0x7fffd080   0x7fffd080
  r8 0x0  0
  r9 0x2  2
  r100x0  0
  r110x629280a0   1653768352
  r120x60260e40   1613106752
  r130x0  0
  r140x606a5018   1617580056
  r150x0  0
  rip0x60048789   0x60048789 
  eflags 0x10282  [ SF IF RF ]
  cs 0x33 51
  ss 0x2b 43
  ds 0x0  0
  es 0x0  0
  fs 0x0  0
  gs 0x0  0
  (gdb)

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

[Bug 1600112] Re: Qemu GTK interface showing question marks instead of correct strings

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Qemu GTK interface showing question marks instead of correct strings

Status in QEMU:
  Expired

Bug description:
  Qemu version: 2.6.0

  When running Qemu system emulation (configured with GTK interface),
  all interface strings shows up as question marks instead of the
  correct translated strings. Tested on locale zh_CN.UTF-8.

  I have attached a screenshot below for better understanding.

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

[Bug 1828508] Re: qemu-img created VMDK files lead to "Unsupported or invalid disk type 7"

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-img created VMDK files lead to "Unsupported or invalid disk type
  7"

Status in QEMU:
  Expired

Bug description:
  Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a
  Windows 10 machine.

  Converting a VHD to VMDK.
  qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic 
-p "c:\test\AppD-VM01.vmdk"

  I have also tried:
  qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o 
adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"

  Attaching the VMDK to a VM in VMware produces the following error when
  powering on.

  Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid 
disk type 7. Ensure that the disk has been imported.
  Target: MyVM1
  vCenter Server: VCENTER
  Error Stack
  An error was received from the ESX host while powering on VM MyVM1.
  Failed to start the virtual machine.
  Module DevicePowerOn power on failed. 
  Unable to create virtual SCSI device for scsi0:1, 
'/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk'
 
  Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that 
the disk has been imported.

  
  If I do not specify the adapter type, it creates an IDE VMDK which works 
perfectly.

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

[Bug 1830031] Re: fatal error: float32nan on QEmu 3.1

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  fatal error: float32nan on QEmu 3.1

Status in QEMU:
  Expired

Bug description:
  Docker throws float32nan errors when running alpine container on a
  CentOS 7.6 ppc64le Distro VM, when using Fedora 30 Host qemu 3.1. I
  Compiled qemu 2.11.2 on the Fedora 30 and using this qemu-system-ppc64
  we don't see the error. Even using qemu 3.1 and machine 2.11 we still
  get the same issue.

  Nothing changed on the OS level on the two runs. just the qemu-system-
  ppc64 used to run the virtual machine.

   Docker on CentOS 7: docker.ppc64le 2:1.13.1-96

  Running with qemu 2.11.2 behavior and machine 2.11:
  [root@machine ~]# /usr/local/bin/qemu-system-ppc64 -version
  QEMU emulator version 2.11.2(qemu-2.11.2-5.fc30)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  [root@powericp ~]# docker run -i -t alpine /bin/sh
  / # exit
  [root@powericp ~]# uname -a
  Linux powericp 3.10.0-957.12.2.el7.ppc64le #1 SMP Tue May 14 22:24:22 UTC 
2019 ppc64le ppc64le ppc64le GNU/Linux
  [root@powericp ~]# docker version
  Client:
   Version: 1.13.1
   API version: 1.26
   Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.ppc64le
   Go version:  go1.10.3
   Git commit:  b2f74b2/1.13.1
   Built:   Wed May  1 15:05:41 2019
   OS/Arch: linux/ppc64le
  …
  [root@powericp ~]# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):16
  On-line CPU(s) list:   0-15
  Thread(s) per core:1
  Core(s) per socket:1
  Socket(s): 16
  NUMA node(s):  1
  Model: 2.0 (pvr 004e 1200)
  Model name:POWER8 (architected), altivec supported
  Hypervisor vendor: KVM
  Virtualization type:   para
  L1d cache: 32K
  L1i cache: 32K
  NUMA node0 CPU(s): 0-15
  
#
  #Running with qemu3.1
  
#
  [root@machine ~]# qemu-system-ppc64 -version
  QEMU emulator version 3.1.0 (qemu-3.1.0-8.fc30)
  Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
  [root@powericp ~]# docker run -i -t alpine /bin/sh
  /usr/bin/docker-current: Error response from daemon: oci runtime error: error 
running hook: exit status 4, stdout: , stderr: fatal error: float32nan
  runtime: panic before malloc heap initialized

  runtime stack:
  fatal error: gentraceback before goexitPC initialization
  runtime: panic before malloc heap initialized
  panic during panic

  runtime stack:
  fatal error: gentraceback before goexitPC initialization
  runtime: panic before malloc heap initialized
  stack trace unavailable.
  [root@powericp ~]# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):16
  On-line CPU(s) list:   0-15
  Thread(s) per core:1
  Core(s) per socket:1
  Socket(s): 16
  NUMA node(s):  1
  Model: 2.0 (pvr 004e 1200)
  Model name:POWER8 (architected), altivec supported
  Hypervisor vendor: KVM
  Virtualization type:   para
  L1d cache: 32K
  L1i cache: 32K
  NUMA node0 CPU(s): 0-15

  
  strace attached.

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

[Bug 1746394] Re: No provider of glEGLImageTargetTexture2DOES found with NVIDIA proprietary driver

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  No provider of glEGLImageTargetTexture2DOES found with NVIDIA
  proprietary driver

Status in QEMU:
  Expired

Bug description:
  https://github.com/anholt/libepoxy/issues/148

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

[Bug 1605611] Re: memsave returns invalid addr when trying to read a 64 bits address

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  memsave returns invalid addr when trying to read a 64 bits address

Status in QEMU:
  Expired

Bug description:
  I am trying to read the first 16 bytes of the System Process on a
  Windows XP x64 SP2 using the memsave monitor command.

  I cloned the latest release of QEMU, v2.6.0, configured it with 
  ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl
  and compiled it.

  I first tried to use memsave against Windows XP SP3 32 bits.
  This is the procedure i used :

  1 - start the VM with :
  ./i386-softmmu/qemu-system-i386 --enable-kvm -monitor stdio -hda 
~/vm/winxp.qcow2
  and wait for the desktop
  2 - take a physical memory dump with :
  pmemsave 0 134217728 dump.raw
  3 - call rekall on this memory dump to identify running processes :
  rekall -f dump.raw pslist
  _EPROCESS  Name  PID   PPID   ThdsHndsSess  Wow64 
  Start Exit  
  --  - -- --  -- -- 
 
  0x80e8fa00 System   4  0 46  148  - False  -  
  -   
  4 - read the first 16 bytes of the System PROCESS struct :
  memsave 0x80e8fa00 16 system
  5 - check the content with hexdump :
    03 00 1b 00 00 00 00 00  08 fa e8 80 08 fa e8 80
  you can recognize here the beginning of an EPROCESS struct.

  So on a 32 bits Windows XP OS, it works.

  But when i tried on Windows XP SP2 64 bits, rekall gave me the following 
output :
_EPROCESSName  PID   PPID   ThdsHndsSess  Wow64 
  Start Exit  
  --  - -- --  -- 
--  
  0xfadffd71d040 System   4  0 51  398  - False 
 --   
  And when i tried to read the memory with memsave :
  memsave 0xfadffd71d040 16 system

  I had the following error :
  Invalid addr 0xfadffd71d040/size 16 specified

  This address is supposed to be valid because I am reading the System EProcess 
struct, which should not be in the paged pool memory I think.
  Also i disabled the paging file to be sure and the bug is still present.

  Furthermore the bug is reproducible on the latest QEMU
  (01a720125f5e2f0a23d2682b39dead2fcc820066).

  Can you confirm that this is a bug ?
  Should i check something ?

  Thanks !

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

[Bug 1834051] Re: IRQ2 ignored under KVM when using IOAPIC

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  IRQ2 ignored under KVM when using IOAPIC

Status in QEMU:
  Expired

Bug description:
  When using KVM, and an OS that supports the IOAPIC, interrupts mapped
  on IRQ2 (for instance, routing an HPET timer on interrupt 2) will
  cause the interrupts to never be delivered. This is because QEmu, when
  setting up the KVM interrupt routes, will not set one up for IRQ2[0].
  When running without KVM, IRQ2 is identity-mapped to GSI2.

  My understanding is that IRQs should be identity mapped to their
  equivalent GSI unless a redirection entry is present in the MADT. This
  is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override
  Structure, which claims: "It is assumed that the ISA interrupts will
  be identity-mapped into the first I/O APIC sources.".

  I stumbled across this while working on my own custom OS, got very
  confused why the HPET wasn't triggering any interruption - and even
  more confused why the behavior only happened in KVM and not in non-
  KVM.

  EDIT: Interestingly, the HPET only supports IRQ2 when using the
  default PIIX chipset, which, combined with this bug, makes it
  completely unusable.

  [0]:
  
https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40

  [1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf

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

[Bug 1732981] Re: usb-net on aarch64 has wrong class IDs, isn't recognized by Windows

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  usb-net on aarch64 has wrong class IDs, isn't recognized by Windows

Status in QEMU:
  Expired

Bug description:
  If I run qemu-system-aarch64 with "-device usb-net,...", the resulting
  USB device will be seen in the guest as class 0x2, subclass 0x2,
  protocol 0xFF, instead of the expected class 0xe0, subclass 0x1,
  protocol 0x3. This prevents Windows' in-box class driver from binding
  to the device. On x86 and x64 Windows, this is not an issue, as
  another driver will bind to the device, but in Windows for ARM64, that
  driver is unavailable, so the USB device is incorrectly recognized as
  a serial port.

  Installing a modified version of the inbox driver in "Disable Driver
  Signature Enforcement" mode solves the issue, but it's not a very
  clean solution.

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

[Bug 1618122] Re: qemu-monitor screendump very slow

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-monitor screendump very slow

Status in QEMU:
  Expired

Bug description:
  qemu-monitor screendump often using 10-20% cpu usage of one core to
  take a small capture.

  Most of the CPU usage seems to come from libpixman. There were many
  reports of libpixman becoming 8 times slower in newer releases.

  
https://github.com/qemu/qemu/blob/0c56c6ab68902281094c7aac6305e2321c34c187/ui/console.c#L285

  Simple Valgrind Ir report.

  

     Ir
  

  9,994,313,959  PROGRAM TOTALS

  

     Ir  file:function
  

  4,883,603,360  
/usr/src/debug/pixman-0.34.0/pixman/pixman-access.c:store_scanline_b8g8r8 
[/usr/lib64/libpixman-1.so.0.34.0]
    282,312,800  
/usr/src/debug/pixman-0.34.0/pixman/pixman-implementation.c:_pixman_implementation_iter_init
 [/usr/lib64/libpixman-1.so.0.34.0]
    267,394,160  
/usr/src/debug/pixman-0.34.0/pixman/pixman-sse2.c:sse2_fetch_x8r8g8b8 
[/usr/lib64/libpixman-1.so.0.34.0]
    256,761,600  
/usr/src/debug/pixman-0.34.0/pixman/pixman-private.h:store_scanline_b8g8r8
    254,676,199  ???:0x00011f40 [/usr/lib64/libjemalloc.so.2]
    199,990,526  ???:0x00011a10 [/usr/lib64/libjemalloc.so.2]

  Calls to there start from.
  qemu_pixman_linebuf_fill
  pixman_image_composite
  
  pixman_image_composite32
  general_composite_rect

  I tried taking a look on how to fix this, but it seems pixman is
  deeply enrooted inside the monitor.  I wanted to try to simply take
  whats on the display and memcpy it into .ppm format manually creating
  the file header, but the image is all broken with colors being off or
  its smeared.

  For example this is DisplaySurface:

  struct DisplaySurface {
  pixman_format_code_t format;
  pixman_image_t *image;
  uint8_t flags;
  #ifdef CONFIG_OPENGL
  GLenum glformat;
  GLenum gltype;
  GLuint texture;
  #endif
  };

  
  It appears graphic_hw_update(con) renders the vram to a pixman_image.  Then 
ppm_save(filename, surface, errp) goes over it yet again, mutates the bytes in 
an expensive way to another pixman_image, and saves that row by row to a ppm.

  Using sdl graphics (the default) the drawing starts in
  
https://github.com/qemu/qemu/blob/7fa124b273acd22a808e742ead78c065ccd9b4c4/hw/display/vga.c#L1466

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

[Bug 1828507] Re: qemu-system-ppc64 smp crash on manual reset

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-system-ppc64 smp crash on manual reset

Status in QEMU:
  Expired

Bug description:
  Host Environment:
 x86_64 Linux v5.0.2
 QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4)
 SLOF:
 Build Date = Jan 14 2019 18:00:39
 FW Version = git-a5b428e1c1eae703

  Problem: Qemu crash immediately after a manual reset
   (this is not the initial reset which launches the guest).

  Steps:

  1. Download Debian ppc64el mini.iso:
 
http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso
  2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a 
single CPU, I was unable
 to reproduce the crash.
 qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso
  3. SLOF prints the version info on the serial device, and proceeds to boot.
  4. After a few seconds, the GRUB menu appears on the VGA screen.
  5. Select one of the install options (I have tested with Default and Expert), 
and wait
 for the Debian's text-mode installer (blue-gray-red) screen to appear.
  6. Click Machine->Reset (or enter system_reset on the qemu monitor).
  7. Notice that, on the serial device, SLOF has printed the version info. That 
is, the system
 has reset and is attempting to boot again.
  8. On the host cmd prompt, qemu dies after printing this fatal error and 
spewing the
 contents of the CPU registers:

 qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support
  (See attached out.txt for details)
 Aborted (core dumped)

  
  The HV exception is either
 (a) 70 = HISI, which occurs when NIP contains an outright bogus or 
inaccessible value, or
 (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner 
value, and
 the cpu attempts to run the instruction at that address.

  The exception can occur on either of the CPUs. It occurs when qemu is running 
the SLOF
  code.

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

[Bug 1691379] Re: NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  NetBSD evbmips64el port installation doesn't work with qemu-system-
  mips64el.

Status in QEMU:
  Expired

Bug description:
  I successfully installed the NetBSD evbmips64el port on gxemul but was
  unable to install it on qemu. Trying to boot it on qemu takes me to
  the 'db>' prompt. Here's the output and backtrace:

  panic: pcib_isa_intr_string: bogus isa irq 0x0
  kernel: breakpoint trap
  Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
  bdslot: nop
  db> bt
  0x805977f0: cpu_Debugger+4 
(63061,9000180003f8,6,804c2290) ra 8030acd0 sz 0
  0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) ra 
8030ad7c sz 64
  0x80597830: panic+34 (63061,803d65b0,0,40) ra 
80109784 sz 96
  0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) ra 
80149bfc sz 16
  0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
802f0400 sz 176
  0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
802f053c sz 64
  0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
80121354 sz 64
  0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
80121548 sz 288
  0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
8012167c sz 160
  0x80597b90: pcirescan+5c (63061,803d65b0,0,0) ra 
801218c4 sz 32
  0x80597bb0: pciattach+19c (63061,803d65b0,0,0) ra 
802f0400 sz 80
  0x80597c00: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
802f053c sz 64
  0x80597c40: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
80108934 sz 64
  0x80597c80: gt_attach+7c (63061,803d65b0,0,0) ra 
802f0400 sz 112   
  0x80597cf0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
802f053c sz 64
  0x80597d30: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
801086ac sz 64
  0x80597d70: mainbus_attach+dc (63061,803d65b0,0,0) ra 
802f0400 sz 96
  0x80597dd0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
80104bf8 sz 64
  0x80597e10: cpu_configure+28 (63061,803d65b0,0,0) ra 
803d5f30 sz 16
  0x80597e20: main+3a0 (63061,803d65b0,0,0) ra 801000dc 
sz 128   
  0x80597ea0: kernel_text+dc (63061,803d65b0,0,0) ra 0 sz 0
  User-level: pid 0.1

  Here's the command that I used:

  Build evbmips64el from source and then launch it from qemu (replace
  the paths relative to your system):

  qemu-system-mips64el -cdrom
  /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71
  -evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel
  /extra/evbmips64/releasedir/evbmips/installation/netbsd-
  INSTALL_MALTA64 -nographic -M malta

  (I've decompressed the kernel)

  Here's the output for qemu-system-mips64el --version :

  QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c)
  2003-2016 Fabrice Bellard and the QEMU Project developers

  This doesn't look like a NetBSD bug. I've attached a screenshot of the
  working installation using gxemul in the attachments.

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

[Bug 1833204] Re: VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0"

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  VM failed to start in nested virtualization with error "KVM: entry
  failed, hardware error 0x0"

Status in QEMU:
  Expired

Bug description:
  Hi,

  I have 3 ubuntu nodes provisioned by IaaS. 
  Then I tried to launch VM again in my ubuntu nodes.
  It's a little strange that VM could be started successfully in two nodes. 
  And always failed in one nodes with error "KVM: entry failed, hardware error 
0x0". 

  When using virsh to resume the VM, it failed with following error,
  virsh # list
   Id   NameState
  --
   1default_vm-cirros   paused

  virsh # resume default_vm-cirros
  error: Failed to resume domain default_vm-cirros
  error: internal error: unable to execute QEMU command 'cont': Resetting the 
Virtual Machine is required

  
  The detailed log from /var/log/libvirt/qemu/default_vm-cirros.log is as below.
  ```
  2019-06-18 09:55:52.397+: starting up libvirt version: 5.0.0, package: 
1.fc28 (Unknown, 2019-01-22-08:04:34, 64723eea657e48d296e6beb0b1be9c4c), qemu 
version: 3.1.0qemu-3.1.0-4.fc28, kernel: 4.15.0-47-generic, hostname: vm-cirros
  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  HOME=/root \
  QEMU_AUDIO_DRV=none \
  /usr/bin/qemu-system-x86_64 \
  -name guest=default_vm-cirros,debug-threads=on \
  -S \
  -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_vm-cirros/master-key.aes
 \
  -machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off \
  -cpu 
Broadwell-IBRS,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,mpx=on,avx512f=on,avx512cd=on,ssbd=on,xsaveopt=on,abm=on,invpcid=off
 \
  -m 489 \
  -realtime mlock=off \
  -smp 1,sockets=1,cores=1,threads=1 \
  -object iothread,id=iothread1 \
  -uuid 0d2a2043-41c0-59c3-9b17-025022203668 \
  -no-user-config \
  -nodefaults \
  -chardev socket,id=charmonitor,fd=22,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot strict=on \
  -device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
  -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
  -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
  -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
  -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
  -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
  -drive 
file=/var/run/kubevirt-ephemeral-disks/container-disk-data/default/vm-cirros/disk_containerdisk/disk-image.raw,format=raw,if=none,id=drive-ua-containerdisk,cache=none
 \
  -device 
virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-ua-containerdisk,id=ua-containerdisk,bootindex=1,write-cache=on
 \
  -drive 
file=/var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-cirros/noCloud.iso,format=raw,if=none,id=drive-ua-cloudinitdisk,cache=none
 \
  -device 
virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-ua-cloudinitdisk,id=ua-cloudinitdisk,write-cache=on
 \
  -netdev tap,fd=24,id=hostua-default,vhost=on,vhostfd=25 \
  -device 
virtio-net-pci,host_mtu=1430,netdev=hostua-default,id=ua-default,mac=16:57:38:cd:57:cb,bus=pci.1,addr=0x0
 \
  -chardev socket,id=charserial0,fd=26,server,nowait \
  -device isa-serial,chardev=charserial0,id=serial0 \
  -chardev socket,id=charchannel0,fd=27,server,nowait \
  -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 \
  -vnc 
vnc=unix:/var/run/kubevirt-private/3b22a138-91af-11e9-af36-0016ac101123/virt-vnc
 \
  -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \
  -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
  -msg timestamp=on
  KVM: entry failed, hardware error 0x0
  EAX= EBX= ECX= EDX=000306d2
  ESI= EDI= EBP= ESP=
  EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =   9300
  CS =f000   9b00
  SS =   9300
  DS =   9300
  FS =   9300
  GS =   9300
  LDT=   8200
  TR =   8b00
  GDT=  
  IDT=  
  CR0=6010 CR2= CR3= CR4=
  DR0= DR1= DR2= 
DR3= 
  DR6=0ff0 DR7=0400
  EFER=
  Code=06 66 05 00 00 01 00 8e c1 26 66 a3 14 f5 66 5b 66 5e 66 c3  5b e0 
00 f0 30 36 2f 32 33 

[Bug 1835732] Re: GTK display zoom in, zooms infinitely

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  GTK display zoom in, zooms infinitely

Status in QEMU:
  Expired

Bug description:
  The zoom in feature in the "View" menu of the gtk frontend (launch
  qemu with -display gtk), seems to be very broken.

  If I hit the zoom in feature, it first zooms in.

  Then, it zooms in again.

  Every subsequent second that passes, it zooms in again, until it
  eventually eats up too much host resources and freezes the host
  desktop.

  I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also
  with a locally built 4.0, My colleague also confirms having seen the
  issue with 3.1.0 (Debian 1:3.1+dfsg-8).

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

[Bug 1774149] Re: qemu-user x86_64 x86 gdb call function from gdb doesn't work

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-user x86_64 x86 gdb call function from gdb doesn't work

Status in QEMU:
  Expired

Bug description:
  While running qemu user x86_64 x86 with gdb server, calling functions
  are not working.

  Here is how to reproduce it:

  run in a terminal:
  $ qemu-x86_64 -g 12345 -L / /bin/ls

  In another terminal run gdb:
  (gdb) file /bin/ls
  (gdb) target remote :12345
  (gdb) b _init
  (gdb) c
  (gdb) call malloc(1)
  Could not fetch register "fs_base"; remote failure reply 'E14'

  In other cases we also got the error:
  Could not fetch register "orig_rax"; remote failure reply 'E14'

  Here is how I patched it (it is only a workaround):

  diff --git a/gdbstub.c b/gdbstub.c
  index 2a94030..5749efe 100644
  --- a/gdbstub.c
  +++ b/gdbstub.c
  @@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t 
*mem_buf, int reg)
   return r->get_reg(env, mem_buf, reg - r->base_reg);
   }
   }
  +#ifdef TARGET_X86_64
  +return 8;
  +#elif TARGET_I386
  +return 4;
  +#endif
   return 0;
   }

  (Our guess for this issue was, gdb is requesting for 'fake' registers
  to know register size)

  Once we patched that, we got another problem while calling functions
  from gdb: We could call functions, but only once.

  Here is how to reproduce it:
  run in a terminal:
  $ qemu-x86_64 -g 12345 -L / /bin/ls

  In another terminal run gdb:
  (gdb) file /bin/ls
  (gdb) target remote :12345
  (gdb) b _init
  (gdb) c
  (gdb) call malloc(1)
  $1 = (void *) 0x620010
  (gdb) call malloc(1)
  Cannot access memory at address 0x40007ffb8f

  Here is how we patched it to make it work:

  diff --git a/exec.c b/exec.c
  index 03238a3..d303922 100644
  --- a/exec.c
  +++ b/exec.c
  @@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong 
addr,
   if (!(flags & PAGE_VALID))
   return -1;
   if (is_write) {
  -if (!(flags & PAGE_WRITE))
  +if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG)))
   return -1;
   /* XXX: this code should not depend on lock_user */
   if (!(p = lock_user(VERIFY_WRITE, addr, l, 0)))

  From what we saw, there is a page which is passed to read-only after
  first execution, and gdb need to write on that page to put a
  breakpoint. (on the stack to get function return)

  We suspect this is linked to this:
  
https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation

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

[Bug 1836855] Re: virtio_scsi_ctx_check failed when detach virtio_scsi disk

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  virtio_scsi_ctx_check failed when detach virtio_scsi disk

Status in QEMU:
  Expired

Bug description:
  I found a problem  that virtio_scsi_ctx_check  failed when detaching
  virtio_scsi disk.  The  bt is below:

  (gdb) bt
  #0  0xb02e1bd0 in raise () from /lib64/libc.so.6
  #1  0xb02e2f7c in abort () from /lib64/libc.so.6
  #2  0xb02db124 in __assert_fail_base () from /lib64/libc.so.6
  #3  0xb02db1a4 in __assert_fail () from /lib64/libc.so.6
  #4  0x004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, 
s=, s=)
  at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243
  #5  0x004ec87c in virtio_scsi_handle_cmd_req_prepare 
(s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90)
  at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553
  #6  0x004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, 
vq=0xd283410)
  at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588
  #7  0x004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, 
vq=0xae7a6f98)
  at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57
  #8  0x00877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323
  #9  0x008773ec in aio_poll (ctx=0xac61010, blocking=true) at 
util/aio-posix.c:472
  #10 0x005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49
  #11 0x0087a8b8 in qemu_thread_start (args=0xac61360) at 
util/qemu-thread-posix.c:495
  #12 0x008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at 
uvp/hotpatch/qemu_hotpatch_helper.c:579
  #13 0xb041c8bc in start_thread () from /lib64/libpthread.so.0
  #14 0xb0382f8c in thread_start () from /lib64/libc.so.6

  assert(blk_get_aio_context(d->conf.blk) == s->ctx)  failed.

  I think this patch
  
(https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b)
  introduce this problem.

  commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b  move blockbackend
  back to main AioContext on unplug. It set the AioContext of

  SCSIDevice  to the main AioContex, but s->ctx is still the iothread
  AioContext.  Is this a bug?

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

[Bug 1766841] Re: QEMU 2.12 Running Problem in Windows 7 Installation

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  QEMU 2.12 Running Problem in Windows 7 Installation

Status in QEMU:
  Expired

Bug description:
  QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe  from Stefan 
Weil's website so I am not sure I should report it to Weil by email or by this 
bug report system.)
  Host System: Windows 7 64bit
  Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 
2018/02/02)

  QEMU Command:
  qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 
9front-6350.iso -boot d

  QEMU warning: 
  (qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf 
loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such 
file or directory

  This likely means that your installation is broken.
  Try running the command
gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
  to make things work again for the time being.

  (qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 
'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, 
perhaps you need to install it.
  You can get a copy from:
  http://icon-theme.freedesktop.org/releases

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

[Bug 1836763] Re: Firebird crashes on qemu-m68k-user with pthread_mutex_init error

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Firebird crashes on qemu-m68k-user with pthread_mutex_init error

Status in QEMU:
  Expired

Bug description:
  Trying to use the Firebird database on qemu-m68k-user with a Debian
  chroot fails with the database crashing with "ConfigStorage: mutex
  pthread_mutex_init error, status = 95":

  (sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
cpio libip4tc0
  Use 'apt autoremove' to remove them.
  The following additional packages will be installed:
firebird3.0-common firebird3.0-common-doc firebird3.0-server-core 
firebird3.0-utils libfbclient2 libib-util
  Suggested packages:
firebird3.0-doc
  The following NEW packages will be installed:
firebird3.0-common firebird3.0-common-doc firebird3.0-server 
firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util
  0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded.
  Need to get 4,051 kB of archives.
  After this operation, 15.9 MB of additional disk space will be used.
  Do you want to continue? [Y/n] 
  Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB]
  Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB]
  Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB]
  Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util 
m68k 3.0.5.33100.ds4-3 [3,220 B]
  Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB]
  Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB]
  Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k 
firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB]
  Fetched 4,051 kB in 2s (1,803 kB/s)  
  debconf: delaying package configuration, since apt-utils is not installed
  E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such 
device)
  Selecting previously unselected package firebird3.0-common-doc.
  (Reading database ... 33605 files and directories currently installed.)
  Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ...
  Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package firebird3.0-common.
  Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ...
  Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package libfbclient2:m68k.
  Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ...
  Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package libib-util:m68k.
  Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ...
  Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package firebird3.0-server-core:m68k.
  Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb 
...
  Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package firebird3.0-utils.
  Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ...
  Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ...
  Selecting previously unselected package firebird3.0-server.
  Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ...
  Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ...
  Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ...
  Setting up firebird3.0-common (3.0.5.33100.ds4-3) ...
  Setting up libib-util:m68k (3.0.5.33100.ds4-3) ...
  Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ...
  Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ...
  Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ...
  Setting up firebird3.0-server (3.0.5.33100.ds4-3) ...
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Password for firebird 3.0
  -

  Firebird has a special user named SYSDBA, which is the user that has access 
to all databases. SYSDBA can also create new databases and users. Because of 
this, it is
  necessary to secure SYSDBA with a password.

  The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by 
root). You 

[Bug 690776] Re: Overwrite argv to set process title, eliminating 16-character prctl() limit.

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Overwrite argv to set process title, eliminating 16-character prctl()
  limit.

Status in QEMU:
  Expired

Bug description:
  I've modified qemu to overwrite its arguments to set the process
  title, since its current prctl() method has a 16-character limit.

  I posted the original patch to qemu-devel, made the changes others
  suggested, then re-posted to qemu-devel. I flailed around a bit with
  the patch submission process and think I finally got it right, but
  haven't been able to gain the notice of a committer to have this
  pushed. Maybe this will get more attention when reported in the BTS.

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

[Bug 1836136] Re: u-boot: any plans to update u-boot to v2019.07

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  u-boot: any plans to update u-boot to v2019.07

Status in QEMU:
  Expired

Bug description:
  Just want to pulse about the plan to update u-boot binary to latest
  v2019.07.

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

[Bug 1207896] Re: binfmt wrapper for argv[0] handling

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  binfmt wrapper for argv[0] handling

Status in QEMU:
  Expired

Bug description:
  Please, add patch https://lists.gnu.org/archive/html/qemu-
  devel/2011-09/msg03841.html to upstream. 2 years have passed and this
  patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu
  with this patch. It is 100% needed.

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

[Bug 1774605] Re: PowerPC guest does not emulate L2 and L3 cache for KVM vCPUs

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  PowerPC guest does not emulate L2 and L3 cache for KVM vCPUs

Status in QEMU:
  Expired

Bug description:
  PowerPC KVM guest does not emulate L2 and L2 caches for vCPU, it would
  be good to have them emulated to guest if not any known
  issues/limitation already with PowerPC.

  Host Env:
  kernel: 4.17.0-rc7-00045-g0512e0134582
  qemu: v2.12.0-923-gc181ddaa17-dirty
  #libvirtd -V
  libvirtd (libvirt) 4.4.0

  Guest Kernel:
  # uname -a
  Linux atest-guest 4.17.0-rc7-00045-g0512e0134582 #9 SMP Fri Jun 1 02:55:50 
EDT 2018 ppc64le ppc64le ppc64le GNU/Linux

  Guest:
  # lscpu
  Architecture:ppc64le
  Byte Order:  Little Endian
  CPU(s):  16
  On-line CPU(s) list: 0-15
  Thread(s) per core:  8
  Core(s) per socket:  2
  Socket(s):   1
  NUMA node(s):1
  Model:   2.1 (pvr 004b 0201)
  Model name:  POWER8 (architected), altivec supported
  Hypervisor vendor:   KVM
  Virtualization type: para
  L1d cache:   64K
  L1i cache:   32K
  NUMA node0 CPU(s):   0-15

  background: x86 enabling cpu L2 cache bydefault and L3 cache on demand for 
kvm guest
  and claims performance improvement as vcpus can be
  benefited with lesser `vmexits due to guest send IPIs.` with L3 cache 
enabled, below was patch for same.

  
https://git.qemu.org/?p=qemu.git;a=commit;h=14c985cffa6cb177fc01a163d8bcf227c104718c

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

[Bug 1837851] Re: hv-tlbflush malfunctions on Intel host CPUs with neither EPT nor VPID (qemu-kvm)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  hv-tlbflush malfunctions on Intel host CPUs with neither EPT nor VPID
  (qemu-kvm)

Status in QEMU:
  Expired

Bug description:
  Enabling hv-tlbflush on older hosts using Intel CPUs supporting VT-x
  but neither EPT nor VPID will lead to bluescreens on the guest.

  It seems KVM only checks if EPT is available, and if it isn't it
  forcibly uses VPID. If that's *also* not available, it defaults to
  basically a no-op hypercall, though windows is expecting the TLB to be
  flushed.

  hv-tlbflush is pretty useless on machines not supporting these
  extensions anyway (only reasonably fix I can see would be to flush the
  *entire* TLB on tlbflush hypercall in KVM (i.e. a kernel fix), but
  that would remove any performance benefits), so I would suggest some
  kind of preliminary check and warning/error if hv-tlbflush is
  specified on such a host.

  All CPUs mentioned in this thread[0] are confirmed to be affected by
  the bug, and I have successfully reproduced it on an Intel Core2Duo
  E8500.

  [0] https://forum.proxmox.com/threads/windows-guest-bluescreen-with-
  proxmox-6.56053/

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

[Bug 1837909] Re: test-char fails if host has no network interfaces

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  Expired

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c 
inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes 
it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or 
ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

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

[Bug 1538541] Re: qcow2 rejects request to use preallocation with backing file

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qcow2 rejects request to use preallocation with backing file

Status in QEMU:
  Expired

Bug description:
  The 'preallocation=full' option to qemu-img / qcow2 block driver
  instructs QEMU to fully allocate the host file to the maximum size
  needed by the logical disk size.

  $ qemu-img create -f qcow2 -o preallocation=full base.qcow2 200M
  Formatting 'base.qcow2', fmt=qcow2 size=209715200 encryption=off 
cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16

  $ ls -alhs base.qcow2 
  201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2

  
  When specifying a backing file for the qcow2 file, however, it rejects the 
preallocation request

  $ qemu-img create -f qcow2 -o preallocation=full,backing_file=base.qcow2 
front.qcow2 200M
  Formatting 'front.qcow2', fmt=qcow2 size=209715200 backing_file='base.qcow2' 
encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off 
refcount_bits=16
  qemu-img: front.qcow2: Backing file and preallocation cannot be used at the 
same time

  
  It might seem like requesting full preallocation is redundant because most 
data associated with the image will be present in the backing file, as so the 
top layer is unlikely to ever need the full preallocation.  Rejecting this, 
however, means it is not (officially) possible to reserve disk space for the 
top layer to guarantee that future copy-on-writes will never get ENOSPC.

  OpenStack in particular uses backing files with all images, in order
  to avoid the I/O overhead of copying the backing file contents into
  the per-VM disk image. It, however, still wants to have a guarantee
  that the per-VM image will never hit an ENOSPC scenario.

  Currently it has to hack around QEMU's refusal to allow backing_file +
  preallocation, by calling 'fallocate' on the qcow2 file after it has
  been created. This is an inexact fix though, because it doesn't take
  account of fact that qcow2 metadata can takes some MBs of space.

  Thus, it would like to see preallocation=full supported in combination
  with backing files.

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

[Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-img convert on Mac OSX creates corrupt images

Status in QEMU:
  Expired

Bug description:
  An image created by qemu-img create, then modified by another program
  is converted to bad/corrupt image when using convert sub command on
  Mac OSX. The same convert works on Linux. The version of qemu-img is
  2.12.

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

[Bug 1840249] Re: Cancelling 'make docker-test-build' does not cancel running containers

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Cancelling 'make docker-test-build' does not cancel running containers

Status in QEMU:
  Expired

Bug description:
  version: v4.1.0-rc5

  Run 'make -k docker-test-build', wait a few, cancel with ^C:

  $ make -k docker-test-build 2>&1 > /dev/null
  ^C

  $ docker ps
  CONTAINER IDIMAGECOMMAND  
CREATED STATUS
  62264a2d777aqemu:debian-mips-cross   "/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes
  80807c47d0dfqemu:debian-armel-cross  "/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes
  06027b5dfd4aqemu:debian-amd64"/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes

  The docker containers are still up building QEMU.

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

[Bug 1838465] Re: qemu-system-x86_64 kernel panic 30% of the time starting up VM

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-system-x86_64 kernel panic 30% of the time starting up VM

Status in QEMU:
  Expired

Bug description:
  I have created a Fedora Core 5 x86_64 VM image. When I run the image
  using QEMU on Windows the VM hangs while loading the kernel about 30%
  of the time. I am trying to use this VM with a CI software, looking at
  the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is
  installed on the CI machine. I have tried using the exact same image
  using QEMU on Linux (Ubuntu) and found the image boot successful every
  time (40+ attempts). The VM image is fairly old it was created using
  QEMU 0.11.1.

  I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and
  3.0.0 all of them fail randomly. I can reproduce the issue on several
  different Windows 10 computers.

  The command I am using to start the VM is “qemu-system-x86_64.exe -cpu
  qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G
  -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`"
  -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22”

  I can provide the qcow image but it is somewhat large coming it at
  4.15GB so I’m not sure what would be the best way to transfer it.

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

[Bug 1829696] Re: qemu-kvm takes 100% CPU when running redhat/centos 7.6 guest VM OS

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-kvm takes 100% CPU when running redhat/centos 7.6 guest VM OS

Status in QEMU:
  Expired

Bug description:
  Description
  ===
  When running redhat or centos 7.6 guest os on vm,
  the cpu usage is very low on vm(100% idle), but on host,
  qemu-kvm reports 100% cpu busy usage.

  After searching some related bugs report,
  I suspect that it is due to the clock settings in vm's domain xml.
  My Openstack cluster uses the default clock settings as follow:
  



  
  And in this report, https://bugs.launchpad.net/qemu/+bug/1174654
  it claims that  can solve the 100% cpu usage 
problem when using Windows Image Guest OS,
  but I makes some tests, the solusion dose not work for me.

  
  Steps to reproduce
  ==
  * create a vm using centos or redhat 7.6 image
  * using sar tool inside vm and host to check the cpu usage, and compare them

  
  Expected result
  ===
  host's cpu usage report should be same with vm's cpu usage

  
  Actual result
  =
  vm's cpu usage is 100% idle, host's cpu usage is 100% busy

  
  Environment
  ===
  1. Exact version of OpenStack you are running.
  # rpm -qa | grep nova
  openstack-nova-compute-13.1.2-1.el7.noarch
  python2-novaclient-3.3.2-1.el7.noarch
  python-nova-13.1.2-1.el7.noarch
  openstack-nova-common-13.1.2-1.el7.noarch

  2. Which hypervisor did you use?
 (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
 What's the version of that?
  # libvirtd -V
  libvirtd (libvirt) 3.9.0

  # /usr/libexec/qemu-kvm --version
  QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 
2003-2008 Fabrice Bellard

  
  Logs & Configs
  ==
  The VM xml:
  
instance-5022
7f5a66a5----75decbbb

  http://openstack.org/xmlns/libvirt/nova/1.0;>

***
2019-05-20 03:08:46

  2048
  12
  2048
  0
  1


  
  


  

2097152
2097152
1

  1024
  
  


  
  


  /machine


  
Fedora Project
OpenStack Nova
13.1.2-1.el7
64ab0e89----05312ef66983
7f5a66a5----75decaf82bbb
Virtual Machine
  


  hvm
  
  


  
  


  IvyBridge
  
  
  
  
  

  


  
  
  

destroy
restart
destroy

  /usr/libexec/qemu-kvm
  






  
  






  
  







  
  


  
  

  
  


  
  



  
  





  
  


  


  
  


  


  
  



  
  


  
  

  
  

  
  

  
  



  
  



  


  +107:+107
  +107:+107

  

  CPU Usage Report inside VM:
  # sar -u -P 0 1 5
  Linux 3.10.0-957.el7.x86_64 (**)  05/20/2019  _x86_64_(1 CPU)

  11:34:40 AM CPU %user %nice   %system   %iowait%steal 
%idle
  11:34:41 AM   0  0.00  0.00  0.00  0.00  0.00
100.00
  11:34:42 AM   0  0.00  0.00  0.00  0.00  0.00
100.00
  11:34:43 AM   0  0.00  0.00  0.00  0.00  0.00
100.00
  11:34:44 AM   0  0.00  0.00  0.00  0.00  0.00
100.00
  11:34:45 AM   0  0.00  0.00  0.00  0.00  0.00
100.00
  Average:  0  0.00  0.00  0.00  0.00  0.00
100.00

  CPU Usage Report ON HOST(the vm's cpu is pinned on host's no.27 physic cpu):
  # sar -u -P 27 1 5
  Linux 3.10.0-862.el7.x86_64 (**)  05/20/2019  _x86_64_(48 CPU)

  11:34:40 AM CPU %user %nice   %system   %iowait%steal 
%idle
  11:34:41 AM  27100.00  0.00  0.00  0.00  0.00  
0.00
  11:34:42 AM  27100.00  0.00  0.00  0.00  0.00  
0.00
  11:34:43 AM  27100.00  0.00  0.00  0.00  0.00  
0.00
  11:34:44 AM  27100.00  0.00

[Bug 1844053] Re: task blocked for more than X seconds - events drm_fb_helper_dirty_work

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  task blocked for more than X seconds - events drm_fb_helper_dirty_work

Status in QEMU:
  Expired

Bug description:
  I've had bunches of these errors on 9 different boots, between
  2019-08-21 and now, with Arch host and guest, from linux 5.1.16 to
  5.2.14 on host and guest, with QEMU 4.0.0 and 4.1.0.  spice 0.14.2,
  spice-gtk 0.37, spice-protocol 0.14.0, virt-viewer 8.0.

  I've been fighting with some other issues related to a 5.2 btrfs
  regression, a QEMU qxl regression (see bug 1843151) which I ran into
  when trying to temporarily abandon virtio-vga, and I haven't paid
  enough attention to what impact specifically this virtio_gpu issue has
  on the system In journalctl, I can see I often rebooted minutes after
  they occurred, but sometimes much later.  That must mean whenever I
  saw it happen that I rebooted the VM, or potentially it impacted
  functionality of the system.

  Please let me know if and how I can get more information for you if
  needed.

  I've replicated this on both a system with integrated ASPEED video,
  and on an AMD Vega 64 running amdgpu.

  As an example, I have one boot which reported at 122 seconds, 245,
  368, 491, 614, 737, 860, 983, 1105, 1228, then I rebooted.

  I have another that reported 122/245/368/491/614/737, went away for 10
  minutes, then started reporting again 122/245/368/491, and went away.
  Then, I rebooted about 20 hours later.

  Host system has no graphical impact when this happens, and logs
  nothing in its journalctl.

  Guest is tty mode only, with kernel argument "video=1280x1024".  No x
  server.

  ==

  INFO: task kworker/0:1:15 blocked for more than 122 seconds.
    Not tainted 5.2.14-1 #1
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  kworker/0:1 D015  2 0x84000
  Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper]
  Call Trace:
   ? __schedule+0x27f/0x6d0
   schedule+0x3d/0xc0
   virtio_gpu_queue_fenced_ctrl_buffer+0xa1/0x130 [virtio_gpu]
   ? wait_woken+0x80/0x80
   virtio_gpu_surface_dirty+0x2a5/0x300 [virtio_gpu]
   drm_fb_helper_dirty_work+0x156/0x160 [drm_kms_helper]
   process_one_work+0x19a/0x3b0
   worker_tread+0x50/0x3a0
   kthread+0xfd/0x130
   ? process_one_work+0x3b0/0x3b0
   ? kthread_park+0x80/0x80
   ret_from_fork+0x35/0x40

  ==

  /usr/bin/qemu-system-x86_64 \
     -name vm,process=qemu:vm \
     -no-user-config \
     -nodefaults \
     -nographic \
     -uuid  \
     -pidfile  \
     -machine q35,accel=kvm,vmport=off,dump-guest-core=off \
     -cpu SandyBridge-IBRS \
     -smp cpus=4,cores=2,threads=1,sockets=2 \
     -m 4G \
     -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd 
\
     -drive if=pflash,format=raw,file=/var/qemu/efivars/vm.fd \
     -monitor telnet:localhost:8000,server,nowait,nodelay \
     -spice unix,addr=/tmp/spice.vm.sock,disable-ticketing \
     -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 \
     -device virtio-vga,bus=pcie.1,addr=0 \
     -usbdevice tablet \
     -netdev bridge,id=network0,br=br0 \
     -device 
virtio-net-pci,netdev=network0,mac=F4:F6:34:F6:34:2d,bus=pcie.0,addr=3 \
     -device virtio-scsi-pci,id=scsi1 \
     -drive 
driver=raw,node-name=hd0,file=/dev/lvm/vm,if=none,discard=unmap,cache=none,aio=threads

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

[Bug 1594394] Re: Using setreuid / setegid crashes x86_64 user-mode target

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Using setreuid / setegid crashes x86_64 user-mode target

Status in QEMU:
  Expired

Bug description:
  When setreuid() or setegid() are called from x86_64 target code in
  user mode, qemu crashes inside the NPTL signal handlers.  x86 targets
  do not directly use a syscall to handle setreuid() / setegid();
  instead the x86 NPTL implementation sets up a temporary data region in
  memory (__xidcmd) and issues a signal (SIGRT1) to all threads,
  allowing the handler for that signal to issue the syscall.  Under
  qemu, __xidcmd remains null (see variable display below backtrace).

  Backtrace:
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x3fff85c74fc0 (LWP 74517)]
  0x6017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, 
ctx=0x3fff85c71f90) at nptl-init.c:263
  263 nptl-init.c: No such file or directory.
  (gdb) thread apply all bt

  Thread 3 (Thread 0x3fff87e8efc0 (LWP 74515)):
  #0  0x601cc430 in syscall ()
  #1  0x60109080 in futex_wait (val=, ev=) at /build/qemu/util/qemu-thread-posix.c:292
  #2  qemu_event_wait (ev=0x62367bb0 ) at 
/build/qemu/util/qemu-thread-posix.c:399
  #3  0x6010f73c in call_rcu_thread (opaque=) at 
/build/qemu/util/rcu.c:250
  #4  0x60176f8c in start_thread (arg=0x3fff87e8efc0) at 
pthread_create.c:336
  #5  0x601cebf4 in clone ()

  Thread 2 (Thread 0x3fff85c74fc0 (LWP 74517)):
  #0  0x6017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, 
ctx=0x3fff85c71f90) at nptl-init.c:263
  #1  
  #2  0x601cc42c in syscall ()
  #3  0x60044b08 in safe_futex (val3=, uaddr2=0x0, 
timeout=, val=, op=128, uaddr=) at 
/build/qemu/linux-user/syscall.c:748
  #4  do_futex (val3=, uaddr2=275186650880, timeout=0, val=1129, 
op=128, uaddr=275186651116) at /build/qemu/linux-user/syscall.c:6201
  #5  do_syscall (cpu_env=0x1000abfd350, num=, 
arg1=275186651116, arg2=, arg3=1129, arg4=0, arg5=275186650880, 
arg6=, arg7=0, arg8=0)
  at /build/qemu/linux-user/syscall.c:10651
  #6  0x600347b8 in cpu_loop (env=0x1000abfd350) at 
/build/qemu/linux-user/main.c:317
  #7  0x60036ae0 in clone_func (arg=0x3fffc4c2ca38) at 
/build/qemu/linux-user/syscall.c:5445
  #8  0x60176f8c in start_thread (arg=0x3fff85c74fc0) at 
pthread_create.c:336
  #9  0x601cebf4 in clone ()

  Thread 1 (Thread 0x1000aa05000 (LWP 74511)):
  #0  0x601cc430 in syscall ()
  #1  0x60044b08 in safe_futex (val3=, uaddr2=0x0, 
timeout=, val=, op=128, uaddr=) at 
/build/qemu/linux-user/syscall.c:748
  #2  do_futex (val3=, uaddr2=1, timeout=0, val=1, op=128, 
uaddr=275078324992) at /build/qemu/linux-user/syscall.c:6201
  #3  do_syscall (cpu_env=0x1000aa23890, num=, 
arg1=275078324992, arg2=, arg3=1, arg4=0, arg5=1, 
arg6=, arg7=0, arg8=0) at /build/qemu/linux-user/syscall.c:10651
  #4  0x600347b8 in cpu_loop (env=0x1000aa23890) at 
/build/qemu/linux-user/main.c:317
  #5  0x600020e4 in main (argc=, argv=, 
envp=) at /build/qemu/linux-user/main.c:4779
  (gdb) p __xidcmd
  $1 = (struct xid_command *) 0x0

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

[Bug 1839294] Re: Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately
  deletes installed files at the very end of the installation

Status in QEMU:
  Expired

Bug description:
  This happens on Windows 10 with the latest installer for 64 bit
  Windows: qemu-w64-setup-20190807.exe

  On install it will create the files and go through all the typical
  functions of installing the software, at the very end step it will
  then delete all files the installer created.

  I looked for logs to see when was going on so I ran the installation
  in Sandboxie and was able to retain all the installed files but I
  couldn't find a log for the installer.

  Here is a screenshot of it deleting all the files at the end of the
  process.

  https://imgur.com/BWiTA38

  If goes too fast for me to see what is written in the text console
  otherwise I would post more information but this is all I have. It
  does not give any error or any other information at completion.

  This error does not occur in the earlier release:
  qemu-w64-setup-20190731.exe

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

[Bug 1835466] Re: qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?)

Status in QEMU:
  Expired

Bug description:
  After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release
  tarball), I'm seeing a (reproducible) crash related to audio
  subsystem.

  I recompiled qemu with debugging options and got it to crash under
  gdb:

  Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted.
  0x752e420b in raise () from /lib64/libc.so.6
  (gdb) bt
  #0  0x752e420b in raise () at /lib64/libc.so.6
  #1  0x752c6524 in abort () at /lib64/libc.so.6
  #2  0x0041ec33 in audio_get_pdo_in (dev=) at 
audio/audio_template.h:328
  #3  0x005d0123 in AUD_open_in
  (card=0x7ffdde98dbc8, sw=0x717444e0, name=0x999d80 "adc", 
callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 
, as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434
  #4  0x0060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at 
hw/audio/hda-codec.c:490
  #5  0x0061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, 
data=) at hw/audio/hda-codec.c:590
  #6  0x0060ea20 in intel_hda_send_command (d=d@entry=0x70a2fc00, 
verb=verb@entry=4341777) at hw/audio/intel-hda.c:301
  #7  0x0060ebbe in intel_hda_corb_run (d=) at 
hw/audio/intel-hda.c:336
  #8  0x0060ebbe in intel_hda_corb_run (d=0x70a2fc00) at 
hw/audio/intel-hda.c:305
  #9  0x00495b99 in memory_region_write_accessor
  (mr=mr@entry=0x70a307a0, addr=72, value=value@entry=0x7fffeddfe568, 
size=size@entry=2, shift=, mask=mask@entry=65535, attrs=...)
  at memory.c:502
  #10 0x0049448e in access_with_adjusted_size
  (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, 
access_size_min=, access_size_max=, 
access_fn=access_fn@entry=0x495b10 , 
mr=0x70a307a0, attrs=...) at memory.c:568
  #11 0x004974f3 in memory_region_dispatch_write 
(mr=mr@entry=0x70a307a0, addr=72, data=, size=2, 
attrs=attrs@entry=...)
  at memory.c:1496
  #12 0x0042afbc in flatview_write_continue
  (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., 
buf=buf@entry=0x766c7028 , len=len@entry=2, 
addr1=, l=, mr=0x70a307a0) at exec.c:3279
  #13 0x0042b1d6 in flatview_write
  (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., 
buf=buf@entry=0x766c7028 , len=len@entry=2)
  at exec.c:3318
  #14 0x0042e2a6 in address_space_write
  (as=0xfc5080 , addr=4228186184, attrs=..., 
buf=buf@entry=0x766c7028 , len=2)
  at exec.c:3408
  #15 0x0042e33a in address_space_rw (as=, 
addr=, attrs=..., 
  attrs@entry=..., buf=buf@entry=0x766c7028 , 
len=, is_write=) at exec.c:3419
  #16 0x004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x70a81140) at 
accel/kvm/kvm-all.c:2034
  #17 0x004812ae in qemu_kvm_cpu_thread_fn (arg=0x70a81140) at 
cpus.c:1281
  #18 0x004812ae in qemu_kvm_cpu_thread_fn 
(arg=arg@entry=0x70a81140) at cpus.c:1254
  #19 0x0089d0eb in qemu_thread_start (args=) at 
util/qemu-thread-posix.c:502
  #20 0x7549319c in start_thread () at /lib64/libpthread.so.0
  #21 0x753ba4af in clone () at /lib64/libc.so.6

  
  After some poking around, I think there's something overwriting dev->driver 
so this switch(dev->driver) statement falls through to abort(): 
https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304

  
  Here's why I think so:

  $ export QEMU_AUDIO_DRV=pa
  $ gdb /usr/bin/qemu-system-x86_64
  (gdb) b qpa_audio_init
  Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831.
  (gdb) b audio_get_pdo_in
  Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304.
  (gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name 
Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive 
file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive 
file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net 
nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor 
telnet:127.0.0.1:7043,server,nowait -pidfile workstation.pid -vga qxl -global 
qxl-vga.vgamem_mb=64 -device usb-ehci,id=ehci -device 
usb-host,vendorid=0x1390,productid=0x5454,bus=ehci.0 -device 
usb-host,vendorid=0x054c,bus=ehci.0 -device usb-tablet -device 
nec-usb-xhci,id=xhci -device 
usb-host,vendorid=0x10c4,productid=0x888e,bus=xhci.0

  Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init 
(dev=0x7161b6a0) at audio/paaudio.c:831
  (gdb) p (*dev)->driver
  $1 = AUDIODEV_DRIVER_PA
  (gdb) p/d 

[Bug 1833048] Re: Guest Agent get-fsinfo doesn't show ZFS volumes

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Guest Agent get-fsinfo doesn't show ZFS volumes

Status in QEMU:
  Expired

Bug description:
  Calling get-fsinfo on a virtual machine does not include ZFS
  (zfsonlinux, debian guest tested) volumes. Calling on a system with a
  single ZFS disk (ZFS as root fs) simply returns '[]', if other disks
  exist on the guest it only shows these.

  Expected behaviour: Show file system details like with other fs
  formats.

  Tried with debian stretch default qemu-guest-agent package and v4.0.0 from 
git, compiled locally - result is the same.
  Host is using QEMU 3.0.1, but that shouldn't matter, right?

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

[Bug 1851547] Re: qemu 4 crashes with this parameter attached -usb -device usb-host, hostbus=1, hostaddr=7 \

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu 4 crashes with this parameter attached -usb -device usb-
  host,hostbus=1,hostaddr=7 \

Status in QEMU:
  Expired

Bug description:
  Hello.

  qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to
  19.10 and qemu from 3 to 4,as you can see below. what can I do ?

  root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-
  OS-HSP2.sh

  > qemu-system-x86_64: /build/qemu-
  UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev !=
  NULL" non riuscita.

  ./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-
  system-x86_64 -enable-kvm -m 16000 -cpu
  Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-
  freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none
  -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device
  vfio-pci,host=01:00.1,bus=pcie.0 -device vfio-
  pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0
  -usb -device usb-host,hostbus=1,hostaddr=7 -drive
  if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive
  if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2
  -device ich9-ahci,id=sata -drive
  id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2'
  -device ide-hd,bus=sata.2,drive=Clover -device ide-
  hd,bus=sata.3,drive=InstallMedia -drive
  id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive
  id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-
  hd,bus=sata.4,drive=BsdHDD -netdev
  tap,id=net0,ifname=tap0,script=no,downscript=no -device
  e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio

  It seems that this line is not good anymore (it worked with qemu 3.x)
  :

  -usb -device usb-host,hostbus=1,hostaddr=7 \

  when I removed it,it works. But I need that. With what can I change it
  ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in
  that way also qemu will be upgraded from 3 to 4. These are the
  packages that I'm using :

  root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version
  QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9)

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

[Bug 1840250] Re: 'make -j1 docker-test-build' uses more than one job

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  'make -j1 docker-test-build' uses more than one job

Status in QEMU:
  Expired

Bug description:
  version: v4.1.0-rc5

  Run 'make -j1 docker-test-build', wait a few, various containers get
  instantiated.

  $ make -j1 docker-test-build 2>&1 > /dev/null

  On another terminal:

  $ docker ps
  CONTAINER IDIMAGECOMMAND  
CREATED STATUS
  62264a2d777aqemu:debian-mips-cross   "/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes
  80807c47d0dfqemu:debian-armel-cross  "/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes
  06027b5dfd4aqemu:debian-amd64"/var/tmp/qemu/run t…"   
10 minutes ago  Up 10 minutes

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

[Bug 1837347] Re: guest userspace process core dump after raspi2 kernel boot

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  guest userspace process core dump after raspi2 kernel boot

Status in QEMU:
  Expired

Bug description:
  Host info:
  ==
  x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site)

  Guest info:
  ===
  ARM7l, Raspbian OS off the main raspberry pi site

  QEMU command:
  =
  qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb 
bootpart/bcm2709-rpi-2-b.dtb -drive 
file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk 
console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio

  kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following
  commands:

  guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1
  > copy-out / bootpart/
  > quit

  Output:
  ===

  https://pastebin.com/fL1eXhV0

  References:
  ===
  
https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
  
https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/

  
  The core dump error can occur at both times, before logging in and after 
logging in, in this case I have given the output after logging in to show the 
initial processes running.

  Also please let me know if I using any kernel flags incorrectly

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

[Bug 1835729] Re: GTK display does not support host scale factor

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  GTK display does not support host scale factor

Status in QEMU:
  Expired

Bug description:
  In the GNOME desktop environment, for HiDPI displays there is support
  to upscale everything.

  This can be set in "System Settings -> Displays -> Scale".

  I believe this affects GDK in the same way as setting the "GDK_SCALE"
  environment variable does.

  When launching `qemu-system-x86_64 ... -display gtk`, this scale
  factor seems to get lost; the result is that the host window is
  upscaled and doubled in size, while the guest appears only in the
  bottom left corner of the UI.

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

[Bug 1851845] Re: Windows 10 panics with BlueIris

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Windows 10 panics with BlueIris

Status in QEMU:
  Expired

Bug description:
  Running Windows 10 64bit.  Starting BlueIris 64 bit causes Windows to
  panic with CPU type is set higher than Penryn or CPU type = host.

  I have been able to reproduce the same issue on Proxmox 4,5,6 as well
  as oVirt 3. and 4.

  Does not panic when CPU type is set to kvm64.

  
  pve-qemu-kvm/stable 4.0.1-4 amd64

   /usr/bin/kvm -id 102 -name win7-01 -chardev
  socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait -mon
  chardev=qmp,mode=control -chardev socket,id=qmp-
  event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-
  event,mode=control -pidfile /var/run/qemu-server/102.pid -daemonize
  -smbios type=1,uuid=3ec61114-c30c-4719-aa00-f3f05be22d48 -smp
  8,sockets=1,cores=8,maxcpus=8 -nodefaults -boot menu=on,strict=on
  ,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc
  unix:/var/run/qemu-server/102.vnc,password -no-hpet -cpu
  
penryn,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer,hv_ipi,enforce
  -m 12000 -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f
  -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device
  vmgenid,guid=50deb929-1974-4fd0-9ad3-71722149d568 -device piix3-usb-
  uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-
  tablet,id=tablet,bus=uhci.0,port=1 -device
  VGA,id=vga,bus=pci.0,addr=0x2 -chardev socket,path=/var/run/qemu-
  server/102.qga,server,nowait,id=qga0 -device virtio-
  serial,id=qga0,bus=pci.0,addr=0x8 -device
  virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -device
  virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-
  name=iqn.1993-08.org.debian:01:203582cea152 -drive if=none,id=drive-
  ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive
  =drive-ide2,id=ide2,bootindex=200 -drive
  file=/disk02/prox/images/102/vm-102-disk-0.raw,if=none,id=drive-
  virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on
  -device virtio-blk-pci,drive=drive-
  virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive
  file=/dev/disk/by-id/ata-WDC_WD80EMAZ-00WJTA0_7SGZLHYC-
  part1,if=none,id=drive-virtio1,cache=writeback,format=raw,aio=threads
  ,detect-zeroes=on -device virtio-blk-pci,drive=drive-
  virtio1,id=virtio1,bus=pci.0,addr=0xb -netdev
  type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-
  bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device
  virtio-net-
  
pci,mac=1e:be:cb:0b:6f:13,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300
  -netdev type=tap,id=net1,ifname=tap102i1,script=/var/lib/qemu-server
  /pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on
  -device virtio-net-
  
pci,mac=EA:76:56:16:2F:D7,netdev=net1,bus=pci.0,addr=0x13,id=net1,bootindex=301
  -rtc driftfix=slew,base=localtime -machine type=pc -global kvm-
  pit.lost_tick_policy=discard

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

[Bug 1847861] Re: Guest stuttering under high disk IO (virtio)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Guest stuttering under high disk IO (virtio)

Status in QEMU:
  Expired

Bug description:
  Performing io intensive tasks on virtualized Windows causes the system
  to visually stutter. I can often reproduce the problem by running fio
  on windows:

  fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1
  --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128
  --size=4G --readwrite=randread

  While the fio command is running, moving the mouse pointer will be be
  laggy. The stuttering does not appear with iodepth <= 32 . The
  stuttering also manifests while playing games, the music and video
  pauses for a fraction of second in a playable but disturbing way.

  Here are my system specs:

  Host OS: archlinux
  Guest OS: Windows 10 Enterprise
  qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with 
-march=native)
  CPU: AMD Ryzen Threadripper 1900X 8-Core Processor
  Huge Pages: vm.nr_hugepages=4128
  Disk: nvme type=raw, io=threads bus=virtio
  GPU (passthrough): Radeon RX 570

  Here are some fio test results on my windows guest:

  [size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508]
  [size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k]
  [size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k]
  [size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k]
  [size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER
  [size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER
  [size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER
  [size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as 
above, but no stuttering

  The min and avg values are the bandwidth values reported in KB/s by
  fio. You can see that, when the stuttering occurs, the stardard
  deviation is high and the minimum bandwidth is way below the average.

  Additional note: the bandwidth reported with `fio` on my linux host is
  about 2x the one reported in the guest:

  sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1
  --name=test --filename=/dev/nvme0n1 --bs=4k --iodepth=64 --size=512M
  --readwrite=randread

  read: IOPS=279k, BW=1092MiB/s (1145MB/s)(512MiB/469msec)

  Moreover, during the fio tests on the guest I've noticed that the CPU
  usage on the host is very high (around 450%) whereas on the guest is
  only 10%

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

[Bug 1843852] Re: QEMU does not express a dependency on perl-Test-Harness

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  QEMU does not express a dependency on perl-Test-Harness

Status in QEMU:
  Expired

Bug description:
  This is a minor thing; in Fedora you can install most of the developer
  dependencies by issuing something like `dnf builddep qemu-kvm` and
  this takes care of just about everything such that you can run
  ./configure and make.

  For "make check" though, configure doesn't catch that you'll need
  perl-Test-Harness; so it fails halfway through the check routine, and
  you'll see this:

  ```
  Can't locate TAP/Parser.pm in @INC (you may need to install the TAP::Parser 
module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 
/usr/share/perl5) at ./scripts/tap-driver.pl line 30.
  BEGIN failed--compilation aborted at ./scripts/tap-driver.pl line 30.
  make: *** [/home/jhuston/src/qemu/tests/Makefile.include:905: check-unit] 
Error 2
  ```

  I'm not sure how we should express this dependency; it shouldn't be a
  requirement for building, but it IS a dependency for testing. We
  probably ought not let users skip the qapi tests just because they
  don't have the perl requirement met.

  (And, separately, the Fedora package should list this as a builddep,
  but that's not an issue for here.)

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

[Bug 1838390] Re: vmx_write_mem: mmu_gva_to_gpa failed when using hvf

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  vmx_write_mem: mmu_gva_to_gpa failed when using hvf

Status in QEMU:
  Expired

Bug description:
  Installed qemu 4.0.0 by homebrew, used below commands:

  1. qemu-img create -f raw arch-vm.img 100G
  2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d 
-cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard 
-device virtio-mouse -device virtio-tablet -drive 
file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off 
-nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda 
-vga virtio

  Displayed bootloader menu successfully, select "Boot Arch Linux" then
  crashed with message: vmx_write_mem: mmu_gva_to_gpa 91953b54
  failed.

  Use tcg accelerator has no problem but very slow.

  See attachment for full crash report.

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

[Bug 1853429] Re: qemu-kvm on aarch64 attach volume failed when vm is booting

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-kvm on aarch64 attach volume failed when vm is booting

Status in QEMU:
  Expired

Bug description:
  I use libvirt and qemu-kvm on aarch64 platform to attach volume to a
  booting vm，when the system of vm has not boot up, attach volume will
  be failed, after vm system booting up, attach volume can be
  successful.

  libvirt: 4.5.0
  qemu : 2.12.0

  console log and qemu command of vm is in attachment.

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

[Bug 1850751] Re: kvm flag is not exposed by default

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  kvm flag is not exposed by default

Status in QEMU:
  Expired

Bug description:
  Hi I found that the kvm flags is not exposed by default, but according
  to the source code, it should be exposed by default when the CPU Model
  is a X86CPU.

  we have to specifically add "kvm=on" in QEMU custom cpu args like this to 
make VMWare Timing and KVM-Clock work:
  

  Also the libvirt can't expose kvm because of this (libvirt assumes the
  kvm flag is exposed by default in QEMU, so only "kvm hidden = 'true'"
  can be used to disable the kvm expose flag.

  I'm using QEMU 4.1.0 and libvirt 20190803.

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

[Bug 1846392] Re: VCPU shutdown request with HAX

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  VCPU shutdown request with HAX

Status in QEMU:
  Expired

Bug description:
  In most scenarios when turning on HAX, QEMU will exit, printing "VCPU
  shutdown request" to the console.

  This is on Windows 8.1 with Intel HAXM 7.5.2.
  QEMU's -version prints v4.1.0-11789-g013a2ecf4f-dirty .
  I've used an installer from qemu.weilnetz.de.
  The host CPU is an IvyBridge i5 (mobile).

  Some miscellaneous notes (you can skip them first):
  Win10-1709-PE_Custom.iso is a custom WinPE image I had meant to test using 
QEMU. It is likely broken and doesn't boot at all.
  [Stuck, etc.]: I had given that image almost 2h during which the circle of 
dots continued to spin. I don't know if it or QEMU did anything of interest at 
all during that period, but this might indicate long-term stability, sort of.
  Win10_1709_German_x32.iso: Stock Win10 1709 32bit ISO I got off a German tech 
website. I've waited for the install screen to appear.
  TinyCore_10-1.iso: TinyCore by Core Project. A 18MB graphical Linux 
distribution, pretty barren by default. I've generally opened Apps there, the 
package manager, then shut it down again.
  On the one marked [Fx stable], I've gotten Firefox 60.8.0 ESR and visited a 
couple of websites. (I don't know of any available program that would try to 
execute exotic CPU instructions in weird combinations to do a proper test.)
  Q64 is .\qemu-system-x86_64.exe , substituted for readability (shorter lines).

  
  Invocations that QEMU seemed to handle well (without the headline error):
  Q64 -machine q35 -accel hax
  Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso
  Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso -m 4096 [Stuck, etc.]
  Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 1920
  Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 256 [1]
  Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 512
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu max -serial 
file:\!S\QEMU_TCL_BUG.log [2]
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax [Fx stable, s.a.]
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Skylake-Client-IBRS
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Icelake-Client-v1
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Cascadelake-Server-v2
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Broadwell-v4
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu IvyBridge-IBRS
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu coreduo
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu pentium
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu base [3]
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu base [4]
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu pentium
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 [5]
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Broadwell-v4 [5]
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 [5]
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo

  
  Then, those that made it print "VCPU shutdown request" repeatedly and quit, 
immediately or after a couple of seconds at most, except where noted. I put an 
indication of the number of messages into curly braces.
  Q64 -machine q35,accel=hax -cpu max  {many}
  Q64 -machine q35,accel=hax -cdrom \!S\Win10-1709-PE_Custom.iso
  Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax  
{very many}
  Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax -cpu 
max  {very many}
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax  {just two}
  Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu max  {a couple}
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 -accel 
hax  {two}
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 -accel hax  
{two}
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu pentium -accel hax  
{three}
  Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo -accel hax  {a 
few}


  (I have rewritten a couple of commandlines to make them more uniform
  (changing the placement of parameters and using '-accel hax' instead
  of '-machine ...,accel=hax').)

  [1]: WinPE boot error, not enough RAM.
  [2]: Will cause a kernel BUG: "... \ login[892]: root login on 'tty1' \ BUG: 
unable to handle kernel paging request at 00010ffa \ ...". See attached file.
  [3]: Stuck after "Booting the kernel.", cursor blinks.
  [4]: Stuck at blinking console prompt, no input possible.
  [5]: According to the printout, TCG doesn't support a bunch of those 
processor's features that have been requested.

  PS: There 

[Bug 1854878] Re: Physical USB thumbdrive treated as read-only

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Physical USB thumbdrive treated as read-only

Status in QEMU:
  Expired

Bug description:
  So I have installed FreeDOS on my USB thumbdrive, by using Rufus.
  Everything goes as expected so far. That's good.

  When I run QEMU with this command line:
  qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1

  it of course is read-only, just like the resulting console message says:
  WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing 
guessed raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.

  
  So what I then did, was I ran QEMU with this command line:
  qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw

  As expected, the above mentioned console message no longer appears.
  However, beyond that, QEMU doesn't behave as it should regarding read-only 
status. When I try any operation that involves writing to the drive, it becomes 
quite clear that the drive is still read-only. Any writing operations to the 
drive result in FreeDOS giving me the error message:
  Error writing to drive C: DOS area: sector not found.

  The above situation is clearly a bug. QEMU should not be treating it
  as read-only once I specify format=raw.

  Note that drive C is how the guest OS refers to the USB thumbdrive
  (it's drive E in my host OS, and drive C in my host OS is the actual
  system drive).

  And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this 
command line, so that all changes would be written to a temporary snapshot file:
  qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot
  That last drive option "snapshot" tells QEMU to create a temporary snapshot 
file, and to write all changes to that. When I do that, all write operations 
are successful. So it seems that there is a bug in QEMU where it keeps 
read-only mode in place for a physical drive, even when format=raw is 
specified. Please fix this bug. Thanks in advance.

  Here's my current setup.
  Host OS: Windows 10 (64bit)
  Guest OS: FreeDOS
  QEMU version: 4.1.0

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

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu 4.1.0 - Corrupt guest filesystem after new vm install

Status in QEMU:
  Expired

Bug description:
  When I install a new vm with qemu 4.1.0 all the guest filesystems are
  corrupt. The first boot from the install dvd iso is ok and the
  installer work fine. But the guest system hangs after the installer
  finishes and I reboot the guest. I can see the grub boot menue but the
  system cannot load the initramfs.

  Testet with:
  - RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and 
/ partition)
  Guided install with the graphical installer, no lvm selected.
  - Debian Stable/Buster (Debian uses ext4 for / and /home partition)
  Guidet install with the graphical installer and default options.

  Used commandline to create the vm disk image:
  qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G

  Used qemu commandline for vm installation:
  #!/bin/sh
  # vmtest10 Installation
  #
  /usr/bin/qemu-system-x86_64  -cpu SandyBridge-IBRS \
  -soundhw hda \
  -M q35 \
  -k de \
  -vga qxl \
  -machine accel=kvm \
  -m 4096 \
  -display gtk \
  -drive 
file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom
 \
  -drive 
file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback
 \
  -boot once=d,menu=off \
  -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \
  -netdev bridge,br=br0,id=vlan0 \
  -rtc base=localtime \
  -name "vmtest10" \
  -usb -device usb-tablet \
  -spice disable-ticketing \
  -device virtio-serial-pci \
  -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \
  -chardev spicevmc,id=spicechannel0,name=vdagent $*

  Host OS:
  Archlinux (last updated at 10.10.2019)
  Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 
x86_64 GNU/Linux
  No libvirt in use.

  
  With qemu 4.0.0 it works fine without any errors.

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

[Bug 1851972] Re: pc-q35-4.1 and AMD Navi 5700/XT incompatible

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  pc-q35-4.1 and AMD Navi 5700/XT incompatible

Status in QEMU:
  Expired

Bug description:
  Hello,

  I am not sure if this qualifies as a "bug"; it is be more of an
  unknown issue with default settings. However, since the default value
  of q35 default_kernel_irqchip_split was changed seemingly due to
  similar user feedback, I thought this was important to share..

  AMD Navi 5700/XT vfio-pci passthrough seems incompatible with
  one/multiple settings in pc-q35-3.1 and higher. The workaround for me
  is that pc-q35-3.0 still works fine passing through the GPU and
  official drivers can load/install fine.

  The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest
  do work; the monitor displays the desktop in a 800x600 resolution and
  things are rendered fine.. so the basic functionality of the card
  seems fine with pc-q35-4.1.

  But attempting to use the official open source AMD driver with the
  card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on
  the Windows 1903 guest immediately during driver install.

  I do not see any errors in Qemu command output.. did not investigate
  other logs or KVM etc, because I am not sure what to look for or how
  to go about it. Also not sure which combination of the latest q35
  default settings are valid combinations to try either, because it
  seems that multiple things have changed related to pcie-root-port
  defaults and other machine options. I am happy to run tests and
  provide feedback if that helps identify the issue.

  I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host
  with AMD Navi reset pci quirk patch applied.

  My working Qemu command line is this:

  QEMU_AUDIO_DRV=pa \
  QEMU_PA_SERVER=/run/user/1000/pulse/native \
  /usr/bin/qemu-system-x86_64 \
  -name windows \
  -m 16g \
  -accel kvm \
  -machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \
  -blockdev 
node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \
  -blockdev 
node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \
  -boot menu=on \
  -global kvm-pit.lost_tick_policy=discard \
  -no-hpet \
  -rtc base=utc,clock=host,driftfix=slew \
  -cpu 
host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer
 \
  -smp sockets=1,cores=4,threads=1 \
  -nodefaults \
  -netdev bridge,br=br0,id=net0 \
  -device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \
  -device virtio-scsi-pci \
  -blockdev 
raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw
 \
  -device scsi-hd,drive=disk0,rotation_rate=1 \
  -blockdev 
raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw
 \
  -device scsi-hd,drive=disk1,rotation_rate=1 \
  -drive 
index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso
 \
  -drive 
index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso 
\
  -device ich9-intel-hda,addr=1b.0 \
  -device hda-output \
  -monitor stdio \
  -display none \
  -vga none \
  -device 
pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on
 \
  -device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \
  -device x3130-upstream,bus=pcierp0,id=pcieu0 \
  -device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \
  -device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \
  -device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \
  -device qemu-xhci,addr=1d.0 \
  -device usb-host,vendorid=0x258a,productid=0x0001 \
  -device usb-host,vendorid=0x1bcf,productid=0x0005 ;

  Thank you!

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

[Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  Expired

Bug description:
  I already send this email to qemu-disc...@nongnu.org , but I can't see
  it arriving in archives, so here  is copy.

  Hello, all!

  I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live 
cd/dvd.
  Usually guests (with various self-compiled kernels and X stack with kde3 on 
top of them)
  boot up normally, but if I left them to run in GUI mode for few hours - qemu 
process on host
  started to eat more and more cpu for itself - more notiecable if I set host 
cpu to lowest possible
  frequency via trayfreq applet (1400Mhz in my case).

  Boot line a bit complicated, but I really prefer to have sound and usb inside 
VM.
  qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm 
-soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm

  rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but 
apparently not helping.
  After just 3 hours of uptime (copied line from 'top' on host)

  31943 guest 20   0 2412m 791m  38m R   51  6.7  66:36.51 qemu-
  system-i38

  I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card 
has not very big amount of VRAM - only 384Mb.
  May be this limitation is playing some role .. but 'end-user' result was 
after 1-2 day of guest uptime I run into completely frozen guest 
  (may be when qemu was hitting 100 one core usage on host some internal timer 
just made guest kernel too upset/froze?
   I was sleeping or doing other things on host  for all this time, with VM 
just supposedly running at another virtual desktop - 
  in KDE3 + built-in compositor )

  I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users 
of other distros (I use self-re-compiled Slackware)
  actually can see same problem?

  qemu-system-i386 --version
  QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty)
  but I saw same behavior for quite some time .. just never reported it in hope 
it will go away.

  cat /proc/cpuinfo
  processor   : 0
  vendor_id   : AuthenticAMD
  cpu family  : 21
  model   : 2
  model name  : AMD FX(tm)-4300 Quad-Core Processor
  stepping: 0
  microcode   : 0x6000852
  cpu MHz : 1399.977
  cache size  : 2048 KB
  physical id : 0
  siblings: 4
  core id : 0
  cpu cores   : 2
  apicid  : 16
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 13
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
  bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
spec_store_bypass
  bogomips: 7600.06
  TLB size: 1536 4K pages
  clflush size: 64
  cache_alignment : 64
  address sizes   : 48 bits physical, 48 bits virtual
  power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

  [and 3x more of the same, for 3 remaining cores]

  Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too.
  This might be 32-bit host problem. But may be just no-one tried to run qemu 
with GUI guest for literaly days?

  Host kernel is
   uname -a
  Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD 
FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux

  I was trying newish 5.3.2 but my compilation was not as stable as this one 
  (I tend to change few things, like max cpu count, preemption mode, numa 
support  
  for more distribution-like, yet most stable  and performant for me kernel)

  Kernel world is moving fast, so I'll try to recompile new 5.3.x too
  

  
  I guess I  should provide perf/profiler output, but for  this I need to 
recompile qemu. 
  I'll try to come back with more details soon.

  Thanks for your attention and possible feedback!

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

[Bug 1845185] Re: Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe) statically with MSYS64 on Windows because intl and iconv libs are not loaded

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe)
  statically with MSYS64 on Windows because intl and iconv libs are not
  loaded

Status in QEMU:
  Expired

Bug description:
  Using MSYS2 and mingw32 instructions from
  https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2, I could not
  statically build the qemu-utils using the latest qemu master branch.

  Steps to reproduce the issue:
  1. Install MSYS2 on a Windows 10 x64 box
  2. Install required mingw64 toolchain: pacman -S base-devel 
mingw-w64-x86_64-toolchain git python mingw-w64-x86_64-glib2 
mingw64/mingw-w64-x86_64-gtk3 mingw64/mingw-w64-x86_64-SDL2
  3. clone qemu
  4. Run configure for static build for the tools only
    ./configure --disable-user --disable-system --disable-docs --enable-tools  
--disable-guest-agent --disable-capstone --disable-sheepdog --enable-debug 
--static
    # I had to remove sheepdog, capstone and guest agent because other errors 
popped out, but let's not go in the rabbit hole.
  5. Run 'make -j'. the following errors appeared, signaling that intl lib is 
not loaded. If I add intl lib, iconv lib needs to be loaded too.

  make: *** [/home/ader1990/qemu/rules.mak:124: qemu-img.exe] Error 1
  make: *** Waiting for unfinished jobs
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1522): 
undefined reference to `libintl_sprintf'
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x154f): 
undefined reference to `libintl_sprintf'
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x157e): 
undefined reference to `libintl_sprintf'
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15ad): 
undefined reference to `libintl_sprintf'
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15dc): 
undefined reference to `libintl_sprintf'
  C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1622): more 
undefined references to `libintl_sprintf' follow
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x43): undefined 
reference to `libintl_textdomain'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x52): undefined 
reference to `libintl_gettext'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x203): undefined 
reference to `libintl_bindtextdomain'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x21e): undefined 
reference to `libintl_bind_textdomain_codeset'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x2c1): undefined 
reference to `libintl_dgettext'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x4e1): undefined 
reference to `libintl_dcgettext'
  C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x53a): undefined 
reference to `libintl_dngettext'

  Patch to fix the issue (added intl and iconv to the libs):

  diff --git a/configure b/configure
  index 30aad233d1..e2ab8ef026 100755
  --- a/configure
  +++ b/configure
  @@ -920,7 +920,7 @@ if test "$mingw32" = "yes" ; then
     DSOSUF=".dll"
     # MinGW needs -mthreads for TLS and macro _MT.
     QEMU_CFLAGS="-mthreads $QEMU_CFLAGS"
  -  LIBS="-lwinmm -lws2_32 -liphlpapi $LIBS"
  +  LIBS="-lwinmm -lws2_32 -liphlpapi -lintl -liconv $LIBS"
     write_c_skeleton;
     if compile_prog "" "-liberty" ; then
   LIBS="-liberty $LIBS"

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

[Bug 1855535] Re: Connection reset by peer when using port fwd

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Connection reset by peer when using port fwd

Status in QEMU:
  Expired

Bug description:
  $ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp 
cores=8 -serial mon:stdio -nographic \
  -drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \
  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
  -cdrom /qemu/aix72.iso \
  -prom-env boot-command='boot disk:' \
  -name ctsprod -k es \
  -netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:-:22 \
  -device virtio-net-pci,netdev=netdev0 \
  -netdev bridge,id=hostnet0,br=virbr0 \
  -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \
  -device virtio-net,netdev=vmnic -netdev 
tap,id=vmnic,ifname=vnet0,script=no,downscript=no \
  -monitor telnet:127.0.0.1:5801,server,nowait,nodelay

  
  $ ssh -p  root@127.0.0.1 -v

  OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug1: Connecting to 127.0.0.1 [127.0.0.1] port .
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519 type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
  ssh_exchange_identification: read: Connection reset by peer

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

[Bug 1853898] Re: qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(>queue)' failed.

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion
  `QTAILQ_EMPTY(>queue)' failed.

Status in QEMU:
  Expired

Bug description:
  While experimenting with blkdebug I can consistently hit this
  assertion in lsi53c895a.c.

  Using locally built from master, commit:
  2061735ff09f9d5e67c501a96227b470e7de69b1

  Steps to reproduce

  $ qemu-img create -f raw empty.raw 8G
  $ sudo losetup -f --show empty.raw
  $ sudo mkfs.ext3 /dev/loop0
  $ sudo losetup -D

  $ cat blkdebug.conf 
  [inject-error]
  event = "read_aio"
  errno = "5"

  $ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic
  user,ipv6=off,model=e1000,hostfwd=tcp::-:22,net=172.16.0.0/255.255.255.0
  -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678
  -drive
  if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw
  -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk

  Initiate install from cdrom ISO image results in:

  qemu-system-x86_64: 
/builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: 
Assertion `QTAILQ_EMPTY(>queue)' failed.
  Aborted (core dumped)

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

[Bug 1848901] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
  (28)

Status in QEMU:
  Expired

Bug description:
  => QEMU process has stopped, return code: -6

  Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
  2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
  'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
  /7725cdea-5e66-4777-b4dd-
  c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
  -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
  telnet:127.0.0.1:5000,server,nowait -monitor
  tcp:127.0.0.1:44629,server,nowait -net none -device
  e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
  socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
  e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
  socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
  e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
  socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
  e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
  socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
  e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
  socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
  e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
  socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
  e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
  socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
  e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
  socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
  -nographic

   
  Execution log:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

  and then it just closes...


  [deemon@Zen ~]$ coredumpctl info 8638
 PID: 8638 (qemu-system-x86)
 UID: 1000 (deemon)
 GID: 1000 (deemon)
  Signal: 6 (ABRT)
   Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 
file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu>
  Executable: /usr/bin/qemu-system-x86_64
   Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
   Slice: user-1000.slice
 Session: 2
   Owner UID: 1000 (deemon)
 Boot ID: cd30f69a8d194359a31889dc7b6b026c
  Machine ID: d0a2d74a5cd9430797d902f5237c448d
Hostname: Zen
 Storage: 
/var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4
 (truncated)
 Message: Process 8638 (qemu-system-x86) of user 1000 dumped core.
  
  Stack trace of thread 8642:
  #0  0x7f1a33609f25 n/a (n/a)

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

[Bug 1870911] Re: QEMU Crashes on Launch, Windows

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  QEMU Crashes on Launch, Windows

Status in QEMU:
  Expired

Bug description:
  Hi,

  I an having no issues up to (and including) v5.0.0-rc0, but when I
  move to rc1 ... it won't even execute in Windows. If I just try to,
  for example, run

  qemu-system-x86_64.exe --version

  No output, it just exits. This seems to be new with this version.

  Thanks!

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

[Bug 1850378] Re: RISC-V unreliable IPIs

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  RISC-V unreliable IPIs

Status in QEMU:
  Expired

Bug description:
  I am working on a project with custom inter processor interrupts (IPIs) on 
the RISC-V virt machine.
  After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue 
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU 
hotplug feature.

  However, if I try to use IPIs for communication between two cores, the
  wfi instruction behaves strangely. Either it does not return, or it
  returns on timer interrupts, even though they are disabled. The code,
  I use on one core to wait for an interrupt is the following.

   csr_clear(sie, SIE_SEIE | SIE_STIE);
   do {
    wait_for_interrupt();
    sipval = csr_read(sip);
    sieval = csr_read(sie);
    scauseval = csr_read(scause) & 0xFF;
   /* only break if wfi returns for an software interrupt */
   } while ((sipval & sieval) == 0 && scauseval != 1);
   csr_set(sie, SIE_SEIE | SIE_STIE);

  Since the resulting sequence does not seem to be deterministic, my
  guess is, that it has something to do with the communication of qemu's
  threads for the different cores.

  Update:
  The exact same setup works fine in spike (the actual sim, not the qemu 
board), which might give a hint, that it is related to the interrupt controller 
implementation.

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

[Bug 1854910] Re: Support VHDX differencing images (ie images with backing)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Support VHDX differencing images (ie images with backing)

Status in QEMU:
  Expired

Bug description:
  The qemu vhdx driver does not support type 2 (differencing) vhdx
  images (usually stored with file extension .avhdx). This means that
  any hyperv images with snapshots are not supported by qemu-img. It
  would be great to be able to convert to a new qcow image from a
  backing + set of differencing images from hyperv, and/or convert an
  individual differencing vhdx image to a qcow2 image with a backing
  file specified.

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

[Bug 1853123] Re: Memory synchronization error between kvm and target, e1000(dpdk)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Memory synchronization error between kvm and target, e1000(dpdk)

Status in QEMU:
  Expired

Bug description:
  Hi folks.

  I use linux with dpdk drivers on the target system, and e1000 emulation 
device with tap interface for host. I use kvm for accelerate.
  Version qemu 4.0.94 and master (Nov 12 10:14:33 2019)
  Version dpdk stable-17.11.4
  Version linux host 4.15.0-66-generic (ubuntu 18.04)

  I type command "ping  -f" and wait about 1-2 minutes.
  Network subsystem freezes.

  For receive the eth pack from host system (tap interface) to host
  system the e1000 using ring buffer.

  The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH 
(Ring Device Head).
  (file hw/net/e1000.c function e1000_receive_iov() )

  The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if 
flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring 
Device Tail).
  (source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() )

  I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but
  sometimes rxdp->status remains equal to 7. On the next cycle, this
  this buffer is read, RDT moved to far. RDH becomes equal RDT and
  network is freezes.

  If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset 
E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine.
  If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid.

  This only appears on kvm. If I use tcg all works fine.

  I trying set watchpoint for memory on the qemu (for tcg), and see,
  that for one package cycle of set/unse STAT_DD repeated once.

  I trying set watchpoint for memory on the qemu (for kvm), and see,
  that rxdp->status changed to 0(unset) only once, but is changes
  immediately before set flag.

  
  Please help me with advice on how to catch and fix this error. 
  Theoretically, it would help me to trace the memory access when writing to 
E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I 
have no idea how this can be done.

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

[Bug 1854738] Re: ppc doesn't support for mttcg but ppc64 supported

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  ppc doesn't support for mttcg  but ppc64 supported

Status in QEMU:
  Expired

Bug description:
  Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for 
support
  ```
ppc)
  gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
;;
ppc64)
  TARGET_BASE_ARCH=ppc
  TARGET_ABI_DIR=ppc
  mttcg=yes
  gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml power-vsx.xml"
;;
ppc64le)
  TARGET_ARCH=ppc64
  TARGET_BASE_ARCH=ppc
  TARGET_ABI_DIR=ppc
  mttcg=yes
  gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml power-vsx.xml"
;;
ppc64abi32)
  TARGET_ARCH=ppc64
  TARGET_BASE_ARCH=ppc
  TARGET_ABI_DIR=ppc
  echo "TARGET_ABI32=y" >> $config_target_mak
  gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml power-vsx.xml"
;;
  ```

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

[Bug 1867601] Re: test-char not concurrent with unix socket

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  test-char not concurrent with unix socket

Status in QEMU:
  Expired

Bug description:
  'make check-unit' might fail when running multiple tests in parallel.

  Apparently occurred on OSX CI:
  https://travis-ci.org/github/philmd/qemu/jobs/662357430

  Guess is same unix path used:

  static SocketAddress unixaddr = {
  .type = SOCKET_ADDRESS_TYPE_UNIX,
  .u.q_unix.path = (char *)"test-char.sock",
  };

  Note, other tests in this file use g_dir_make_tmp().

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

[PATCH 1/1] migration: Unregister yank if migration setup fails

[Leonardo Bras]

Currently, if a qemu instance is started with "-incoming defer" and
an incorect parameter is passed to "migrate_incoming", it will print the
expected error and reply with "duplicate yank instance" for any upcoming
"migrate_incoming" command.

This renders current qemu process unusable, and requires a new qemu
process to be started before accepting a migration.

This is caused by a yank_register_instance() that happens in
qemu_start_incoming_migration() but is never reverted if any error
happens.

Solves this by unregistering the instance if anything goes wrong
in the function, allowing a new "migrate_incoming" command to be
accepted.

Fixes: b5eea99ec2f ("migration: Add yank feature", 2021-01-13)
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1974366
Signed-off-by: Leonardo Bras 

---
 migration/migration.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 4228635d18..ddcf9e1868 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -474,9 +474,13 @@ static void qemu_start_incoming_migration(const char *uri, 
Error **errp)
 } else if (strstart(uri, "fd:", )) {
 fd_start_incoming_migration(p, errp);
 } else {
-yank_unregister_instance(MIGRATION_YANK_INSTANCE);
 error_setg(errp, "unknown migration protocol: %s", uri);
 }
+
+if (*errp) {
+yank_unregister_instance(MIGRATION_YANK_INSTANCE);
+}
+
 }
 
 static void process_incoming_migration_bh(void *opaque)
-- 
2.32.0

Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd.

[Yuri Benditovich]

On Mon, Jun 21, 2021 at 12:20 PM Jason Wang  wrote:
>
>
> 在 2021/6/19 上午4:03, Andrew Melnichenko 写道:
> > Hi Jason,
> > I've checked "kernel.unprivileged_bpf_disabled=0" on Fedora,  Ubuntu,
> > and Debian - no need permissions to update BPF maps.
>
>
> How about RHEL :) ?

If I'm not mistaken, the RHEL releases do not use modern kernels yet
(for BPF we need 5.8+).
So this will be (probably) relevant for RHEL 9. Please correct me if I'm wrong.


>
> Thanks
>
>
> >
> > On Wed, Jun 16, 2021 at 1:18 AM Andrew Melnichenko  > > wrote:
> >
> > Hi,
> >
> > I may miss something.
> >
> > But RSS requires to update the map. This won't work if you
> > don't grant
> > any permission to qemu.
> >
> > Thanks
> >
> >
> > Partly - with "kernel.unprivileged_bpf_disabled=0" capabilities is
> > not required to update maps.
> > With "kernel.unprivileged_bpf_disabled=1" - setting maps will
> > fail(without CAP_BPF) and "in-qemu" RSS will be used.
> >
> > On Tue, Jun 15, 2021 at 12:13 PM Jason Wang  > > wrote:
> >
> >
> > 在 2021/6/12 上午12:49, Andrew Melnichenko 写道:
> > > Hi,
> > >
> > > So I think the series is for unprivileged_bpf disabled.
> > If I'm not
> > > wrong, I guess the policy is to grant CAP_BPF but do
> > fine grain
> > > checks
> > > via LSM.
> > >
> > >
> > > The main idea is to run eBPF RSS with qemu without any
> > permission.
> > > Libvirt should handle everything and pass proper eBPF file
> > descriptors.
> > > For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations)
> > > also required, and in the future may be other permissions.
> >
> >
> > I may miss something.
> >
> > But RSS requires to update the map. This won't work if you
> > don't grant
> > any permission to qemu.
> >
> > Thanks
> >
> >
> > >
> > > I'm not sure this is the best. We have several examples
> > that let
> > > libvirt
> > > to involve. Examples:
> > >
> > > 1) create TAP device (and the TUN_SETIFF)
> > >
> > > 2) open vhost devices
> > >
> > >
> > > Technically TAP/vhost not related to a particular qemu
> > emulator. So common
> > > TAP creation should fit any modern qemu. eBPF fds(program
> > and maps) should
> > > suit the interface for current qemu, g.e. some qemu builds
> > may have
> > > different map
> > > structures or their count. It's necessary that the qemu got fds
> > > prepared by the helper
> > > that was built with the qemu.
> > >
> > > I think we need an example on the detail steps for how
> > libvirt is
> > > expected to use this.
> > >
> > >
> > > The simplified workflow looks like this:
> > >
> > >  1. Libvirt got "emulator" from domain document.
> > >  2. Libvirt queries for qemu capabilities.
> > >  3. One of the capabilities is "qemu-ebpf-rss-helper"
> > path(if present).
> > >  4. On NIC preparation Libvirt checks for virtio-net + rss
> > configurations.
> > >  5. If required, the "qemu-ebpf-rss-helper" called and fds are
> > > received through unix fd.
> > >  6. Those fds are for eBPF RSS, which passed to child
> > process - qemu.
> > >  7. Qemu launched with virtio-net-pci property "rss" and
> > "ebpf_rss_fds".
> > >
> > >
> > > On Fri, Jun 11, 2021 at 8:36 AM Jason Wang
> > mailto:jasow...@redhat.com>
> > > >>
> > wrote:
> > >
> > >
> > > 在 2021/6/10 下午2:55, Yuri Benditovich 写道:
> > > > On Thu, Jun 10, 2021 at 9:41 AM Jason
> > Wangmailto:jasow...@redhat.com>
> > >  > >> wrote:
> > > >> 在 2021/6/9 下午6:04, Andrew Melnychenko 写道:
> > > >>> Libvirt usually launches qemu with strict permissions.
> > > >>> To enable eBPF RSS steering, qemu-ebpf-rss-helper
> > was added.
> > > >> A silly question:
> > > >>
> > > >> Kernel had the following permission checks in bpf
> > syscall:
> > > >>
> > > >>  if (sysctl_unprivileged_bpf_disabled &&
> > !bpf_capable())
> > > >>   return -EPERM;
> > > >> ...
> > > >>
> > > >>   err = security_bpf(cmd, , size);
> > > >>   if (err < 0)
> > > >>   return 

[PATCH] coreaudio: Lock only the buffer

[Akihiko Odaki]

On macOS 11.3.1, Core Audio calls AudioDeviceIOProc after calling an
internal function named HALB_Mutex::Lock(), which locks a mutex in
HALB_IOThread::Entry(void*). HALB_Mutex::Lock() is also called in
AudioObjectGetPropertyData, which is called by coreaudio driver.
Therefore, a deadlock will occur if coreaudio driver calls
AudioObjectGetPropertyData while holding a lock for a mutex and tries
to lock the same mutex in AudioDeviceIOProc.

audioDeviceIOProc, which implements AudioDeviceIOProc in coreaudio
driver, requires an exclusive access for the device configuration and
the buffer. Fortunately, a mutex is necessary only for the buffer in
audioDeviceIOProc because a change for the device configuration occurs
only before setting up AudioDeviceIOProc or after stopping the playback
with AudioDeviceStop.

With this change, the mutex owned by the driver will only be used for
the buffer, and the device configuration change will be protected with
the implicit iothread mutex.

Signed-off-by: Akihiko Odaki 
---
 audio/coreaudio.c | 59 +++
 1 file changed, 13 insertions(+), 46 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 578ec9b8b2e..c8d9f01d275 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -26,6 +26,7 @@
 #include 
 #include /* pthread_X */
 
+#include "qemu/main-loop.h"
 #include "qemu/module.h"
 #include "audio.h"
 
@@ -551,9 +552,7 @@ static OSStatus handle_voice_change(
 OSStatus status;
 coreaudioVoiceOut *core = in_client_data;
 
-if (coreaudio_lock(core, __func__)) {
-abort();
-}
+qemu_mutex_lock_iothread();
 
 if (core->outputDeviceID) {
 fini_out_device(core);
@@ -564,7 +563,7 @@ static OSStatus handle_voice_change(
 update_device_playback_state(core);
 }
 
-coreaudio_unlock (core, __func__);
+qemu_mutex_unlock_iothread();
 return status;
 }
 
@@ -582,11 +581,7 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct 
audsettings *as,
 err = pthread_mutex_init(>mutex, NULL);
 if (err) {
 dolog("Could not create mutex\nReason: %s\n", strerror (err));
-goto mutex_error;
-}
-
-if (coreaudio_lock(core, __func__)) {
-goto lock_error;
+return -1;
 }
 
 obt_as = *as;
@@ -606,37 +601,21 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct 
audsettings *as,
 if (status != kAudioHardwareNoError) {
 coreaudio_playback_logerr (status,
"Could not listen to voice property 
change\n");
-goto listener_error;
+return -1;
 }
 
 if (init_out_device(core)) {
-goto device_error;
+status = AudioObjectRemovePropertyListener(kAudioObjectSystemObject,
+   _addr,
+   handle_voice_change,
+   core);
+if (status != kAudioHardwareNoError) {
+coreaudio_playback_logerr(status,
+  "Could not remove voice property change 
listener\n");
+}
 }
 
-coreaudio_unlock(core, __func__);
 return 0;
-
-device_error:
-status = AudioObjectRemovePropertyListener(kAudioObjectSystemObject,
-   _addr,
-   handle_voice_change,
-   core);
-if (status != kAudioHardwareNoError) {
-coreaudio_playback_logerr(status,
-  "Could not remove voice property change 
listener\n");
-}
-
-listener_error:
-coreaudio_unlock(core, __func__);
-
-lock_error:
-err = pthread_mutex_destroy(>mutex);
-if (err) {
-dolog("Could not destroy mutex\nReason: %s\n", strerror (err));
-}
-
-mutex_error:
-return -1;
 }
 
 static void coreaudio_fini_out (HWVoiceOut *hw)
@@ -645,10 +624,6 @@ static void coreaudio_fini_out (HWVoiceOut *hw)
 int err;
 coreaudioVoiceOut *core = (coreaudioVoiceOut *) hw;
 
-if (coreaudio_lock(core, __func__)) {
-abort();
-}
-
 status = AudioObjectRemovePropertyListener(kAudioObjectSystemObject,
_addr,
handle_voice_change,
@@ -659,8 +634,6 @@ static void coreaudio_fini_out (HWVoiceOut *hw)
 
 fini_out_device(core);
 
-coreaudio_unlock(core, __func__);
-
 /* destroy mutex */
 err = pthread_mutex_destroy(>mutex);
 if (err) {
@@ -672,14 +645,8 @@ static void coreaudio_enable_out(HWVoiceOut *hw, bool 
enable)
 {
 coreaudioVoiceOut *core = (coreaudioVoiceOut *) hw;
 
-if (coreaudio_lock(core, __func__)) {
-abort();
-}
-
 core->enabled = enable;
 update_device_playback_state(core);
-
-coreaudio_unlock(core, __func__);
 }
 
 static void *coreaudio_audio_init(Audiodev *dev)

RE: Denormal input handling

[Michael Morrell]

Richard,

I was under the mistaken impression that your changes in this area (splitting 
float_flag_input_denormal into 2 flags) were already checked in, but I see now 
that is not the case.  I should probably wait until that is done before I try 
to claim there are additional issues here.

Michael

-Original Message-
From: Richard Henderson  
Sent: Monday, June 21, 2021 4:30 PM
To: Michael Morrell ; qemu-devel@nongnu.org
Subject: Re: Denormal input handling

On 6/21/21 4:13 PM, Michael Morrell wrote:
> I have another couple of thoughts around input denormal handling.
> 
> The first is straightforward.  I noticed that the Aarch64 port doesn't 
> report input denormals (I could not find any code which sets the IDC 
> bit in the FPSR).  I found code in the arm (not aarch64) port that 
> sets other bits like IXC, but nothing for IDC.   Is that simply because no 
> one has bothered to add this support?

It's because we failed to use symbolic constants.  See 
vfp_exceptbits_from_host.  Which
*is* used for both aarch64 and arm.


> The second concerns support for cases where multiple exception conditions 
> occur.   I had 
> originally thought that denormal input handling would be orthogonal to 
> everything else and 
> so a case like "sNaN  + denorm" would set both the invalid and input denormal 
> flags or 
> "denorm / 0" would set both idivde by zero and input denormal, but I don't 
> think that is 
> true for at least some architectures.  Perhaps some specialization is needed 
> here?

If you've got a specific example, we can look at it.  There's no point adding 
specialization that isn't going to be used.


r~

Re: [PATCH v2 00/29] tcg: bswap improvements

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20210621231849.1871164-1-richard.hender...@linaro.org/



Hi,

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

Type: series
Message-id: 20210621231849.1871164-1-richard.hender...@linaro.org
Subject: [PATCH v2 00/29] tcg: bswap improvements

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/20210621231849.1871164-1-richard.hender...@linaro.org -> 
patchew/20210621231849.1871164-1-richard.hender...@linaro.org
Switched to a new branch 'test'
8a1ce95 tcg/riscv: Remove MO_BSWAP handling
042d928 tcg/aarch64: Unset TCG_TARGET_HAS_MEMORY_BSWAP
b12d261 tcg/arm: Unset TCG_TARGET_HAS_MEMORY_BSWAP
a72e94c target/mips: Fix gen_mxu_s32ldd_s32lddr
8c44e92 target/sh4: Improve swap.b translation
5def832 target/i386: Improve bswap translation
c558d58 target/arm: Improve REVSH
465157c target/arm: Improve vector REV
1fbd37e target/arm: Improve REV32
c0a1731 tcg: Make use of bswap flags in tcg_gen_qemu_st_*
446bceb tcg: Make use of bswap flags in tcg_gen_qemu_ld_*
6001384 tcg: Add flags argument to tcg_gen_bswap16_*, tcg_gen_bswap32_i64
a38add9 tcg: Handle new bswap flags during optimize
8152e2f tcg/tci: Support bswap flags
ed16867 tcg/mips: Support bswap flags in tcg_out_bswap32
1c402bf tcg/mips: Support bswap flags in tcg_out_bswap16
a21ddba tcg/s390: Support bswap flags
4c9ee2c tcg/ppc: Use power10 byte-reverse instructions
258cd29 tcg/ppc: Support bswap flags
dda8631 tcg/ppc: Split out tcg_out_bswap64
cced49b tcg/ppc: Split out tcg_out_bswap32
248ebec tcg/ppc: Split out tcg_out_bswap16
7d61b03 tcg/ppc: Split out tcg_out_sari{32,64}
69f510f tcg/ppc: Split out tcg_out_ext{8,16,32}s
fd998ad tcg/arm: Support bswap flags
2bf67ce tcg/aarch64: Support bswap flags
b14d4b1 tcg/aarch64: Merge tcg_out_rev{16,32,64}
47f04bc tcg/i386: Support bswap flags
a013bcf tcg: Add flags argument to bswap opcodes

=== OUTPUT BEGIN ===
1/29 Checking commit a013bcf9920f (tcg: Add flags argument to bswap opcodes)
2/29 Checking commit 47f04bcfbd3c (tcg/i386: Support bswap flags)
3/29 Checking commit b14d4b1a15d3 (tcg/aarch64: Merge tcg_out_rev{16,32,64})
4/29 Checking commit 2bf67ce46f28 (tcg/aarch64: Support bswap flags)
5/29 Checking commit fd998ad55098 (tcg/arm: Support bswap flags)
6/29 Checking commit 69f510fc9ccf (tcg/ppc: Split out tcg_out_ext{8,16,32}s)
7/29 Checking commit 7d61b03fe7f7 (tcg/ppc: Split out tcg_out_sari{32,64})
8/29 Checking commit 248ebecd716e (tcg/ppc: Split out tcg_out_bswap16)
9/29 Checking commit cced49b22079 (tcg/ppc: Split out tcg_out_bswap32)
10/29 Checking commit dda86314b2df (tcg/ppc: Split out tcg_out_bswap64)
11/29 Checking commit 258cd29045b2 (tcg/ppc: Support bswap flags)
12/29 Checking commit 4c9ee2ce7bfe (tcg/ppc: Use power10 byte-reverse 
instructions)
13/29 Checking commit a21ddba7adfd (tcg/s390: Support bswap flags)
14/29 Checking commit 1c402bf4ea32 (tcg/mips: Support bswap flags in 
tcg_out_bswap16)
15/29 Checking commit ed16867a8514 (tcg/mips: Support bswap flags in 
tcg_out_bswap32)
16/29 Checking commit 8152e2fbe20b (tcg/tci: Support bswap flags)
17/29 Checking commit a38add98a8cd (tcg: Handle new bswap flags during optimize)
ERROR: spaces required around that ':' (ctx:VxE)
#41: FILE: tcg/optimize.c:1033:
+CASE_OP_32_64(bswap16):
   ^

ERROR: spaces required around that ':' (ctx:VxE)
#94: FILE: tcg/optimize.c:1188:
+CASE_OP_32_64(bswap16):
   ^

ERROR: spaces required around that ':' (ctx:VxE)
#95: FILE: tcg/optimize.c:1189:
+CASE_OP_32_64(bswap32):
   ^

total: 3 errors, 0 warnings, 82 lines checked

Patch 17/29 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

18/29 Checking commit 6001384c5d55 (tcg: Add flags argument to 
tcg_gen_bswap16_*, tcg_gen_bswap32_i64)
ERROR: code indent should never use tabs
#165: FILE: target/sh4/translate.c:680:
+^Itcg_gen_bswap16_i32(low, low, TCG_BSWAP_IZ | TCG_BSWAP_OZ);$

total: 1 errors, 0 warnings, 296 lines checked

Patch 18/29 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

19/29 Checking commit 446bcebe129b (tcg: Make use of bswap flags in 
tcg_gen_qemu_ld_*)
20/29 Checking commit c0a1731ecfa5 (tcg: Make use of bswap flags in 
tcg_gen_qemu_st_*)
21/29 Checking commit 1fbd37ebe67c (target/arm: Improve REV32)
22/29 Checking commit 465157cd1fae (target/arm: Improve vector REV)
23/29 Checking commit c558d5861f46 (target/arm: Improve REVSH)
24/29 Checking 

Re: [PATCH v2 02/11] target/cris: Replace DISAS_TB_JUMP with DISAS_NORETURN

[Richard Henderson]

On 6/21/21 1:01 PM, Philippe Mathieu-Daudé wrote:

On 6/20/21 11:32 PM, Richard Henderson wrote:

The only semantic of DISAS_TB_JUMP is that we've done goto_tb,
which is the same as DISAS_NORETURN -- we've exited the tb.

Signed-off-by: Richard Henderson 
---
  target/cris/translate.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/target/cris/translate.c b/target/cris/translate.c
index bed7a7ed10..2ff4319dd1 100644
--- a/target/cris/translate.c
+++ b/target/cris/translate.c
@@ -55,7 +55,6 @@
  /* is_jmp field values */
  #define DISAS_JUMPDISAS_TARGET_0 /* only pc was modified dynamically */
  #define DISAS_UPDATE  DISAS_TARGET_1 /* cpu state was modified dynamically */
-#define DISAS_TB_JUMP DISAS_TARGET_2 /* only pc was modified statically */
  #define DISAS_SWI DISAS_TARGET_3


Can we #define DISAS_SWI DISAS_TARGET_2 in the same commit?


No point.  It goes away in patch 4.


r~

RE: Denormal input handling

[Michael Morrell]

Thanks for pointing me to vfp_exceptbits_from_host.  I see it setting bit 7 if 
flag_input_denormal is set, but it does not seem to work.   I never see that 
bit set.

As for the specialization, perhaps we don't need it if all architectures are 
the same, but the current code doesn't match any architecture I'm aware of.  I 
gave the example of "sNaN + denorm".   The HW will not set the "input denormal" 
flag, but qemu will.

If you want to see my test code, I can send that.

   Michael

-Original Message-
From: Richard Henderson  
Sent: Monday, June 21, 2021 4:30 PM
To: Michael Morrell ; qemu-devel@nongnu.org
Subject: Re: Denormal input handling

On 6/21/21 4:13 PM, Michael Morrell wrote:
> I have another couple of thoughts around input denormal handling.
> 
> The first is straightforward.  I noticed that the Aarch64 port doesn't 
> report input denormals (I could not find any code which sets the IDC 
> bit in the FPSR).  I found code in the arm (not aarch64) port that 
> sets other bits like IXC, but nothing for IDC.   Is that simply because no 
> one has bothered to add this support?

It's because we failed to use symbolic constants.  See 
vfp_exceptbits_from_host.  Which
*is* used for both aarch64 and arm.


> The second concerns support for cases where multiple exception conditions 
> occur.   I had 
> originally thought that denormal input handling would be orthogonal to 
> everything else and 
> so a case like "sNaN  + denorm" would set both the invalid and input denormal 
> flags or 
> "denorm / 0" would set both idivde by zero and input denormal, but I don't 
> think that is 
> true for at least some architectures.  Perhaps some specialization is needed 
> here?

If you've got a specific example, we can look at it.  There's no point adding 
specialization that isn't going to be used.


r~

[PATCH v2 29/29] tcg/riscv: Remove MO_BSWAP handling

[Richard Henderson]

TCG_TARGET_HAS_MEMORY_BSWAP is already unset for this backend,
which means that MO_BSWAP be handled by the middle-end and
will never be seen by the backend.  Thus the indexes used with
qemu_{ld,st}_helpers will always be zero.

Tidy the comments and asserts in tcg_out_qemu_{ld,st}_direct.
It is not that we do not handle bswap "yet", but never will.

Acked-by: Alistair Francis 
Signed-off-by: Richard Henderson 
---
 tcg/riscv/tcg-target.c.inc | 64 --
 1 file changed, 33 insertions(+), 31 deletions(-)

diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
index da7eecafc5..c16f96b401 100644
--- a/tcg/riscv/tcg-target.c.inc
+++ b/tcg/riscv/tcg-target.c.inc
@@ -852,37 +852,43 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
 /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
  * TCGMemOpIdx oi, uintptr_t ra)
  */
-static void * const qemu_ld_helpers[16] = {
-[MO_UB]   = helper_ret_ldub_mmu,
-[MO_SB]   = helper_ret_ldsb_mmu,
-[MO_LEUW] = helper_le_lduw_mmu,
-[MO_LESW] = helper_le_ldsw_mmu,
-[MO_LEUL] = helper_le_ldul_mmu,
+static void * const qemu_ld_helpers[8] = {
+[MO_UB] = helper_ret_ldub_mmu,
+[MO_SB] = helper_ret_ldsb_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_UW] = helper_be_lduw_mmu,
+[MO_SW] = helper_be_ldsw_mmu,
+[MO_UL] = helper_be_ldul_mmu,
 #if TCG_TARGET_REG_BITS == 64
-[MO_LESL] = helper_le_ldsl_mmu,
+[MO_SL] = helper_be_ldsl_mmu,
 #endif
-[MO_LEQ]  = helper_le_ldq_mmu,
-[MO_BEUW] = helper_be_lduw_mmu,
-[MO_BESW] = helper_be_ldsw_mmu,
-[MO_BEUL] = helper_be_ldul_mmu,
+[MO_Q]  = helper_be_ldq_mmu,
+#else
+[MO_UW] = helper_le_lduw_mmu,
+[MO_SW] = helper_le_ldsw_mmu,
+[MO_UL] = helper_le_ldul_mmu,
 #if TCG_TARGET_REG_BITS == 64
-[MO_BESL] = helper_be_ldsl_mmu,
+[MO_SL] = helper_le_ldsl_mmu,
+#endif
+[MO_Q]  = helper_le_ldq_mmu,
 #endif
-[MO_BEQ]  = helper_be_ldq_mmu,
 };
 
 /* helper signature: helper_ret_st_mmu(CPUState *env, target_ulong addr,
  * uintxx_t val, TCGMemOpIdx oi,
  * uintptr_t ra)
  */
-static void * const qemu_st_helpers[16] = {
-[MO_UB]   = helper_ret_stb_mmu,
-[MO_LEUW] = helper_le_stw_mmu,
-[MO_LEUL] = helper_le_stl_mmu,
-[MO_LEQ]  = helper_le_stq_mmu,
-[MO_BEUW] = helper_be_stw_mmu,
-[MO_BEUL] = helper_be_stl_mmu,
-[MO_BEQ]  = helper_be_stq_mmu,
+static void * const qemu_st_helpers[4] = {
+[MO_8]   = helper_ret_stb_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_16] = helper_be_stw_mmu,
+[MO_32] = helper_be_stl_mmu,
+[MO_64] = helper_be_stq_mmu,
+#else
+[MO_16] = helper_le_stw_mmu,
+[MO_32] = helper_le_stl_mmu,
+[MO_64] = helper_le_stq_mmu,
+#endif
 };
 
 /* We don't support oversize guests */
@@ -997,7 +1003,7 @@ static bool tcg_out_qemu_ld_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 tcg_out_movi(s, TCG_TYPE_PTR, a2, oi);
 tcg_out_movi(s, TCG_TYPE_PTR, a3, (tcg_target_long)l->raddr);
 
-tcg_out_call(s, qemu_ld_helpers[opc & (MO_BSWAP | MO_SSIZE)]);
+tcg_out_call(s, qemu_ld_helpers[opc & MO_SSIZE]);
 tcg_out_mov(s, (opc & MO_SIZE) == MO_64, l->datalo_reg, a0);
 
 tcg_out_goto(s, l->raddr);
@@ -1042,7 +1048,7 @@ static bool tcg_out_qemu_st_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 tcg_out_movi(s, TCG_TYPE_PTR, a3, oi);
 tcg_out_movi(s, TCG_TYPE_PTR, a4, (tcg_target_long)l->raddr);
 
-tcg_out_call(s, qemu_st_helpers[opc & (MO_BSWAP | MO_SSIZE)]);
+tcg_out_call(s, qemu_st_helpers[opc & MO_SIZE]);
 
 tcg_out_goto(s, l->raddr);
 return true;
@@ -1052,10 +1058,8 @@ static bool tcg_out_qemu_st_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 static void tcg_out_qemu_ld_direct(TCGContext *s, TCGReg lo, TCGReg hi,
TCGReg base, MemOp opc, bool is_64)
 {
-const MemOp bswap = opc & MO_BSWAP;
-
-/* We don't yet handle byteswapping, assert */
-g_assert(!bswap);
+/* Byte swapping is left to middle-end expansion. */
+tcg_debug_assert((opc & MO_BSWAP) == 0);
 
 switch (opc & (MO_SSIZE)) {
 case MO_UB:
@@ -1139,10 +1143,8 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
*args, bool is_64)
 static void tcg_out_qemu_st_direct(TCGContext *s, TCGReg lo, TCGReg hi,
TCGReg base, MemOp opc)
 {
-const MemOp bswap = opc & MO_BSWAP;
-
-/* We don't yet handle byteswapping, assert */
-g_assert(!bswap);
+/* Byte swapping is left to middle-end expansion. */
+tcg_debug_assert((opc & MO_BSWAP) == 0);
 
 switch (opc & (MO_SSIZE)) {
 case MO_8:
-- 
2.25.1

[PATCH v2 27/29] tcg/arm: Unset TCG_TARGET_HAS_MEMORY_BSWAP

[Richard Henderson]

Now that the middle-end can replicate the same tricks as tcg/arm
used for optimizing bswap for signed loads and for stores, do not
pretend to have these memory ops in the backend.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.h |   2 +-
 tcg/arm/tcg-target.c.inc | 214 ++-
 2 files changed, 77 insertions(+), 139 deletions(-)

diff --git a/tcg/arm/tcg-target.h b/tcg/arm/tcg-target.h
index 57fd0c0c74..95fcef33bc 100644
--- a/tcg/arm/tcg-target.h
+++ b/tcg/arm/tcg-target.h
@@ -174,7 +174,7 @@ extern bool use_neon_instructions;
 #define TCG_TARGET_HAS_cmpsel_vec   0
 
 #define TCG_TARGET_DEFAULT_MO (0)
-#define TCG_TARGET_HAS_MEMORY_BSWAP 1
+#define TCG_TARGET_HAS_MEMORY_BSWAP 0
 
 /* not defined -- call should be eliminated at compile time */
 void tb_target_set_jmp_target(uintptr_t, uintptr_t, uintptr_t, uintptr_t);
diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index 73e0455511..7a761a602e 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -1393,34 +1393,38 @@ static void tcg_out_vldst(TCGContext *s, ARMInsn insn,
 /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
  * int mmu_idx, uintptr_t ra)
  */
-static void * const qemu_ld_helpers[16] = {
+static void * const qemu_ld_helpers[8] = {
 [MO_UB]   = helper_ret_ldub_mmu,
 [MO_SB]   = helper_ret_ldsb_mmu,
-
-[MO_LEUW] = helper_le_lduw_mmu,
-[MO_LEUL] = helper_le_ldul_mmu,
-[MO_LEQ]  = helper_le_ldq_mmu,
-[MO_LESW] = helper_le_ldsw_mmu,
-[MO_LESL] = helper_le_ldul_mmu,
-
-[MO_BEUW] = helper_be_lduw_mmu,
-[MO_BEUL] = helper_be_ldul_mmu,
-[MO_BEQ]  = helper_be_ldq_mmu,
-[MO_BESW] = helper_be_ldsw_mmu,
-[MO_BESL] = helper_be_ldul_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_UW] = helper_be_lduw_mmu,
+[MO_UL] = helper_be_ldul_mmu,
+[MO_Q]  = helper_be_ldq_mmu,
+[MO_SW] = helper_be_ldsw_mmu,
+[MO_SL] = helper_be_ldul_mmu,
+#else
+[MO_UW] = helper_le_lduw_mmu,
+[MO_UL] = helper_le_ldul_mmu,
+[MO_Q]  = helper_le_ldq_mmu,
+[MO_SW] = helper_le_ldsw_mmu,
+[MO_SL] = helper_le_ldul_mmu,
+#endif
 };
 
 /* helper signature: helper_ret_st_mmu(CPUState *env, target_ulong addr,
  * uintxx_t val, int mmu_idx, uintptr_t ra)
  */
-static void * const qemu_st_helpers[16] = {
-[MO_UB]   = helper_ret_stb_mmu,
-[MO_LEUW] = helper_le_stw_mmu,
-[MO_LEUL] = helper_le_stl_mmu,
-[MO_LEQ]  = helper_le_stq_mmu,
-[MO_BEUW] = helper_be_stw_mmu,
-[MO_BEUL] = helper_be_stl_mmu,
-[MO_BEQ]  = helper_be_stq_mmu,
+static void * const qemu_st_helpers[4] = {
+[MO_8]   = helper_ret_stb_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_16] = helper_be_stw_mmu,
+[MO_32] = helper_be_stl_mmu,
+[MO_64] = helper_be_stq_mmu,
+#else
+[MO_16] = helper_le_stw_mmu,
+[MO_32] = helper_le_stl_mmu,
+[MO_64] = helper_le_stq_mmu,
+#endif
 };
 
 /* Helper routines for marshalling helper function arguments into
@@ -1625,9 +1629,9 @@ static bool tcg_out_qemu_ld_slow_path(TCGContext *s, 
TCGLabelQemuLdst *lb)
icache usage.  For pre-armv6, use the signed helpers since we do
not have a single insn sign-extend.  */
 if (use_armv6_instructions) {
-func = qemu_ld_helpers[opc & (MO_BSWAP | MO_SIZE)];
+func = qemu_ld_helpers[opc & MO_SIZE];
 } else {
-func = qemu_ld_helpers[opc & (MO_BSWAP | MO_SSIZE)];
+func = qemu_ld_helpers[opc & MO_SSIZE];
 if (opc & MO_SIGN) {
 opc = MO_UL;
 }
@@ -1705,7 +1709,7 @@ static bool tcg_out_qemu_st_slow_path(TCGContext *s, 
TCGLabelQemuLdst *lb)
 argreg = tcg_out_arg_reg32(s, argreg, TCG_REG_R14);
 
 /* Tail-call to the helper, which will return to the fast path.  */
-tcg_out_goto(s, COND_AL, qemu_st_helpers[opc & (MO_BSWAP | MO_SIZE)]);
+tcg_out_goto(s, COND_AL, qemu_st_helpers[opc & MO_SIZE]);
 return true;
 }
 #endif /* SOFTMMU */
@@ -1714,7 +1718,8 @@ static inline void tcg_out_qemu_ld_index(TCGContext *s, 
MemOp opc,
  TCGReg datalo, TCGReg datahi,
  TCGReg addrlo, TCGReg addend)
 {
-MemOp bswap = opc & MO_BSWAP;
+/* Byte swapping is left to middle-end expansion. */
+tcg_debug_assert((opc & MO_BSWAP) == 0);
 
 switch (opc & MO_SSIZE) {
 case MO_UB:
@@ -1725,51 +1730,30 @@ static inline void tcg_out_qemu_ld_index(TCGContext *s, 
MemOp opc,
 break;
 case MO_UW:
 tcg_out_ld16u_r(s, COND_AL, datalo, addrlo, addend);
-if (bswap) {
-tcg_out_bswap16(s, COND_AL, datalo, datalo,
-TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-}
 break;
 case MO_SW:
-if (bswap) {
-tcg_out_ld16u_r(s, COND_AL, datalo, addrlo, addend);
-tcg_out_bswap16(s, COND_AL, datalo, 

[PATCH v2 28/29] tcg/aarch64: Unset TCG_TARGET_HAS_MEMORY_BSWAP

[Richard Henderson]

The memory bswap support in the aarch64 backend merely dates from
a time when it was required.  There is nothing special about the
backend support that could not have been provided by the middle-end
even prior to the introduction of the bswap flags.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/aarch64/tcg-target.h |  2 +-
 tcg/aarch64/tcg-target.c.inc | 87 +---
 2 files changed, 32 insertions(+), 57 deletions(-)

diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h
index ef55f7c185..551baf8da3 100644
--- a/tcg/aarch64/tcg-target.h
+++ b/tcg/aarch64/tcg-target.h
@@ -148,7 +148,7 @@ typedef enum {
 #define TCG_TARGET_HAS_cmpsel_vec   0
 
 #define TCG_TARGET_DEFAULT_MO (0)
-#define TCG_TARGET_HAS_MEMORY_BSWAP 1
+#define TCG_TARGET_HAS_MEMORY_BSWAP 0
 
 void tb_target_set_jmp_target(uintptr_t, uintptr_t, uintptr_t, uintptr_t);
 
diff --git a/tcg/aarch64/tcg-target.c.inc b/tcg/aarch64/tcg-target.c.inc
index 72aa7e0e74..5924977b42 100644
--- a/tcg/aarch64/tcg-target.c.inc
+++ b/tcg/aarch64/tcg-target.c.inc
@@ -1547,28 +1547,34 @@ static void tcg_out_cltz(TCGContext *s, TCGType ext, 
TCGReg d,
 /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
  * TCGMemOpIdx oi, uintptr_t ra)
  */
-static void * const qemu_ld_helpers[16] = {
-[MO_UB]   = helper_ret_ldub_mmu,
-[MO_LEUW] = helper_le_lduw_mmu,
-[MO_LEUL] = helper_le_ldul_mmu,
-[MO_LEQ]  = helper_le_ldq_mmu,
-[MO_BEUW] = helper_be_lduw_mmu,
-[MO_BEUL] = helper_be_ldul_mmu,
-[MO_BEQ]  = helper_be_ldq_mmu,
+static void * const qemu_ld_helpers[4] = {
+[MO_8]  = helper_ret_ldub_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_16] = helper_be_lduw_mmu,
+[MO_32] = helper_be_ldul_mmu,
+[MO_64] = helper_be_ldq_mmu,
+#else
+[MO_16] = helper_le_lduw_mmu,
+[MO_32] = helper_le_ldul_mmu,
+[MO_64] = helper_le_ldq_mmu,
+#endif
 };
 
 /* helper signature: helper_ret_st_mmu(CPUState *env, target_ulong addr,
  * uintxx_t val, TCGMemOpIdx oi,
  * uintptr_t ra)
  */
-static void * const qemu_st_helpers[16] = {
-[MO_UB]   = helper_ret_stb_mmu,
-[MO_LEUW] = helper_le_stw_mmu,
-[MO_LEUL] = helper_le_stl_mmu,
-[MO_LEQ]  = helper_le_stq_mmu,
-[MO_BEUW] = helper_be_stw_mmu,
-[MO_BEUL] = helper_be_stl_mmu,
-[MO_BEQ]  = helper_be_stq_mmu,
+static void * const qemu_st_helpers[4] = {
+[MO_8]  = helper_ret_stb_mmu,
+#ifdef HOST_WORDS_BIGENDIAN
+[MO_16] = helper_be_stw_mmu,
+[MO_32] = helper_be_stl_mmu,
+[MO_64] = helper_be_stq_mmu,
+#else
+[MO_16] = helper_le_stw_mmu,
+[MO_32] = helper_le_stl_mmu,
+[MO_64] = helper_le_stq_mmu,
+#endif
 };
 
 static inline void tcg_out_adr(TCGContext *s, TCGReg rd, const void *target)
@@ -1592,7 +1598,7 @@ static bool tcg_out_qemu_ld_slow_path(TCGContext *s, 
TCGLabelQemuLdst *lb)
 tcg_out_mov(s, TARGET_LONG_BITS == 64, TCG_REG_X1, lb->addrlo_reg);
 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_X2, oi);
 tcg_out_adr(s, TCG_REG_X3, lb->raddr);
-tcg_out_call(s, qemu_ld_helpers[opc & (MO_BSWAP | MO_SIZE)]);
+tcg_out_call(s, qemu_ld_helpers[opc & MO_SIZE]);
 if (opc & MO_SIGN) {
 tcg_out_sxt(s, lb->type, size, lb->datalo_reg, TCG_REG_X0);
 } else {
@@ -1618,7 +1624,7 @@ static bool tcg_out_qemu_st_slow_path(TCGContext *s, 
TCGLabelQemuLdst *lb)
 tcg_out_mov(s, size == MO_64, TCG_REG_X2, lb->datalo_reg);
 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_X3, oi);
 tcg_out_adr(s, TCG_REG_X4, lb->raddr);
-tcg_out_call(s, qemu_st_helpers[opc & (MO_BSWAP | MO_SIZE)]);
+tcg_out_call(s, qemu_st_helpers[opc & MO_SIZE]);
 tcg_out_goto(s, lb->raddr);
 return true;
 }
@@ -1714,7 +1720,8 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, MemOp 
memop, TCGType ext,
TCGReg data_r, TCGReg addr_r,
TCGType otype, TCGReg off_r)
 {
-const MemOp bswap = memop & MO_BSWAP;
+/* Byte swapping is left to middle-end expansion. */
+tcg_debug_assert((memop & MO_BSWAP) == 0);
 
 switch (memop & MO_SSIZE) {
 case MO_UB:
@@ -1726,40 +1733,19 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, MemOp 
memop, TCGType ext,
 break;
 case MO_UW:
 tcg_out_ldst_r(s, I3312_LDRH, data_r, addr_r, otype, off_r);
-if (bswap) {
-tcg_out_rev(s, TCG_TYPE_I32, MO_16, data_r, data_r);
-}
 break;
 case MO_SW:
-if (bswap) {
-tcg_out_ldst_r(s, I3312_LDRH, data_r, addr_r, otype, off_r);
-tcg_out_rev(s, TCG_TYPE_I32, MO_16, data_r, data_r);
-tcg_out_sxt(s, ext, MO_16, data_r, data_r);
-} else {
-tcg_out_ldst_r(s, (ext ? I3312_LDRSHX : I3312_LDRSHW),
-   data_r, addr_r, otype, off_r);
-}
+tcg_out_ldst_r(s, 

[PATCH v2 25/29] target/sh4: Improve swap.b translation

[Richard Henderson]

Remove TCG_BSWAP_IZ and the preceding zero-extension.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/sh4/translate.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/sh4/translate.c b/target/sh4/translate.c
index 147219759b..f45515952f 100644
--- a/target/sh4/translate.c
+++ b/target/sh4/translate.c
@@ -676,8 +676,7 @@ static void _decode_opc(DisasContext * ctx)
 case 0x6008:   /* swap.b Rm,Rn */
{
 TCGv low = tcg_temp_new();
-   tcg_gen_ext16u_i32(low, REG(B7_4));
-   tcg_gen_bswap16_i32(low, low, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+   tcg_gen_bswap16_i32(low, REG(B7_4), 0);
 tcg_gen_deposit_i32(REG(B11_8), REG(B7_4), low, 0, 16);
tcg_temp_free(low);
}
-- 
2.25.1

[PATCH v2 23/29] target/arm: Improve REVSH

[Richard Henderson]

The new bswap flags can implement the semantics exactly.

Reviewed-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index 669b0be578..a0c6cfa902 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -354,9 +354,7 @@ void gen_rev16(TCGv_i32 dest, TCGv_i32 var)
 /* Byteswap low halfword and sign extend.  */
 static void gen_revsh(TCGv_i32 dest, TCGv_i32 var)
 {
-tcg_gen_ext16u_i32(var, var);
-tcg_gen_bswap16_i32(var, var, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-tcg_gen_ext16s_i32(dest, var);
+tcg_gen_bswap16_i32(var, var, TCG_BSWAP_OS);
 }
 
 /* Dual 16-bit add.  Result placed in t0 and t1 is marked as dead.
-- 
2.25.1

[PATCH v2 24/29] target/i386: Improve bswap translation

[Richard Henderson]

Use a break instead of an ifdefed else.
There's no need to move the values through s->T0.
Remove TCG_BSWAP_IZ and the preceding zero-extension.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/i386/tcg/translate.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index e8a9dcd21a..b21873ed23 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -7195,17 +7195,11 @@ static target_ulong disas_insn(DisasContext *s, 
CPUState *cpu)
 reg = (b & 7) | REX_B(s);
 #ifdef TARGET_X86_64
 if (dflag == MO_64) {
-gen_op_mov_v_reg(s, MO_64, s->T0, reg);
-tcg_gen_bswap64_i64(s->T0, s->T0);
-gen_op_mov_reg_v(s, MO_64, reg, s->T0);
-} else
-#endif
-{
-gen_op_mov_v_reg(s, MO_32, s->T0, reg);
-tcg_gen_ext32u_tl(s->T0, s->T0);
-tcg_gen_bswap32_tl(s->T0, s->T0, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-gen_op_mov_reg_v(s, MO_32, reg, s->T0);
+tcg_gen_bswap64_i64(cpu_regs[reg], cpu_regs[reg]);
+break;
 }
+#endif
+tcg_gen_bswap32_tl(cpu_regs[reg], cpu_regs[reg], TCG_BSWAP_OZ);
 break;
 case 0xd6: /* salc */
 if (CODE64(s))
-- 
2.25.1

[PATCH v2 15/29] tcg/mips: Support bswap flags in tcg_out_bswap32

[Richard Henderson]

Merge tcg_out_bswap32 and tcg_out_bswap32s.
Use the flags in the internal uses for loads and stores.

For mips32r2 bswap32 with zero-extension, standardize on
WSBH+ROTR+DEXT.  This is the same number of insns as the
previous DSBH+DSHD+DSRL but fits in better with the flags check.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 tcg/mips/tcg-target.c.inc | 39 ---
 1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/tcg/mips/tcg-target.c.inc b/tcg/mips/tcg-target.c.inc
index 7a5634419c..e3698274eb 100644
--- a/tcg/mips/tcg-target.c.inc
+++ b/tcg/mips/tcg-target.c.inc
@@ -578,27 +578,20 @@ static void tcg_out_bswap_subr(TCGContext *s, const 
tcg_insn_unit *sub)
 tcg_debug_assert(ok);
 }
 
-static void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg)
+static void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg, int flags)
 {
 if (use_mips32r2_instructions) {
 tcg_out_opc_reg(s, OPC_WSBH, ret, 0, arg);
 tcg_out_opc_sa(s, OPC_ROTR, ret, ret, 16);
+if (flags & TCG_BSWAP_OZ) {
+tcg_out_opc_bf(s, OPC_DEXT, ret, ret, 31, 0);
+}
 } else {
-tcg_out_bswap_subr(s, bswap32_addr);
-/* delay slot -- never omit the insn, like tcg_out_mov might.  */
-tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
-tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
-}
-}
-
-static void tcg_out_bswap32u(TCGContext *s, TCGReg ret, TCGReg arg)
-{
-if (use_mips32r2_instructions) {
-tcg_out_opc_reg(s, OPC_DSBH, ret, 0, arg);
-tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);
-tcg_out_dsrl(s, ret, ret, 32);
-} else {
-tcg_out_bswap_subr(s, bswap32u_addr);
+if (flags & TCG_BSWAP_OZ) {
+tcg_out_bswap_subr(s, bswap32u_addr);
+} else {
+tcg_out_bswap_subr(s, bswap32_addr);
+}
 /* delay slot -- never omit the insn, like tcg_out_mov might.  */
 tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
 tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
@@ -1380,7 +1373,7 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, TCGReg 
lo, TCGReg hi,
 if (TCG_TARGET_REG_BITS == 64 && is_64) {
 if (use_mips32r2_instructions) {
 tcg_out_opc_imm(s, OPC_LWU, lo, base, 0);
-tcg_out_bswap32u(s, lo, lo);
+tcg_out_bswap32(s, lo, lo, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
 } else {
 tcg_out_bswap_subr(s, bswap32u_addr);
 /* delay slot */
@@ -1393,7 +1386,7 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, TCGReg 
lo, TCGReg hi,
 case MO_SL | MO_BSWAP:
 if (use_mips32r2_instructions) {
 tcg_out_opc_imm(s, OPC_LW, lo, base, 0);
-tcg_out_bswap32(s, lo, lo);
+tcg_out_bswap32(s, lo, lo, 0);
 } else {
 tcg_out_bswap_subr(s, bswap32_addr);
 /* delay slot */
@@ -1519,7 +1512,7 @@ static void tcg_out_qemu_st_direct(TCGContext *s, TCGReg 
lo, TCGReg hi,
 break;
 
 case MO_32 | MO_BSWAP:
-tcg_out_bswap32(s, TCG_TMP3, lo);
+tcg_out_bswap32(s, TCG_TMP3, lo, 0);
 lo = TCG_TMP3;
 /* FALLTHRU */
 case MO_32:
@@ -1538,9 +1531,9 @@ static void tcg_out_qemu_st_direct(TCGContext *s, TCGReg 
lo, TCGReg hi,
 tcg_out_opc_imm(s, OPC_SW, TCG_TMP0, base, 0);
 tcg_out_opc_imm(s, OPC_SW, TCG_TMP1, base, 4);
 } else {
-tcg_out_bswap32(s, TCG_TMP3, MIPS_BE ? lo : hi);
+tcg_out_bswap32(s, TCG_TMP3, MIPS_BE ? lo : hi, 0);
 tcg_out_opc_imm(s, OPC_SW, TCG_TMP3, base, 0);
-tcg_out_bswap32(s, TCG_TMP3, MIPS_BE ? hi : lo);
+tcg_out_bswap32(s, TCG_TMP3, MIPS_BE ? hi : lo, 0);
 tcg_out_opc_imm(s, OPC_SW, TCG_TMP3, base, 4);
 }
 break;
@@ -1945,10 +1938,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_bswap16(s, a0, a1, a2);
 break;
 case INDEX_op_bswap32_i32:
-tcg_out_bswap32(s, a0, a1);
+tcg_out_bswap32(s, a0, a1, 0);
 break;
 case INDEX_op_bswap32_i64:
-tcg_out_bswap32u(s, a0, a1);
+tcg_out_bswap32(s, a0, a1, a2);
 break;
 case INDEX_op_bswap64_i64:
 tcg_out_bswap64(s, a0, a1);
-- 
2.25.1

Re: Denormal input handling

[Richard Henderson]

On 6/21/21 4:13 PM, Michael Morrell wrote:

I have another couple of thoughts around input denormal handling.

The first is straightforward.  I noticed that the Aarch64 port doesn't report input 
denormals (I could not find any code which sets the IDC bit in the FPSR).  I found code in 
the arm (not aarch64) port that sets other bits like IXC, but nothing for IDC.   Is that 
simply because no one has bothered to add this support?


It's because we failed to use symbolic constants.  See vfp_exceptbits_from_host.  Which 
*is* used for both aarch64 and arm.



The second concerns support for cases where multiple exception conditions occur.   I had 
originally thought that denormal input handling would be orthogonal to everything else and 
so a case like "sNaN  + denorm" would set both the invalid and input denormal flags or 
"denorm / 0" would set both idivde by zero and input denormal, but I don't think that is 
true for at least some architectures.  Perhaps some specialization is needed here?


If you've got a specific example, we can look at it.  There's no point adding 
specialization that isn't going to be used.



r~

[PATCH v2 22/29] target/arm: Improve vector REV

[Richard Henderson]

We can eliminate the requirement for a zero-extended output,
because the following store will ignore any garbage high bits.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/translate-a64.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 304fd3d370..1a40e49db7 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -12444,12 +12444,10 @@ static void handle_rev(DisasContext *s, int opcode, 
bool u,
 read_vec_element(s, tcg_tmp, rn, i, grp_size);
 switch (grp_size) {
 case MO_16:
-tcg_gen_bswap16_i64(tcg_tmp, tcg_tmp,
-TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap16_i64(tcg_tmp, tcg_tmp, TCG_BSWAP_IZ);
 break;
 case MO_32:
-tcg_gen_bswap32_i64(tcg_tmp, tcg_tmp,
-TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap32_i64(tcg_tmp, tcg_tmp, TCG_BSWAP_IZ);
 break;
 case MO_64:
 tcg_gen_bswap64_i64(tcg_tmp, tcg_tmp);
-- 
2.25.1

[PATCH v2 14/29] tcg/mips: Support bswap flags in tcg_out_bswap16

[Richard Henderson]

Merge tcg_out_bswap16 and tcg_out_bswap16s.  Use the flags
in the internal uses for loads and stores.

Signed-off-by: Richard Henderson 
---
 tcg/mips/tcg-target.c.inc | 60 ++-
 1 file changed, 28 insertions(+), 32 deletions(-)

diff --git a/tcg/mips/tcg-target.c.inc b/tcg/mips/tcg-target.c.inc
index 598b2a..7a5634419c 100644
--- a/tcg/mips/tcg-target.c.inc
+++ b/tcg/mips/tcg-target.c.inc
@@ -540,39 +540,36 @@ static void tcg_out_movi(TCGContext *s, TCGType type,
 }
 }
 
-static inline void tcg_out_bswap16(TCGContext *s, TCGReg ret, TCGReg arg)
+static void tcg_out_bswap16(TCGContext *s, TCGReg ret, TCGReg arg, int flags)
 {
+/* ret and arg can't be register tmp0 */
+tcg_debug_assert(ret != TCG_TMP0);
+tcg_debug_assert(arg != TCG_TMP0);
+
 if (use_mips32r2_instructions) {
 tcg_out_opc_reg(s, OPC_WSBH, ret, 0, arg);
-} else {
-/* ret and arg can't be register at */
-if (ret == TCG_TMP0 || arg == TCG_TMP0) {
-tcg_abort();
+if (flags & TCG_BSWAP_OS) {
+tcg_out_opc_reg(s, OPC_SEH, ret, 0, ret);
+} else if ((flags & (TCG_BSWAP_IZ | TCG_BSWAP_OZ)) == TCG_BSWAP_OZ) {
+tcg_out_opc_imm(s, OPC_ANDI, ret, ret, 0x);
 }
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 8);
-tcg_out_opc_sa(s, OPC_SLL, ret, arg, 8);
-tcg_out_opc_imm(s, OPC_ANDI, ret, ret, 0xff00);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
+return;
 }
-}
 
-static inline void tcg_out_bswap16s(TCGContext *s, TCGReg ret, TCGReg arg)
-{
-if (use_mips32r2_instructions) {
-tcg_out_opc_reg(s, OPC_WSBH, ret, 0, arg);
-tcg_out_opc_reg(s, OPC_SEH, ret, 0, ret);
-} else {
-/* ret and arg can't be register at */
-if (ret == TCG_TMP0 || arg == TCG_TMP0) {
-tcg_abort();
-}
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 8);
+tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 8);
+if (!(flags & TCG_BSWAP_IZ)) {
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP0, TCG_TMP0, 0x00ff);
+}
+if (flags & TCG_BSWAP_OS) {
 tcg_out_opc_sa(s, OPC_SLL, ret, arg, 24);
 tcg_out_opc_sa(s, OPC_SRA, ret, ret, 16);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
+} else {
+tcg_out_opc_sa(s, OPC_SLL, ret, arg, 8);
+if (flags & TCG_BSWAP_OZ) {
+tcg_out_opc_imm(s, OPC_ANDI, ret, ret, 0xff00);
+}
 }
+tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
 }
 
 static void tcg_out_bswap_subr(TCGContext *s, const tcg_insn_unit *sub)
@@ -1367,14 +1364,14 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, 
TCGReg lo, TCGReg hi,
 break;
 case MO_UW | MO_BSWAP:
 tcg_out_opc_imm(s, OPC_LHU, TCG_TMP1, base, 0);
-tcg_out_bswap16(s, lo, TCG_TMP1);
+tcg_out_bswap16(s, lo, TCG_TMP1, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
 break;
 case MO_UW:
 tcg_out_opc_imm(s, OPC_LHU, lo, base, 0);
 break;
 case MO_SW | MO_BSWAP:
 tcg_out_opc_imm(s, OPC_LHU, TCG_TMP1, base, 0);
-tcg_out_bswap16s(s, lo, TCG_TMP1);
+tcg_out_bswap16(s, lo, TCG_TMP1, TCG_BSWAP_IZ | TCG_BSWAP_OS);
 break;
 case MO_SW:
 tcg_out_opc_imm(s, OPC_LH, lo, base, 0);
@@ -1514,8 +1511,7 @@ static void tcg_out_qemu_st_direct(TCGContext *s, TCGReg 
lo, TCGReg hi,
 break;
 
 case MO_16 | MO_BSWAP:
-tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, lo, 0x);
-tcg_out_bswap16(s, TCG_TMP1, TCG_TMP1);
+tcg_out_bswap16(s, TCG_TMP1, lo, 0);
 lo = TCG_TMP1;
 /* FALLTHRU */
 case MO_16:
@@ -1933,10 +1929,6 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 case INDEX_op_not_i64:
 i1 = OPC_NOR;
 goto do_unary;
-case INDEX_op_bswap16_i32:
-case INDEX_op_bswap16_i64:
-i1 = OPC_WSBH;
-goto do_unary;
 case INDEX_op_ext8s_i32:
 case INDEX_op_ext8s_i64:
 i1 = OPC_SEB;
@@ -1948,6 +1940,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_opc_reg(s, i1, a0, TCG_REG_ZERO, a1);
 break;
 
+case INDEX_op_bswap16_i32:
+case INDEX_op_bswap16_i64:
+tcg_out_bswap16(s, a0, a1, a2);
+break;
 case INDEX_op_bswap32_i32:
 tcg_out_bswap32(s, a0, a1);
 break;
-- 
2.25.1

[PATCH v2 21/29] target/arm: Improve REV32

[Richard Henderson]

For the sf version, we are performing two 32-bit bswaps
in either half of the register.  This is equivalent to
performing one 64-bit bswap followed by a rotate.

For the non-sf version, we can remove TCG_BSWAP_IZ
and the preceding zero-extension.

Reviewed-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 target/arm/translate-a64.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index f2641a37ba..304fd3d370 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -5430,22 +5430,13 @@ static void handle_rev32(DisasContext *s, unsigned int 
sf,
  unsigned int rn, unsigned int rd)
 {
 TCGv_i64 tcg_rd = cpu_reg(s, rd);
+TCGv_i64 tcg_rn = cpu_reg(s, rn);
 
 if (sf) {
-TCGv_i64 tcg_tmp = tcg_temp_new_i64();
-TCGv_i64 tcg_rn = read_cpu_reg(s, rn, sf);
-
-/* bswap32_i64 requires zero high word */
-tcg_gen_ext32u_i64(tcg_tmp, tcg_rn);
-tcg_gen_bswap32_i64(tcg_rd, tcg_tmp, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-tcg_gen_shri_i64(tcg_tmp, tcg_rn, 32);
-tcg_gen_bswap32_i64(tcg_tmp, tcg_tmp, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-tcg_gen_concat32_i64(tcg_rd, tcg_rd, tcg_tmp);
-
-tcg_temp_free_i64(tcg_tmp);
+tcg_gen_bswap64_i64(tcg_rd, tcg_rn);
+tcg_gen_rotri_i64(tcg_rd, tcg_rd, 32);
 } else {
-tcg_gen_ext32u_i64(tcg_rd, cpu_reg(s, rn));
-tcg_gen_bswap32_i64(tcg_rd, tcg_rd, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap32_i64(tcg_rd, tcg_rn, TCG_BSWAP_OZ);
 }
 }
 
-- 
2.25.1

[PATCH v2 20/29] tcg: Make use of bswap flags in tcg_gen_qemu_st_*

[Richard Henderson]

By removing TCG_BSWAP_IZ we indicate that the input is
not zero-extended, and thus can remove an explicit extend.
By removing TCG_BSWAP_OZ, we allow the implementation to
leave high bits set, which will be ignored by the store.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/tcg-op.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index 0eac2d1969..44d711c0fc 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -2915,8 +2915,7 @@ void tcg_gen_qemu_st_i32(TCGv_i32 val, TCGv addr, TCGArg 
idx, MemOp memop)
 swap = tcg_temp_new_i32();
 switch (memop & MO_SIZE) {
 case MO_16:
-tcg_gen_ext16u_i32(swap, val);
-tcg_gen_bswap16_i32(swap, swap, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap16_i32(swap, val, 0);
 break;
 case MO_32:
 tcg_gen_bswap32_i32(swap, val);
@@ -3013,12 +3012,10 @@ void tcg_gen_qemu_st_i64(TCGv_i64 val, TCGv addr, 
TCGArg idx, MemOp memop)
 swap = tcg_temp_new_i64();
 switch (memop & MO_SIZE) {
 case MO_16:
-tcg_gen_ext16u_i64(swap, val);
-tcg_gen_bswap16_i64(swap, swap, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap16_i64(swap, val, 0);
 break;
 case MO_32:
-tcg_gen_ext32u_i64(swap, val);
-tcg_gen_bswap32_i64(swap, swap, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
+tcg_gen_bswap32_i64(swap, val, 0);
 break;
 case MO_64:
 tcg_gen_bswap64_i64(swap, val);
-- 
2.25.1

[PATCH v2 26/29] target/mips: Fix gen_mxu_s32ldd_s32lddr

[Richard Henderson]

There were two bugs here: (1) the required endianness was
not present in the MemOp, and (2) we were not providing a
zero-extended input to the bswap as semantics required.

The best fix is to fold the bswap into the memory operation,
producing the desired result directly.

Acked-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 target/mips/tcg/mxu_translate.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/target/mips/tcg/mxu_translate.c b/target/mips/tcg/mxu_translate.c
index c12cf78df7..f4356432c7 100644
--- a/target/mips/tcg/mxu_translate.c
+++ b/target/mips/tcg/mxu_translate.c
@@ -857,12 +857,8 @@ static void gen_mxu_s32ldd_s32lddr(DisasContext *ctx)
 tcg_gen_ori_tl(t1, t1, 0xF000);
 }
 tcg_gen_add_tl(t1, t0, t1);
-tcg_gen_qemu_ld_tl(t1, t1, ctx->mem_idx, MO_SL);
+tcg_gen_qemu_ld_tl(t1, t1, ctx->mem_idx, MO_TESL ^ (sel * MO_BSWAP));
 
-if (sel == 1) {
-/* S32LDDR */
-tcg_gen_bswap32_tl(t1, t1, TCG_BSWAP_IZ | TCG_BSWAP_OZ);
-}
 gen_store_mxu_gpr(t1, XRa);
 
 tcg_temp_free(t0);
-- 
2.25.1

[PATCH v2 09/29] tcg/ppc: Split out tcg_out_bswap32

[Richard Henderson]

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/ppc/tcg-target.c.inc | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc
index ad46ce32ca..28b8671cba 100644
--- a/tcg/ppc/tcg-target.c.inc
+++ b/tcg/ppc/tcg-target.c.inc
@@ -807,6 +807,27 @@ static void tcg_out_bswap16(TCGContext *s, TCGReg dst, 
TCGReg src)
 tcg_out_mov(s, TCG_TYPE_REG, dst, tmp);
 }
 
+static void tcg_out_bswap32(TCGContext *s, TCGReg dst, TCGReg src)
+{
+TCGReg tmp = dst == src ? TCG_REG_R0 : dst;
+
+/*
+ * Stolen from gcc's builtin_bswap32.
+ * In the following,
+ *   dep(a, b, m) -> (a & ~m) | (b & m)
+ *
+ * Begin with:  src = abcd
+ */
+/* tmp = rol32(src, 8) & 0x = bcda */
+tcg_out_rlw(s, RLWINM, tmp, src, 8, 0, 31);
+/* tmp = dep(tmp, rol32(src, 24), 0xff00)   = dcda */
+tcg_out_rlw(s, RLWIMI, tmp, src, 24, 0, 7);
+/* tmp = dep(tmp, rol32(src, 24), 0xff00)   = dcba */
+tcg_out_rlw(s, RLWIMI, tmp, src, 24, 16, 23);
+
+tcg_out_mov(s, TCG_TYPE_REG, dst, tmp);
+}
+
 /* Emit a move into ret of arg, if it can be done in one insn.  */
 static bool tcg_out_movi_one(TCGContext *s, TCGReg ret, tcg_target_long arg)
 {
@@ -2799,24 +2820,9 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 case INDEX_op_bswap16_i64:
 tcg_out_bswap16(s, args[0], args[1]);
 break;
-
 case INDEX_op_bswap32_i32:
 case INDEX_op_bswap32_i64:
-/* Stolen from gcc's builtin_bswap32 */
-a1 = args[1];
-a0 = args[0] == a1 ? TCG_REG_R0 : args[0];
-
-/* a1 = args[1] # abcd */
-/* a0 = rotate_left (a1, 8) # bcda */
-tcg_out_rlw(s, RLWINM, a0, a1, 8, 0, 31);
-/* a0 = (a0 & ~0xff00) | ((a1 r<< 24) & 0xff00) # dcda */
-tcg_out_rlw(s, RLWIMI, a0, a1, 24, 0, 7);
-/* a0 = (a0 & ~0xff00) | ((a1 r<< 24) & 0xff00) # dcba */
-tcg_out_rlw(s, RLWIMI, a0, a1, 24, 16, 23);
-
-if (a0 == TCG_REG_R0) {
-tcg_out_mov(s, TCG_TYPE_REG, args[0], a0);
-}
+tcg_out_bswap32(s, args[0], args[1]);
 break;
 
 case INDEX_op_bswap64_i64:
-- 
2.25.1