[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

[Christian Ehrhardt ]

@Ubuntu-Desktop Team (now subscribed) - is there a chance we can revert [1] in 
mesa before it will be released with Disco for now. That would be needed until 
an accepted solution throughout the stack of libvirt/qemu/mesa is found?
Otherwise using GL backed qemu graphics will fail as outlined in the bug.

Once such a cross-package solution to the problem is found we can (if
needed at all) SRU back the set of changes to all components required.

[1]:
https://github.com/mesa3d/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in Mesa:
  Unknown
Status in QEMU:
  New
Status in mesa package in Ubuntu:
  New
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

[Christian Ehrhardt ]

Summary:
- qemu crash when using GL
- "sched_setaffinity" is the syscall that is seccomp blocked and kills qemu
- the mesa i915 drivers (and your radeon as well) will do that call
- it is blocked by the current qemu -sanbox on,...,resourcecontrol=deny which 
is libvirts default
- Implemented by qemu 24f8cdc572
- Similar issue being fixed last year qemu 056de1e894
- new code in mesa 18.3 since mesa d877451b48

I think we just need to allow sched_setaffinity with these new mesa drivers in 
the wild.
The alternative to detect gl usage in libvirt and only then allow 
ressourcecontrol IMHO seems over-engineered (needs internals to actually pass 
the need of seccomp subsets to be switched) and not better (more syscalls will 
be non-blocked then as the -secomp interface isn't fine grained).

OTOH the man page literally says "... Disable process affinity ...", so I'm not 
sure we can just remove it. Maybe split resourcecontrol in two, put *affinity* 
in the new one and make the default being not blocked - so that upper layers 
like libvirt will work until one explicitly states ... -sandbox on,affinity=on 
which no one wanting to use GL would do. That again seems too much.
Well the discussion will happen either here on ML/bug or latter when submitting 
an RFC for it.

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

[Christian Ehrhardt ]

>From Ubuntu's POV this is rather new as the code in Mesa came in with the 
>fresh 18.3.0_rc4-1
It is possible that no one else saw it so far ...
It is in mesa upstream since
  https://github.com/mesa3d/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a

But opinions might differ ...
I'll subscribe upstream qemu to this bug and then post a summary here.
This will mirror the bug updates to the Mailing List, if there is no harsh 
feedback I'll propose a patch to remove sched_setaffinity from the list of 
blocked calls.

** Also affects: qemu
   Importance: Undecided
   Status: New

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

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

Re: [Qemu-devel] Live migration from Qemu 2.12 hosts to Qemu 3.2 hosts, with VMX flag enabled in the guest?

[Christian Ehrhardt]

On Fri, Jan 18, 2019 at 7:33 AM Mark Mielke  wrote:
>
> Thank you for the work on nested virtualization. Having had live migrations
> fail in the past when nested virtualization has been active, it is great to
> see that clever people have been working on this problem!
>
> My question is about whether a migration path has been considered to allow
> live migration from Qemu 2.12 hosts to Qemu 3.2 hosts, with VMX flag
> enabled in the guest?
>
> Qemu 2.12 doesn't know about the new nested state available from newer
> Linux kernels, and it might be used on a machine with an older kernel that
> doesn't make the nested state available. If Qemu 3.2 is on an up-to-date
> host with an up-to-date kernel that does support the nested state, I'd like
> to ensure we have the ability to try the migrations.
>
> In the past, I've found that:
>
> 1) If the guest had used nested virtualization before, the migration often
> fails. However, if we reboot the guest and do not use nested
> virtualization, this simplifies to...
> 2) If the guest has never used nested virtualization before, the migration
> succeeds.
>
> I would like to leverage 2) as much as possible to migrate forwards to Qemu
> 3.2 hosts (once it is available). I can normally enter the guest to see if
> 1) is likely or not, and handle these ones specially. If only 20% of the
> guests have ever used nested virtualization, then I would like the option
> to safely migrate 80% of the guests using live migration, and handle the
> 20% as exceptions.
>
> This is the 3.1 change log that got my attention:
>
>
>- x86 machines cannot be live-migrated if nested Intel virtualization is
>enabled. The next version of QEMU will be able to do live migration when
>nested virtualization is enabled, if supported by the kernel.
>
>
> I believe this is the change it refers to:
>
> commit d98f26073bebddcd3da0ba1b86c3a34e840c0fb8
> Author: Paolo Bonzini 
> Date:   Wed Nov 14 10:38:13 2018 +0100
>
> target/i386: kvm: add VMX migration blocker
>
> Nested VMX does not support live migration yet.  Add a blocker
> until that is worked out.
>
> Nested SVM only does not support it, but unfortunately it is
> enabled by default for -cpu host so we cannot really disable it.
>
> Signed-off-by: Paolo Bonzini 
>
>
> This particular check seems very simplistic:
>
> +if ((env->features[FEAT_1_ECX] & CPUID_EXT_VMX) && !vmx_mig_blocker) {
> +error_setg(_mig_blocker,
> +   "Nested VMX virtualization does not support live
> migration yet");
> +r = migrate_add_blocker(vmx_mig_blocker, _err);
> +if (local_err) {
> +error_report_err(local_err);
> +error_free(vmx_mig_blocker);
> +return r;
> +}
> +}
> +
>
> It fails if the flag is set, rather than if any nested virtualization has
> been used before.

Hi Mark,
I was facing the same question just recently - thanks for bringing it up.

Even more emphasized as Ubuntu (for ease of use of nested
virtualization) will enable the VMX flag by default.
That made me end up with no guest being able to migrate at all, which
as you point out clearly was not the case - they would migrate fine.
In almost all use cases it would be just the VMX flag that was set,
but never used.

I haven't thought about it before your mail, but if there would be a
way to differentiate between "VMX available" and "VMX actually used"
that would be a much better check to set the blocker.

For now I reverted above patch with the migration blocker in Ubuntu to
get the situation temporarily resolved.
I considered it a downstream thing as it is mostly triggered by our
decision to make VMX available by default which was made years ago -
that is the reason I didn't bring it up here, but now that you brought
it up it is worth the discussion for sure.

Mid term I expect that migration will work for nested guests as well
which makes me able to drop that delta then.

> I'm concerned I will end up with a requirement for *all* guests to be
> restarted in order to migrate them to the new hosts, rather than just the
> ones that would have a problem.
>
> Thoughts?
>
> Thanks!
>
> --
> Mark Mielke 



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Subscribed there as well now to stay on top of it if upstream gets to a
conclusion.

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * There are conditions where the vga/qxl driver can crash the qemu 
 process.

   * It is like a very complex case of a non initialized var - without the 
 fix it might try to ask for updates without having a valid primary 
 surface.

   * Backport from upstream
  
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
  to avoid the crash

  
  [Test Case]

   * Sometimes booting xubuntu was reported to be enough, at other times
  it was needed to change resolution a few times to trigger.

# get xubuntu iso (actually other UI Isos should do as well)
$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
# If it boots successfully, change resolution until it crashes.
$ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done

   * Without the fix that will trigger the qemu crash

  [Regression Potential]

   * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
 the rendering update. That sounds rather safe. But thinking hard on 
 potential updates I could think of theoretical setups that were  in 
 undefined mode all the time (unlikely or impossible I think) that now 
 would get no updates anymore. Well I really don't think this is an 
 issue, but since this section should be open thinking on "potential" 
 regressions that is what comes to my mind.

  [Other Info]
   
   * Thanks to Leonardo for most of the bisecting and discussion work!

  
  ---

  
  When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Arr reading is hard today, you had the other bug open already ... grml
:-)

Never the less - This bug here is fixed in the proposed version and for
now that is the important part.

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * There are conditions where the vga/qxl driver can crash the qemu 
 process.

   * It is like a very complex case of a non initialized var - without the 
 fix it might try to ask for updates without having a valid primary 
 surface.

   * Backport from upstream
  
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
  to avoid the crash

  
  [Test Case]

   * Sometimes booting xubuntu was reported to be enough, at other times
  it was needed to change resolution a few times to trigger.

# get xubuntu iso (actually other UI Isos should do as well)
$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
# If it boots successfully, change resolution until it crashes.
$ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done

   * Without the fix that will trigger the qemu crash

  [Regression Potential]

   * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
 the rendering update. That sounds rather safe. But thinking hard on 
 potential updates I could think of theoretical setups that were  in 
 undefined mode all the time (unlikely or impossible I think) that now 
 would get no updates anymore. Well I really don't think this is an 
 issue, but since this section should be open thinking on "potential" 
 regressions that is what comes to my mind.

  [Other Info]
   
   * Thanks to Leonardo for most of the bisecting and discussion work!

  
  ---

  
  When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Thanks Leonardo for your check as well!
I agree that this particular issue here is fixed as we hoped.
The other one with the freeze did not occur for me, you might open another bug 
if you have any pointers how we could go on on this.

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * There are conditions where the vga/qxl driver can crash the qemu 
 process.

   * It is like a very complex case of a non initialized var - without the 
 fix it might try to ask for updates without having a valid primary 
 surface.

   * Backport from upstream
  
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
  to avoid the crash

  
  [Test Case]

   * Sometimes booting xubuntu was reported to be enough, at other times
  it was needed to change resolution a few times to trigger.

# get xubuntu iso (actually other UI Isos should do as well)
$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
# If it boots successfully, change resolution until it crashes.
$ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done

   * Without the fix that will trigger the qemu crash

  [Regression Potential]

   * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
 the rendering update. That sounds rather safe. But thinking hard on 
 potential updates I could think of theoretical setups that were  in 
 undefined mode all the time (unlikely or impossible I think) that now 
 would get no updates anymore. Well I really don't think this is an 
 issue, but since this section should be open thinking on "potential" 
 regressions that is what comes to my mind.

  [Other Info]
   
   * Thanks to Leonardo for most of the bisecting and discussion work!

  
  ---

  
  When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Running the Bionic ISO like:
$ qemu-system-x86_64 -cpu host -smp cores=4,threads=2 -boot d -m 2048 
-enable-kvm -vga qxl -vnc :21 -cdrom ubuntu-18.04-desktop-amd64.iso

Attaching like:
$ vncviewer FullColor=1 AutoSelect=0 10.245.168.42:5921
(alternatives on tigervnc)
Well for me it had "-k de" as well :-)

Then boot into the "try Ubuntu" live CD mode.
There opened a terminal to loop on xrandr.

Running the loop of above in that guest to crash it after a while.


Upgrade to proposed:
$ sudo apt install qemu-system-x86=1:2.11+dfsg-1ubuntu7.5
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  samba vde2 qemu-block-extra sgabios ovmf
The following packages will be upgraded:
  qemu-system-x86
1 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Need to get 5.168 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
qemu-system-x86 amd64 1:2.11+dfsg-1ubuntu7.5 [5.168 kB]
Fetched 5.168 kB in 1s (7.666 kB/s)  
(Reading database ... 127990 files and directories currently installed.)
Preparing to unpack .../qemu-system-x86_1%3a2.11+dfsg-1ubuntu7.5_amd64.deb ...
Unpacking qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) over 
(1:2.11+dfsg-1ubuntu7.4) ...
Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...


Running the loop again with the same setup  - no crash in 15 minutes - assume 
that means good now.
I'd be glad about someone else checking the result as well, best someone 
formerly affected by it.
(and having a tick in the eye for seeing my right screen change sizes and 
flicker all the time)

Setting verified

** Tags removed: verification-needed
** Tags added: verification-done

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * There are conditions where the vga/qxl driver can crash the qemu 
 process.

   * It is like a very complex case of a non initialized var - without the 
 fix it might try to ask for updates without having a valid primary 
 surface.

   * Backport from upstream
  
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
  to avoid the crash

  
  [Test Case]

   * Sometimes booting xubuntu was reported to be enough, at other times
  it was needed to change resolution a few times to trigger.

# get xubuntu iso (actually other UI Isos should do as well)
$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
# If it boots successfully, change resolution until it crashes.
$ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done

   * Without the fix that will trigger the qemu crash

  [Regression Potential]

   * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
 the rendering update. That sounds rather safe. But thinking hard on 
 potential updates I could think of theoretical setups that were  in 
 undefined mode all the time (unlikely or impossible I think) that now 
 would get no updates anymore. Well I really don't think this is an 
 issue, but since this section should be open thinking on "potential" 
 regressions that is what comes to my mind.

  [Other Info]
   
   * Thanks to Leonardo for most of the bisecting and discussion work!

  
  ---

  
  When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Note: The code change already passed the general regression checks on
the identical content against a PPA (Also on the weekend prior to the
full maturing period I'll have another automated run on proposed).

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * There are conditions where the vga/qxl driver can crash the qemu 
 process.

   * It is like a very complex case of a non initialized var - without the 
 fix it might try to ask for updates without having a valid primary 
 surface.

   * Backport from upstream
  
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
  to avoid the crash

  
  [Test Case]

   * Sometimes booting xubuntu was reported to be enough, at other times
  it was needed to change resolution a few times to trigger.

# get xubuntu iso (actually other UI Isos should do as well)
$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
# If it boots successfully, change resolution until it crashes.
$ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done

   * Without the fix that will trigger the qemu crash

  [Regression Potential]

   * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
 the rendering update. That sounds rather safe. But thinking hard on 
 potential updates I could think of theoretical setups that were  in 
 undefined mode all the time (unlikely or impossible I think) that now 
 would get no updates anymore. Well I really don't think this is an 
 issue, but since this section should be open thinking on "potential" 
 regressions that is what comes to my mind.

  [Other Info]
   
   * Thanks to Leonardo for most of the bisecting and discussion work!

  
  ---

  
  When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

** Description changed:

- When using qemu-system-x86_64 with the option -vga qxl, it crashes. The
- easiest way to crash it is by trying to change the guest's resolution.
- However, the system may randomly crash too, not happening only when
- changing resolution. Here is the terminal output of one of these random
- crashes:
+ [Impact]
+ 
+  * There are conditions where the vga/qxl driver can crash the qemu 
+process.
+ 
+  * It is like a very complex case of a non initialized var - without the 
+fix it might try to ask for updates without having a valid primary 
+surface.
+ 
+  * Backport from upstream
+ 
https://git.qemu.org/?p=qemu.git;a=commit;h=5bd5c27c7d284d01477c5cc022ce22438c46bf9f
+ to avoid the crash
+ 
+ 
+ [Test Case]
+ 
+  * Sometimes booting xubuntu was reported to be enough, at other times
+ it was needed to change resolution a few times to trigger.
+ 
+   # get xubuntu iso (actually other UI Isos should do as well)
+   $ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 
-m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso
+   # If it boots successfully, change resolution until it crashes.
+   $ while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; 
xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 
--mode 1920x1080 ; sleep 1 ; done
+ 
+  * Without the fix that will trigger the qemu crash
+ 
+ [Regression Potential]
+ 
+  * The change "just" adds QXL_MODE_UNDEFINED as one more trigger to leave 
+the rendering update. That sounds rather safe. But thinking hard on 
+potential updates I could think of theoretical setups that were  in 
+undefined mode all the time (unlikely or impossible I think) that now 
+would get no updates anymore. Well I really don't think this is an 
+issue, but since this section should be open thinking on "potential" 
+regressions that is what comes to my mind.
+ 
+ [Other Info]
+  
+  * Thanks to Leonardo for most of the bisecting and discussion work!
+ 
+ 
+ ---
+ 
+ 
+ When using qemu-system-x86_64 with the option -vga qxl, it crashes. The 
easiest way to crash it is by trying to change the guest's resolution. However, 
the system may randomly crash too, not happening only when changing resolution. 
Here is the terminal output of one of these random crashes:
  
  
  
  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.
+  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.
  
  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)
  
- 
- (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0
+ (process:21313): Spice-WARNING **: 16:01:45.759: display-
+ channel.c:2432:display_channel_validate_surface: failed on 0
  
  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)
  
  
  
  I was running QEMU as a normal user which is on the groups kvm and disk.
  Initially I supposed the problem was because I was running QEMU as root,
  but as a normal user this happens too.
  
  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.
  
  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
-  () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
-  () at 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Working on Bionic SRu prep in https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3367/+packages

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Triaged

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Christian Ehrhardt]

On Mon, Aug 20, 2018 at 9:51 PM Phillip Susi  wrote:

> On 8/20/2018 11:07 AM, Christian Ehrhardt wrote:
> > What exactly would you need in Ubuntu Phillp?
>
> It *looks* like this is fixed in 2.12, but Ubuntu has 2.11.
>
> > Latest qemu would atm be on 2.12 with the git available here [1].
> > Unfortunately mostly nobody cares about the git branches so I forgot to
> > push this one - shame on me :-/, it is ready now thou.
>
> What did you forget to push?  Because the debian git repo already seemd
> to have 2.12 last week.
>

I forgot to push the git branch for 2.12 when I uploaded the package itself
on 2018-07-20

Ubuntu cosmic (18.10) has qemu 2.12 as of ~4 weeks ago as well.
Once Cosmic is released there will be a 2.12 via the Ubuntu Cloud Archive
[1] available into Bionic as well.

[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive


> > I couldn't follow all of the thread, do you need something else than qemu
> > code to be updated, if so which package would that be?
>
> Nope; it's just qemu 2.11 seems to have had this bug.  It seems there
> has been massive refactoring of the keyboard code since then so likely
> this bug will forever remain in 18.04 unless someone wants to go through
> the 2.11 code and figure out how to surgically fix it.  At this point I
> think the path of least resistance for me is to get the newer version in
> the debian git repo to build and install that.
>

Yeah unless one does volunteer to identify the single change or it becomes
a problem for more of the community it is unlikely to be changed in the
2.11 in Ubuntu Bionic.


> What I can't figure out is how to get the pristine-tar for
> dpkg-buildpackage.  The git repo doesn't contain the pristine-tar branch
> that was required for pristine-tar to check out the original tar.
>

I thought the salsa repo should have the pristine-tar branch which is valid
for Debian and Ubuntu.
But you are right it doesn't, any Ubuntu package in main will have a repo
per package following this scheme
  git://git.launchpad.net/~usd-import-team/ubuntu/+source/qemu
including pristine-tar branches for Debian as well as Ubuntu.

Worst case run a "pull-lp-source" and you'll get all you need (but without
git history)

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] Pipe key broken on US keyboards

[Christian Ehrhardt]

On Mon, Aug 20, 2018 at 4:32 PM Phillip Susi  wrote:

> On 8/20/2018 4:43 AM, Gerd Hoffmann wrote:
> > There have been fixes for that one, specifically recent qemu will look
> > at modifier state in addition to the keysym when looking up the keycode,
> > because some keymaps can generate the same keysym with different key
> > combinations, and most of the time they have different modifier state.
>
> Yea, I saw that code, so the new version probably works if I could
> figure out how to get the package to build.  I'm not sure why Ubuntu is
> on such an old version.  I just cloned the debain git repo to start
> poking around and assumed that was what was in Ubuntu.
>

What exactly would you need in Ubuntu Phillp?
Latest qemu would atm be on 2.12 with the git available here [1].
Unfortunately mostly nobody cares about the git branches so I forgot to
push this one - shame on me :-/, it is ready now thou.

I couldn't follow all of the thread, do you need something else than qemu
code to be updated, if so which package would that be?

[1]: https://salsa.debian.org/qemu-team/qemu/commits/ubuntu-cosmic-2.12

[Qemu-devel] [Bug 1484990] Re: fsfreeze-hook script should also ignored dpkg generated files

[ Christian Ehrhardt ]

Yeah I even got help back then to make sure CCs are better but nothing happened.
Old thread: 
http://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg02142.html

I re-pinged on the old thread to be reconsidered.
New Ping: http://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg03892.html

Thanks Thomas for making me aware this was still lingering unresolved.

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

Title:
  fsfreeze-hook script should also ignored dpkg generated files

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Fix Released

Bug description:
  Hello,

  In the fsfreeze-hook script, the following code check if some of the
  files should be ignored:

  
  # Check whether file $1 is a backup or rpm-generated file and should be 
ignored
  is_ignored_file() {
  case "$1" in
  *~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample)
  return 0 ;;
  esac
  return 1
  }

  The functions should probably also skip dpkg generated files.

  I've found a list of the different extensions in the systemd source
  tree:
  https://github.com/systemd/systemd/blob/master/src/basic/util.c#L1871

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

Re: [Qemu-devel] [PATCH] qemu-guest-agent: freeze-hook to ignore dpkg files as well

[Christian Ehrhardt]

On Thu, May 10, 2018 at 8:47 PM Philippe Mathieu-Daudé 
wrote:

> Hi Paolo,
>
> On 04/24/2018 10:01 PM, Philippe Mathieu-Daudé wrote:
> > Hi Christian,
> >
> > On 04/09/2018 04:18 AM, Christian Ehrhardt wrote:
> >> Re-Ping for consideration?
> >>
> >> On Mon, Jan 22, 2018 at 3:03 PM, Christian Ehrhardt <
> >> christian.ehrha...@canonical.com> wrote:
> >>
> >>> Hi,
> >>> maybe I missed a formal thing on this submission, but I don't see it
> right
> >>> away.
> >
> > You missed to Cc the maintainer of this file:
> >
> > $ ./scripts/get_maintainer.pl -f scripts/qemu-guest-agent/fsfreeze-hook
> > Michael Roth  (maintainer:QEMU Guest Agent)
> >
> > (I Cc'ed him).
> >
> > See
> https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer
> >
> >>> So for now just a ping on any updates in regard to accept this?
> >>>
> >>> On Wed, Dec 13, 2017 at 11:17 AM, Christian Ehrhardt
> >>>  wrote:
> >>>> The hook already skips a set of rpm upgrade artifacts.
> >>>> Do the same with such files that might be created by dpkg.
> >>>>
> >>>> Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1484990
> >>>>
> >>>> Signed-off-by: Christian Ehrhardt 
> >
> > Reviewed-by: Philippe Mathieu-Daudé 
>
> Can you take this patch via your MISC tree?
>

Even after Philippe back then helped to make sure CCs are better nothing
happened.
Therefore kindly re-ping for this to be included.


>
> >>>> ---
> >>>>  scripts/qemu-guest-agent/fsfreeze-hook | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/scripts/qemu-guest-agent/fsfreeze-hook
> >>> b/scripts/qemu-guest-agent/fsfreeze-hook
> >>>> index c27b29f..13aafd4 100755
> >>>> --- a/scripts/qemu-guest-agent/fsfreeze-hook
> >>>> +++ b/scripts/qemu-guest-agent/fsfreeze-hook
> >>>> @@ -13,7 +13,7 @@ FSFREEZE_D=$(dirname -- "$0")/fsfreeze-hook.d
> >>>>  # Check whether file $1 is a backup or rpm-generated file and should
> be
> >>> ignored
> >>>>  is_ignored_file() {
> >>>>  case "$1" in
> >>>> -*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave |
> >>> *.sample)
> >>>> +*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave |
> >>> *.sample | *.dpkg-old | *.dpkg-new | *.dpkg-tmp | *.dpkg-dist |
> *.dpkg-bak
> >>> | *.dpkg-backup | *.dpkg-remove)
> >>>>  return 0 ;;
> >>>>  esac
> >>>>  return 1
> >>>> --
> >>>> 2.7.4
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

** Changed in: qemu (Ubuntu Bionic)
   Status: New => Triaged

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Bionic:
  Triaged

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

Prior to the update:

$ virsh domfsfreeze x-freeze; virsh domfsthaw x-freeze
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 
'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy

Thawed 0 filesystem(s)


$ sudo apt install qemu-guest-agent
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  qemu-guest-agent
1 upgraded, 0 newly installed, 0 to remove and 27 not upgraded.
Need to get 132 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/universe amd64 
qemu-guest-agent amd64 1:2.5+dfsg-5ubuntu10.31 [132 kB]
Fetched 132 kB in 0s (1.161 kB/s)
(Reading database ... 54125 files and directories currently installed.)
Preparing to unpack .../qemu-guest-agent_1%3a2.5+dfsg-5ubuntu10.31_amd64.deb ...
Unpacking qemu-guest-agent (1:2.5+dfsg-5ubuntu10.31) over 
(1:2.5+dfsg-5ubuntu10.30) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu21.2) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up qemu-guest-agent (1:2.5+dfsg-5ubuntu10.31) ...


Retesting the above:
$ virsh domfsfreeze x-freeze; virsh domfsthaw x-freeze
Froze 1 filesystem(s)

Thawed 1 filesystem(s)


Found no other hickups due to the update, setting verified.

** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * backport upstream fix to avoid double unmounts (e.g. bind mounts)
     hanging the freeze action.

  [Test Case]

   * Prepare a guest
     $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
  uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily

   * Shut it down and use virsh edit to add a channel for the agent. Add this 
somewhere under :
  
     
     
  

    * Start the guest again, in it install qemu-guest-agent

    *

    * On the Host then freeze and thaw the guest
  $ virsh domfsfreeze x-freeze
  $ virsh domfsthaw x-freeze

    # The above works, then trigger the issue, in the guest do
  $ sudo mkdir /mnt/test
  $ sudo mount -o bind / /mnt/test/

    * Now the freeze/thaw will fail unless the fix is applied to the
  guest.

  [Regression Potential]

   * From looking at the code alone I could think of a different cause that
     makes it return EBUSY.
     The biggest risk I could see due to that is the agent reporting a
     successful freeze due to accepting EBUSY which is not actually true.
     But we have that in Ubuntu since Artful and
     upstream since January 2017 and there are no such reports.

  [Other Info]

   * n/a

  ---

  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.

  Below more information about how we encountered this issue...

  Message send to qemu-disc...@nongnu.org:

  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.

  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"

  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:

  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

  This is the only entry of the qemu guest agent in syslog.

  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0

  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Bionic:
  New

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

Tests are all ok, MP review was acked and case confirmed.
No Security Update since then in between, so sponsoring into SRU queue now ...

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * backport upstream fix to avoid double unmounts (e.g. bind mounts)
     hanging the freeze action.

  [Test Case]

   * Prepare a guest
     $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
  uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily

   * Shut it down and use virsh edit to add a channel for the agent. Add this 
somewhere under :
  
     
     
  

    * Start the guest again, in it install qemu-guest-agent

    *

    * On the Host then freeze and thaw the guest
  $ virsh domfsfreeze x-freeze
  $ virsh domfsthaw x-freeze

    # The above works, then trigger the issue, in the guest do
  $ sudo mkdir /mnt/test
  $ sudo mount -o bind / /mnt/test/

    * Now the freeze/thaw will fail unless the fix is applied to the
  guest.

  [Regression Potential]

   * From looking at the code alone I could think of a different cause that
     makes it return EBUSY.
     The biggest risk I could see due to that is the agent reporting a
     successful freeze due to accepting EBUSY which is not actually true.
     But we have that in Ubuntu since Artful and
     upstream since January 2017 and there are no such reports.

  [Other Info]

   * n/a

  ---

  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.

  Below more information about how we encountered this issue...

  Message send to qemu-disc...@nongnu.org:

  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.

  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"

  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:

  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

  This is the only entry of the qemu guest agent in syslog.

  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0

  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }

  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
   may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.

  Piece of reply 2:
  -
  Ok, that seems to be it.

  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Nice, thanks Leonardo for the Bisect - lets call upstream Fixed
Committed then (as there is no 2.13 released yet).

For the separate gl discussion feel free to subscribe/chime in on bug
1657409

Currently 2.12 is on its way into Cosmic.
I'll add and test that patch afterwards, it looks small and safe to me.

** Changed in: qemu
   Status: New => Fix Committed

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Triaged

** Tags added: qemu-18.10 server-next

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Yeah we switched to gtk.
With OpenGL which do you mean - the virtgl based support or some other config 
option?

Since it still fails to reproduce for me, but you already have a self build 
qemu that is good.
Could you based on this build 2.12 from source as well and confirm that it 
fails.
If it does you could bisect from 2.12 to master what fixed it so that we can 
consider that patch.
Otherwise if 2.12 from source in your own build works lets take a look at the 
build options that you mentioned.

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

** Description changed:

  [Impact]
  
-  * An explanation of the effects of the bug on users and
- 
-  * justification for backporting the fix to the stable release.
- 
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
+  * backport upstream fix to avoid double unmounts (e.g. bind mounts) 
+hanging the freeze action.
  
  [Test Case]
  
   * Prepare a guest
     $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
  uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily
  
   * Shut it down and use virsh edit to add a channel for the agent. Add this 
somewhere under :
  
     
     
  
  
    * Start the guest again, in it install qemu-guest-agent
  
    *
  
    * On the Host then freeze and thaw the guest
  $ virsh domfsfreeze x-freeze
  $ virsh domfsthaw x-freeze
  
    # The above works, then trigger the issue, in the guest do
  $ sudo mkdir /mnt/test
  $ sudo mount -o bind / /mnt/test/
  
    * Now the freeze/thaw will fail unless the fix is applied.
  
  [Regression Potential]
  
   * From looking at the code alone I could think of a different cause that
     makes it return EBUSY.
     The biggest risk I could see due to that is the agent reporting a
     successful freeze due to accepting EBUSY which is not actually true.
     But we have that in Ubuntu since Artful and
     upstream since January 2017 and there are no such reports.
  
  [Other Info]
  
   * n/a
  
  ---
  
  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)
  
  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.
  
  Below more information about how we encountered this issue...
  
  Message send to qemu-disc...@nongnu.org:
  
  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.
  
  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"
  
  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:
  
  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called
  
  This is the only entry of the qemu guest agent in syslog.
  
  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0
  
  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }
  
  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1
  
  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
   may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.
  
  Piece of reply 2:
  -
  Ok, that seems to be it.
  
  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * backport upstream fix to avoid double unmounts (e.g. bind mounts) 
 hanging the freeze action.

  [Test Case]

   * Prepare a guest
     $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
  uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily

   * Shut it down and use 

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Link is better as https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3306

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

[ Christian Ehrhardt ]

Very interesting, Still not triggering for me :-/
Could you check if the PPA in [1] (with qemu 2.12 planned for Cosmic) already 
fixes it for you?

[1]: https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3306/+packages

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

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' 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.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

** Changed in: qemu (Ubuntu Xenial)
   Status: Confirmed => In Progress

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

  [Test Case]

   * Prepare a guest
 $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
  uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily

   * Shut it down and use virsh edit to add a channel for the agent
  
 
 
  

* Start the guest again, in it install qemu-guest-agent

*

* On the Host then freeze and thaw the guest
  $ virsh domfsfreeze x-freeze
  $ virsh domfsthaw x-freeze

# The above works, then trigger the issue, in the guest do
  $ sudo mkdir /mnt/test
  $ sudo mount -o bind / /mnt/test/

* Now the freeze/thaw will fail unless the fix is applied.

  [Regression Potential]

   * From looking at the code alone I could think of a different cause that 
 makes it return EBUSY.
 The biggest risk I could see due to that is the agent reporting a 
 successful freeze due to accepting EBUSY which is not actually true.
 But we have that in Ubuntu since Artful and 
 upstream since January 2017 and there are no such reports.

  [Other Info]
   
   * n/a

  
  ---

  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.

  Below more information about how we encountered this issue...

  Message send to qemu-disc...@nongnu.org:

  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.

  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"

  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:

  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

  This is the only entry of the qemu guest agent in syslog.

  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0

  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }

  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
   may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.

  Piece of reply 2:
  -
  Ok, that seems to be it.

  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

** Description changed:

+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+ 
+ [Test Case]
+ 
+  * Prepare a guest
+$ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
+ uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial 
label=daily
+ 
+  * Shut it down and use virsh edit to add a channel for the agent
+ 
+
+
+ 
+ 
+   * Start the guest again, in it install qemu-guest-agent
+ 
+   *
+ 
+   * On the Host then freeze and thaw the guest
+ $ virsh domfsfreeze x-freeze
+ $ virsh domfsthaw x-freeze
+ 
+   # The above works, then trigger the issue, in the guest do
+ $ sudo mkdir /mnt/test
+ $ sudo mount -o bind / /mnt/test/
+ 
+   * Now the freeze/thaw will fail unless the fix is applied.
+ 
+ [Regression Potential]
+ 
+  * From looking at the code alone I could think of a different cause that 
+makes it return EBUSY.
+The biggest risk I could see due to that is the agent reporting a 
+successful freeze due to accepting EBUSY which is not actually true.
+But we have that in Ubuntu since Artful and 
+upstream since January 2017 and there are no such reports.
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ 
+ ---
+ 
  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)
  
  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.
- 
  
  Below more information about how we encountered this issue...
  
  Message send to qemu-disc...@nongnu.org:
  
  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.
  
  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"
  
  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:
  
  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called
  
  This is the only entry of the qemu guest agent in syslog.
  
  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0
  
  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }
  
  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1
  
  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
-  may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.
+  may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.
  
  Piece of reply 2:
  -
  Ok, that seems to be it.
  
  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

  [Test Case]

   * 

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

Steps to reproduce

uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial label=daily

Add this to the guest definition and restart it

   
   


>From the host freeze and thaw it:
$ virsh domfsfreeze x-freeze
$ virsh domfsthaw x-freeze

# The above works

In the Guest then add a bind mount to trigger the issue
$ sudo mkdir /mnt/test
$ sudo mount -o bind / /mnt/test/

Then again try to freeze/unfreeze
$ virsh domfsfreeze x-freeze
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 
'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy


I installed a fix from my PPA [1] and with that it works just fine now.
Proposing an MP for review by the team, to afterwards move on into SRU 
processing.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3310

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Confirmed

Bug description:
  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.

  
  Below more information about how we encountered this issue...

  Message send to qemu-disc...@nongnu.org:

  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.

  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"

  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:

  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

  This is the only entry of the qemu guest agent in syslog.

  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0

  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }

  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
   may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.

  Piece of reply 2:
  -
  Ok, that seems to be it.

  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

[Qemu-devel] [Bug 474968] Re: kvm smb server hogs cpu guest freeze

[ Christian Ehrhardt ]

Clearing old bugs: No more occurring in any of my recent KVMs, setting
this old bug to incomplete.

** Changed in: qemu-kvm (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  kvm smb server hogs cpu guest freeze

Status in QEMU:
  Won't Fix
Status in qemu-kvm package in Ubuntu:
  Incomplete

Bug description:
  Binary package hint: qemu-kvm

  kvm hogs the CPU reproducibly. I installed an Ubuntu using KVM. I run
  the machine with -net nic,model=rtl8139,macaddr=f0:00:BA:12:34:56 -net
  user,hostfwd=tcp::2223-:22,smb=/tmp/share, sshed into the machine and
  typed "telnet 10.0.2.4 139" to try whether the SMB server works. KVM
  then hogs the CPU.

  ProblemType: Bug
  Architecture: amd64
  Date: Thu Nov  5 01:23:09 2009
  DistroRelease: Ubuntu 9.10
  KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
  MachineType: LENOVO 766636G
  Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3
  PccardctlIdent:
   Socket 0:
 no product info available
  PccardctlStatus:
   Socket 0:
 no card
  ProcCmdLine: root=/dev/mapper/cryptroot 
source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro quiet splash  
crashkernel=384M-2G:64M,2G-:128M
  SourcePackage: qemu-kvm
  Uname: Linux 2.6.32-999-generic x86_64
  dmi.bios.date: 07/01/2008
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 7NETB6WW (2.16 )
  dmi.board.name: 766636G
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Available
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvr7NETB6WW(2.16):bd07/01/2008:svnLENOVO:pn766636G:pvrThinkPadX61s:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 766636G
  dmi.product.version: ThinkPad X61s
  dmi.sys.vendor: LENOVO

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

[Qemu-devel] [Bug 1129571] Re: libreoffice armhf FTBFS

[ Christian Ehrhardt ]

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

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

Title:
  libreoffice armhf FTBFS

Status in QEMU:
  Won't Fix
Status in qemu package in Ubuntu:
  Incomplete

Bug description:
  We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in
  the launchpad buildds. We believe this is likely due to an error in
  qemu.

  While we do not have a small test case yet, we do have a build log
  (attaching here).

  The relevant snippet from the build log is:

  
3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar"
 com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir 
../../unxlngr.pro/misc/ziptmpswriter_cs -o 
../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro
  dmake:  Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip'

  We believe this is from bash error code 128 + 4, where 4 is illegal
  instruction, thus leading us to suspect qemu.

  Any help in tracking this down would be appreciated.

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

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

[ Christian Ehrhardt ]

Fix is known and seems backportable, marking as server-next and subscribing for 
somebody to take a look.
Also as mentioned it is in 2.9, so newer releases are already fixed.

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu)
   Status: New => Fix Released

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Confirmed

** Tags added: server-next

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

Title:
  btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Confirmed

Bug description:
  Having two mounts of the same device makes fsfreeze through qemu-ga 
impossible.
  root@CmsrvMTA:/# mount -l | grep /dev/vda2
  /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
  /dev/vda2 on /home type btrfs 
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

  Having two mounts is rather common with btrfs, so the feature fsfreeze
  is unusable on these systems.

  
  Below more information about how we encountered this issue...

  Message send to qemu-disc...@nongnu.org:

  Message 1:
  --
  I use external snapshots to backup my guests. I use the 'quiesce' option to 
flush and frees the guest file system with the qemu guest agent.

  With the exeption of one guest, this procedure works fine. On the 'unwilling' 
guest, I get this error message:
  "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: 
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze 
/: Device or resource busy"

  I don't think this is not some sort of time-out error, because
  activation of the fsfreeze and the error message happen immediately
  after each other:

  $ grep qemu-ga syslog.1
  May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

  This is the only entry of the qemu guest agent in syslog.

  $ sudo virsh version
  Compiled against library: libvirt 1.3.1
  Using library: libvirt 1.3.1
  Gebruikte API: QEMU 1.3.1
  Draaiende hypervisor: QEMU 2.5.0

  $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
  {"return":{"version":"2.5.0", ... 
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
 ... }

  For making an external snapshot, I use this command:
  $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic 
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

  Piece of reply 1:
  -
  I have encountered this before. Some operating systems
   may have bind-mounts that let a device appear multiple times in the mount 
list. Unfortunately the guest agent is not smart enough to consider a device 
that has been frozen as succesfull and keep going. This causes this specific 
error.

  Piece of reply 2:
  -
  Ok, that seems to be it.

  I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
  two separate sub volumes.

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

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

[Christian Ehrhardt]

>
> I will provide all necessary info. Unfortunately the smallest image I can
> provide is around 10M.
>
> What is M1/M2/M3 L1/L2/L3 file?
>

Just a suggestion how you could name the files
Linux-at-step-1 would be L1 and similar.

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

[ Christian Ehrhardt ]

Can this be done with like a 1M example file that you could copy off in
all stages.

Provide the commands you use like
1. create
2. do ??
3. convert

Then for Mac and Linux you'd have M1/M2/M3 L1/L2/L3 files that can all
be attached here to be evaluated for what might be broken.

IMHO In the current state there is neither enough data for good
debugging, not enough steps to reproduce what exactly you faced.

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

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

[Qemu-devel] [Bug 1769053] Re: Ability to control phys-bits through libvirt

[ Christian Ehrhardt ]

** Merge proposal unlinked:
   
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347801

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

Title:
  Ability to control phys-bits through libvirt

Status in libvirt:
  Unknown
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1769053] Re: Ability to control phys-bits through libvirt

[ Christian Ehrhardt ]

** Merge proposal unlinked:
   
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347801

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

Title:
  Ability to control phys-bits through libvirt

Status in libvirt:
  Unknown
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1769053] Re: Ability to control phys-bits through libvirt

[ Christian Ehrhardt ]

** Merge proposal unlinked:
   
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347796

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

Title:
  Ability to control phys-bits through libvirt

Status in libvirt:
  Unknown
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM

[ Christian Ehrhardt ]

Since all but the libvirt task to expose these are set to invalid in
regard to the issue here I'm changing the title accordingly.

As a short term solution for Ubuntu users I forked bug 1776189 to
provide a machine type based solution until this here is implemented and
widely available and exploited.

** Summary changed:

- Cannot start a guest with more than 1TB of RAM
+ Ability to control phys-bits through libvirt

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

Title:
  Ability to control phys-bits through libvirt

Status in libvirt:
  Unknown
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1077116] Re: automoc4 segfaults when building in an armhf pbuilder on an amd64 host

[ Christian Ehrhardt ]

We have had a few more issues around armhf qemu-static that mostly resolved in 
Artful (qemu 2.10) and finally one that was good in Bionic (qemu 2.11).
This also included some updates to other components but should be good now.

If the issue here really still applies to a newer version please reopen
and state an updated test and version that it ran on.

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  automoc4 segfaults when building in an armhf pbuilder on an amd64 host

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released

Bug description:
  When trying to build kde4libs in an armhf pbuilder created with the
  pbuilder-scripts running on an amd64 host automoc4 recieves a
  segmentation fault and I can't get any useful information out of it:

  root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# /usr/bin/automoc4 
kdeui_automoc.cpp ../../kdeui/ . moc-qt4 cmake
  unable to dump 00102c00
  Segmentation fault (core dumped)
  root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# gdb /usr/bin/automoc4 
qemu_automoc4_20121108-211818_15839.core  
  GNU gdb (GDB) 7.5-ubuntu
  Copyright (C) 2012 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "arm-linux-gnueabihf".
  For bug reporting instructions, please see:
  ...
  Reading symbols from /usr/bin/automoc4...done.
  BFD: Warning: 
/tmp/kde4libs-4.9.3/build/kdeui/qemu_automoc4_20121108-211818_15839.core is 
truncated: expected core file size >= 5150720, found: 974848.
  [New LWP 15839]
  [New LWP 15866]
  Cannot access memory at address 0xf67fe954
  Cannot access memory at address 0xf67fe950
  (gdb) bt
  #0  0xf6630306 in ?? ()
  #1  0xf6415ff8 in ?? ()
  #2  0xf6415ff8 in ?? ()
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) 

  automoc4 runs fine when building on a nexus7 so this sounds like an issue in 
qemu.
  Tested in quantal and raring.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: qemu-user-static 1.2.0-2012.09-0ubuntu1
  Uname: Linux 3.6.2-030602-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.6.2-0ubuntu3
  Architecture: amd64
  Date: Fri Nov  9 19:29:28 2012
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2011-10-08 (398 days ago)
  InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007)
  MarkForUpload: True
  ProcEnviron:
   SHELL=/bin/bash
   TERM=xterm
   PATH=(custom, user)
   LANG=en_US.UTF-8
   LANGUAGE=en_US.UTF-8
  SourcePackage: qemu-linaro
  UpgradeStatus: No upgrade log present (probably fresh install)

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

[Qemu-devel] [Bug 1722074] Re: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

[ Christian Ehrhardt ]

Hi,
this is not a show stopper at all.
It is just a warning and it is fine.
It is a trade-off between the "ease to use nested virt" vs "this warning".
For example on an intel chip you'd get:
  qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.8001H:ECX.svm
And that as well is no issue.

Since this is Ubuntu downstream decision to prefer simplicity for nested
virt I marked upstream qemu task invalid. There you'd not see the
warning, but instead would have to jump a few extra whoops to get
nesting working.

And finally, this code really is like that for longer than I take a look at it, 
so it might be that today one could solve it differently. There could be much 
more magic code to make it work as comfortable on both platforms and avoid the 
warning, but honestly - it wasn't an issue for many years, and I think it still 
is none.
So for the Ubuntu portion, I'll set confirmed+low(est) prio until it is clear 
that this really breaks something it didn't in the past years.

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

** Changed in: qemu (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: qemu (Ubuntu)
   Importance: Wishlist => Low

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

Title:
  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

Status in QEMU:
  Invalid
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  
  I encountered the bug today (when using qemu to boot up images - which used 
to work on my Intel CPU box):

  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

  The bug is a show-stopper - I completely cannot load my kernel images
  at all.

  My Ubuntu have this version of QEMU installed:

  qemu-system-x86_64 --version

  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16),
  Copyright (c) 2003-2008 Fabrice Bellard

  And PC is a AMD Ryzen7 CPU built, and this is the first time I am
  using it to load QEMU images.   My host information:

  cat /proc/cpuinfo |more

  processor : 0
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB
  physical id   : 0
  siblings  : 16
  core id   : 0
  cpu cores : 8
  apicid: 0
  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 extd_apicid aperfmperf pni 
pclmulqdq
  monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand 
lahf
  _lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw s
  kinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx 
hw_pstate
  vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni 
xsaveopt
  xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save 
tsc_scale v
  mcb_clean flushbyasid decodeassists pausefilter pfthreshold avic 
overflow_recov
  succor smca
  bugs  : fxsave_leak sysret_ss_attrs null_seg
  bogomips  : 6787.24
  TLB size  : 2560 4K pages
  clflush size  : 64
  cache_alignment   : 64
  address sizes : 48 bits physical, 48 bits virtual
  power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

  processor : 1
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB

  From other places, it can be seen that this is an AMD CPU issue:

  https://www.virtualmin.com/node/52227

  not sure?

  The bug will also affect the host negatively:  it will completely go
  into a hung mode - the entire host becomes completely unsable.

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

[Qemu-devel] [Bug 1722074] Re: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

[ Christian Ehrhardt ]

And sorry for the status update noise, one can clearly see that I start
to fail once I have to use my mouse :-)

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

Title:
  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

Status in QEMU:
  Invalid
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  
  I encountered the bug today (when using qemu to boot up images - which used 
to work on my Intel CPU box):

  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

  The bug is a show-stopper - I completely cannot load my kernel images
  at all.

  My Ubuntu have this version of QEMU installed:

  qemu-system-x86_64 --version

  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16),
  Copyright (c) 2003-2008 Fabrice Bellard

  And PC is a AMD Ryzen7 CPU built, and this is the first time I am
  using it to load QEMU images.   My host information:

  cat /proc/cpuinfo |more

  processor : 0
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB
  physical id   : 0
  siblings  : 16
  core id   : 0
  cpu cores : 8
  apicid: 0
  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 extd_apicid aperfmperf pni 
pclmulqdq
  monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand 
lahf
  _lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw s
  kinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx 
hw_pstate
  vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni 
xsaveopt
  xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save 
tsc_scale v
  mcb_clean flushbyasid decodeassists pausefilter pfthreshold avic 
overflow_recov
  succor smca
  bugs  : fxsave_leak sysret_ss_attrs null_seg
  bogomips  : 6787.24
  TLB size  : 2560 4K pages
  clflush size  : 64
  cache_alignment   : 64
  address sizes : 48 bits physical, 48 bits virtual
  power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

  processor : 1
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB

  From other places, it can be seen that this is an AMD CPU issue:

  https://www.virtualmin.com/node/52227

  not sure?

  The bug will also affect the host negatively:  it will completely go
  into a hung mode - the entire host becomes completely unsable.

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

[Qemu-devel] [Bug 1722074] Re: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

[ Christian Ehrhardt ]

** Also affects: qemu (Ubuntu)
   Importance: Undecided
   Status: New

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

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

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

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

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

Title:
  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

Status in QEMU:
  Invalid
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  
  I encountered the bug today (when using qemu to boot up images - which used 
to work on my Intel CPU box):

  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

  The bug is a show-stopper - I completely cannot load my kernel images
  at all.

  My Ubuntu have this version of QEMU installed:

  qemu-system-x86_64 --version

  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16),
  Copyright (c) 2003-2008 Fabrice Bellard

  And PC is a AMD Ryzen7 CPU built, and this is the first time I am
  using it to load QEMU images.   My host information:

  cat /proc/cpuinfo |more

  processor : 0
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB
  physical id   : 0
  siblings  : 16
  core id   : 0
  cpu cores : 8
  apicid: 0
  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 extd_apicid aperfmperf pni 
pclmulqdq
  monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand 
lahf
  _lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw s
  kinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx 
hw_pstate
  vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni 
xsaveopt
  xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save 
tsc_scale v
  mcb_clean flushbyasid decodeassists pausefilter pfthreshold avic 
overflow_recov
  succor smca
  bugs  : fxsave_leak sysret_ss_attrs null_seg
  bogomips  : 6787.24
  TLB size  : 2560 4K pages
  clflush size  : 64
  cache_alignment   : 64
  address sizes : 48 bits physical, 48 bits virtual
  power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

  processor : 1
  vendor_id : AuthenticAMD
  cpu family: 23
  model : 1
  model name: AMD Ryzen 7 1700X Eight-Core Processor
  stepping  : 1
  microcode : 0x800110e
  cpu MHz   : 2200.000
  cache size: 512 KB

  From other places, it can be seen that this is an AMD CPU issue:

  https://www.virtualmin.com/node/52227

  not sure?

  The bug will also affect the host negatively:  it will completely go
  into a hung mode - the entire host becomes completely unsable.

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

[Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM

[ Christian Ehrhardt ]

Reported to upstream libvirt's BZ with the suggestions of Daniel Berrage
and David Alan Glibert; now available at [1] I linked that up in the LP
bug status so that we auto-track this.

As eventually this has to go upstream using the bug tracker should
better ensure that there is no concurrent conflicting work (or opinion)
on it.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1578278

** Bug watch added: Red Hat Bugzilla #1578278
   https://bugzilla.redhat.com/show_bug.cgi?id=1578278

** Also affects: libvirt via
   https://bugzilla.redhat.com/show_bug.cgi?id=1578278
   Importance: Unknown
   Status: Unknown

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

Title:
  Cannot start a guest with more than 1TB of RAM

Status in libvirt:
  Unknown
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM

[ Christian Ehrhardt ]

Actually the qemu tasks are "invalid" not "incomplete" as they currently
are - after our discussions here it seems we agreed that qemu is doing
what is intended (and the reasons why larger bits are not the default).
Therefore set the status to that for the qemu tasks.

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

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

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

Title:
  Cannot start a guest with more than 1TB of RAM

Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

[Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM

[ Christian Ehrhardt ]

Crit prio on Qemu which was explained to work just fine is not correct IMHO.
After checking with David he meant to want to raise the prio on the suggested 
libvirt extensions instead. I'm re-triaging this bug for that and will ping 
David Berrange if work on this is already tracked on a libvirt-BZ or worked on 
in general.

** Also affects: libvirt (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu)
   Importance: Undecided => High

** Changed in: qemu (Ubuntu)
   Importance: Critical => Undecided

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

Title:
  Cannot start a guest with more than 1TB of RAM

Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Invalid

Bug description:
  Attempting to start a KVM guest with more than 1TB of RAM fails.

  It looks like we might need some extra patches:
  https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg5.html

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Fri May  4 16:21:14 2018
  InstallationDate: Installed on 2017-04-05 (393 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise 
vt.handoff=1
  SourcePackage: qemu
  UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
  dmi.bios.date: 02/26/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.6.2
  dmi.board.name: 0PF86Y
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

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

Re: [Qemu-devel] [PATCH] qemu-guest-agent: freeze-hook to ignore dpkg files as well

[Christian Ehrhardt]

Re-Ping for consideration?

On Mon, Jan 22, 2018 at 3:03 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> Hi,
> maybe I missed a formal thing on this submission, but I don't see it right
> away.
> So for now just a ping on any updates in regard to accept this?
>
> On Wed, Dec 13, 2017 at 11:17 AM, Christian Ehrhardt
> <christian.ehrha...@canonical.com> wrote:
> > The hook already skips a set of rpm upgrade artifacts.
> > Do the same with such files that might be created by dpkg.
> >
> > Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1484990
> >
> > Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
> > ---
> >  scripts/qemu-guest-agent/fsfreeze-hook | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/qemu-guest-agent/fsfreeze-hook
> b/scripts/qemu-guest-agent/fsfreeze-hook
> > index c27b29f..13aafd4 100755
> > --- a/scripts/qemu-guest-agent/fsfreeze-hook
> > +++ b/scripts/qemu-guest-agent/fsfreeze-hook
> > @@ -13,7 +13,7 @@ FSFREEZE_D=$(dirname -- "$0")/fsfreeze-hook.d
> >  # Check whether file $1 is a backup or rpm-generated file and should be
> ignored
> >  is_ignored_file() {
> >  case "$1" in
> > -*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave |
> *.sample)
> > +*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave |
> *.sample | *.dpkg-old | *.dpkg-new | *.dpkg-tmp | *.dpkg-dist | *.dpkg-bak
> | *.dpkg-backup | *.dpkg-remove)
> >  return 0 ;;
> >  esac
> >  return 1
> > --
> > 2.7.4
> >
>
>
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] proposed release schedule for QEMU 2.12

[Christian Ehrhardt]

On Tue, Jan 30, 2018 at 5:25 PM, Peter Maydell  wrote:
> It seems like it's about time we settled on the dates for the
> 2.12 release. I've sketched in a suggestion at:
>   https://wiki.qemu.org/Planning/2.12
>
> which puts softfreeze on the 13th March, hardfreeze a
> week later on the 20th, and final release on the 17th April.

Hi Peter,
2.12 looks good to me FWIW, but I wanted to ask if there are
discussions on a 2.11.1 timing as well?
Especially in regard to [1] at least agreeing and defining a date
would be great IMHO.
I haven't seen any date-talk on 2.11.1 and doesn't say anything about it yet.

We touched the topic on some architectures contributions to [1] fixes,
but nobody mentioned a date so far.

[1]: https://www.qemu.org/2018/01/04/spectre/
[2]: https://wiki.qemu.org/Planning/2.11

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Christian Ehrhardt]

On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
<borntrae...@de.ibm.com> wrote:
>
>
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
>> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.mayd...@linaro.org> 
>> wrote:
>>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabk...@redhat.com> wrote:
>>>> The following changes since commit 
>>>> 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>>>
>>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
>>>> staging (2018-01-16 17:36:39 +)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>>>
>>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>>>
>>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>>>
>>>> 
>>>> x86 queue, 2018-01-17
>>>>
>>>> Highlight: new CPU models that expose CPU features that guests
>>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>>>
>>>
>>> Applied, thanks.
>>>
>>> -- PMM
>>>
>>
>> Hi,
>> I was kind of clinging to [1] so far and had the expectation that all
>> those would be wrapped up in 2.11.1 once ready.
>> I see that the s390x changes are targeted to qemu-stable (well to
>> admit I suggested so referring the article above).
>> So I'd expected to see this series to show up on qemu-stable as well
>> but haven't seen it so far.
>>
>> Therefore I wanted to ask if there was a change of plans in that
>> regard or if it needs just a few days more to see (part of) this
>> series on qemu-stable and on its way into 2.11.1?
>>
>> [1]: https://www.qemu.org/2018/01/04/spectre/
>
> Adding Michael,
>
> Yes, I think it makes sense to have the guest enablement for the spectre
> mitigations available in 2.11.1 for all architectures that provide it.
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
[PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
the PPC version of all of this right?
Not sure who to add for Arm :-/

@Cornelia - the consumers of these stable changes in particular IMHO
are Distributions for security updates.
Seeing at least one backport into 2.11.1 would be very helpful to
avoid issues that would not apply to a forward thinking 2.12 commit.
Such a (even short distance) backport being done by the Author would
have the lowest risk of such issues creeping in.
I'm not so sure on 2.(<11).x  - but one backport at least into the
latest release would be very nice to fulfill the [1] announcement
referenced above and provide a first release of these important
changes available earlier than full 2.12.

cu
Christian

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Christian Ehrhardt]

On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  wrote:
> On 18 January 2018 at 02:01, Eduardo Habkost  wrote:
>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>
>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
>> staging (2018-01-16 17:36:39 +)
>>
>> are available in the Git repository at:
>>
>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>
>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>
>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>
>> 
>> x86 queue, 2018-01-17
>>
>> Highlight: new CPU models that expose CPU features that guests
>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>
>
> Applied, thanks.
>
> -- PMM
>

Hi,
I was kind of clinging to [1] so far and had the expectation that all
those would be wrapped up in 2.11.1 once ready.
I see that the s390x changes are targeted to qemu-stable (well to
admit I suggested so referring the article above).
So I'd expected to see this series to show up on qemu-stable as well
but haven't seen it so far.

Therefore I wanted to ask if there was a change of plans in that
regard or if it needs just a few days more to see (part of) this
series on qemu-stable and on its way into 2.11.1?

[1]: https://www.qemu.org/2018/01/04/spectre/

Re: [Qemu-devel] [PATCH] qemu-guest-agent: freeze-hook to ignore dpkg files as well

[Christian Ehrhardt]

Hi,
maybe I missed a formal thing on this submission, but I don't see it right away.
So for now just a ping on any updates in regard to accept this?

On Wed, Dec 13, 2017 at 11:17 AM, Christian Ehrhardt
<christian.ehrha...@canonical.com> wrote:
> The hook already skips a set of rpm upgrade artifacts.
> Do the same with such files that might be created by dpkg.
>
> Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1484990
>
> Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
> ---
>  scripts/qemu-guest-agent/fsfreeze-hook | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/qemu-guest-agent/fsfreeze-hook 
> b/scripts/qemu-guest-agent/fsfreeze-hook
> index c27b29f..13aafd4 100755
> --- a/scripts/qemu-guest-agent/fsfreeze-hook
> +++ b/scripts/qemu-guest-agent/fsfreeze-hook
> @@ -13,7 +13,7 @@ FSFREEZE_D=$(dirname -- "$0")/fsfreeze-hook.d
>  # Check whether file $1 is a backup or rpm-generated file and should be 
> ignored
>  is_ignored_file() {
>  case "$1" in
> -*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample)
> +*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample | 
> *.dpkg-old | *.dpkg-new | *.dpkg-tmp | *.dpkg-dist | *.dpkg-bak | 
> *.dpkg-backup | *.dpkg-remove)
>  return 0 ;;
>  esac
>  return 1
> --
> 2.7.4
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] [PATCH v3 0/3] s390x/kvm: implement new hardware/firmware features

[Christian Ehrhardt]

On Thu, Jan 18, 2018 at 2:15 PM, Cornelia Huck  wrote:
> On Thu, 18 Jan 2018 13:47:54 +0100
> Christian Borntraeger  wrote:
>
>> Have the x86 features been marked as stable? If the answer is yes,
>> shall we mark these patches for stable as well?
>
> Doesn't look like it.
>
> TBH, I'm not quite sure whether this should go into stable as I'm a bit
> unclear what our use case for stable is. It seems to be mostly "don't
> let people run into known crashes" or something like that.

I read the public statement [1] as "... non-x86 processors ...
backported to recent stable releases." or did the changes in
discussion here end up structurally so different that this doesn't
apply anymore?

[1]: https://www.qemu.org/2018/01/04/spectre/

[Qemu-devel] [PATCH] qemu-guest-agent: freeze-hook to ignore dpkg files as well

[Christian Ehrhardt]

The hook already skips a set of rpm upgrade artifacts.
Do the same with such files that might be created by dpkg.

Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1484990

Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
 scripts/qemu-guest-agent/fsfreeze-hook | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/qemu-guest-agent/fsfreeze-hook 
b/scripts/qemu-guest-agent/fsfreeze-hook
index c27b29f..13aafd4 100755
--- a/scripts/qemu-guest-agent/fsfreeze-hook
+++ b/scripts/qemu-guest-agent/fsfreeze-hook
@@ -13,7 +13,7 @@ FSFREEZE_D=$(dirname -- "$0")/fsfreeze-hook.d
 # Check whether file $1 is a backup or rpm-generated file and should be ignored
 is_ignored_file() {
 case "$1" in
-*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample)
+*~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample | 
*.dpkg-old | *.dpkg-new | *.dpkg-tmp | *.dpkg-dist | *.dpkg-bak | *.dpkg-backup 
| *.dpkg-remove)
 return 0 ;;
 esac
 return 1
-- 
2.7.4

Re: [Qemu-devel] [libvirt] How to best handle the reoccurring of rom changes breaking cross version migrations?

[Christian Ehrhardt]

On Thu, Nov 2, 2017 at 4:34 PM, Daniel P. Berrange <berra...@redhat.com> wrote:
>
> On Thu, Nov 02, 2017 at 04:14:06PM +0100, Christian Ehrhardt wrote:
> > Ping - since there wasn't any reply so far - any best practices one could
> > share?
> >
> > Let me add a TL;DR:
> > - bump of ipxe rom versions change the size of virtio-net-pci.rom
> > - that breaks on migration "Length mismatch"
> >
> > I'd guess the size of that rom has to be fixed up on the fly, but if that
> > is really ok and how/where is the question.
>
> The actual ROM contents will be transferred in the migration stream, so
> the fact that the target host has ROMs with different content is not
> important. The key thing that matters is that QEMU the target host loads
> the ROMs at the same location, so that when the ROM contents is overwritten
> with data from the incoming migration scheme, it all ends up at the same
> place as it was on the source.


Thanks Daniel for your answer, although you try to kill my remaining
hopes of a better solution :-)
But if the actual ROM content is migrated over anyway "all I'd have to
do" is to make clear that the newer system (qemu) knows that the
incoming rom has a different size than it thinks.
I thought that was what the machine types and their mechanisms were
for, but so far I only scratched like 10% of those - maybe they don't
cover these rom sizes?

>
> Getting this to happen requires pre-planning when building the ROMs. By
> the time you hit the size change during migration it is too late and your
> VM is basically doomed. When building you need to add padding. IIUC for
> RHEL we artificially increased the size of the seabios and ipxe ROMs to
> 256k. So when later RHEL updates ship new seabios/ipxe they still fit in
> the 256k region previously allowed for.


That would have been a good solution to this - if it was done in the past :-)
If I end up forced to draw a line anyway, that is a good way to start
over safe against further size changes.

Re: [Qemu-devel] How to best handle the reoccurring of rom changes breaking cross version migrations?

[Christian Ehrhardt]

Ping - since there wasn't any reply so far - any best practices one could
share?

Let me add a TL;DR:
- bump of ipxe rom versions change the size of virtio-net-pci.rom
- that breaks on migration "Length mismatch"

I'd guess the size of that rom has to be fixed up on the fly, but if that
is really ok and how/where is the question.

Also to +1 on bad things for today - I made this a cross post to libvirt in
case there is one that has done that in the past.


On Mon, Aug 28, 2017 at 4:36 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> Hi,
> migration issues due to rom changes seem to occur over and over in past
> years [1], [2],[3],[4],[5].
> From the past I know several workarounds (like just truncating to the
> bigger size) but all have various deficiencies.
>
> But OTOH rom's will always change due to fixes in them. And recently I
> found one such change [6] that affects the next Ubuntu release and wonder
> what the ?right?, well lets say best way to fix it would be.
> Current issue:
> Length mismatch: :00:03.0/virtio-net-pci.rom: 0x4 in != 0x8:
> Invalid argument
> Due to efi-virtio.rom growing over 256k due to an update to a newer ipxe
> from upstream.
>
> I beg your pardon (for not being educated enough on this yet), but I want
> to avoid to go a route that is fixing it in a sub-optimal way and ask for
> some guidance. There might be better ways in the modern qemu of today than
> there were in the past.
> TL;DR I look for the best way (if any) to declare in the new qemu: "I know
> that the old size was smaller, let me fix that up on migration".
>
> I'll try on my own as I expect the machine type structures/mechanisms (and
> we have Ubuntu specific types that could encapsulate the rom status from
> the ipxe package to be coupled with the type) have all that is needed.
> Yet me almost randomly trying around there surely isn't the best way to go
> - so if there is some existing case or a short hint at what in there might
> be the best way to fixup a changed rom size on a migration I'd be very
> happy to hear about that.
>
> [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536331
> [2]: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01881.html
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1293566
> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1090093
> [5]: https://forge.univention.org/bugzilla/show_bug.cgi?id=38877
> [6]: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1713490
>
> P.S: As everybody else I don't mind so much on reverse migration to older
> releases
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] need to resurrect no-lock option?

[Christian Ehrhardt]

On Wed, Sep 20, 2017 at 11:51 AM, Fam Zheng <f...@redhat.com> wrote:

> On Wed, 09/20 11:26, Christian Ehrhardt wrote:
> > Hi,
> > this might have been discussed in the wake of the lock changes that took
> > place in 2.10 but I can't find anything clear enough to follow in the
> > current case.
> > There was an old submission [1] by Fam to make it possible to no-lock
> > qemu-img and others if needed. But it seems nothing like it made it along
> > to the locking we have in 2.10.
> >
> > One (maybe more) case where missing this causes pain is e.g. running an
> > info check on a running guest.
> > In general info shouldn't need a write lock anyway, but without --no-lock
> > that use case is broken.
>
> The --no-lock option was later revised into --force-share, so...
>

Thanks for the remapping of this old patch to what it ended up!
Test works for me, need to check with other affected cases.

>
> > Repro of the case is rather simple:
> > $ qemu-img create -f qcow2 /tmp/test.qcow2 1M
> > $ qemu-system-x86_64 -hda /tmp/test.qcow2 -enable-kvm -nodefaults
> > -nographic &
> > $ qemu-img info /tmp/test.qcow2
> > qemu-img: Could not open '/tmp/test.qcow2': Failed to get shared "write"
> > lock
> > Is another process using the image?
>
> ... you can do this:
>
> $ qemu-img info --force-share /tmp/test.qcow2
> image: /tmp/test.qcow2
> file format: qcow2
> virtual size: 1.0M (1048576 bytes)
> disk size: 196K
> cluster_size: 65536
> Format specific information:
> compat: 1.1
> lazy refcounts: false
> refcount bits: 16
> corrupt: false
>
> Fam
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[Qemu-devel] need to resurrect no-lock option?

[Christian Ehrhardt]

Hi,
this might have been discussed in the wake of the lock changes that took
place in 2.10 but I can't find anything clear enough to follow in the
current case.
There was an old submission [1] by Fam to make it possible to no-lock
qemu-img and others if needed. But it seems nothing like it made it along
to the locking we have in 2.10.

One (maybe more) case where missing this causes pain is e.g. running an
info check on a running guest.
In general info shouldn't need a write lock anyway, but without --no-lock
that use case is broken.

Repro of the case is rather simple:
$ qemu-img create -f qcow2 /tmp/test.qcow2 1M
$ qemu-system-x86_64 -hda /tmp/test.qcow2 -enable-kvm -nodefaults
-nographic &
$ qemu-img info /tmp/test.qcow2
qemu-img: Could not open '/tmp/test.qcow2': Failed to get shared "write"
lock
Is another process using the image?

[1]: https://lists.gnu.org/archive/html/qemu-block/2016-04/msg00349.html

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3

[Christian Ehrhardt]

On Thu, Aug 31, 2017 at 7:44 PM, Michael Roth 
wrote:

> Quoting Thomas Huth (2017-08-29 04:35:22)
> > On 28.08.2017 09:18, Christian Borntraeger wrote:
> > >
> > >
> > > On 08/25/2017 10:29 AM, Cornelia Huck wrote:
> > >> On Fri, 25 Aug 2017 10:21:58 +0200
> > >> Christian Borntraeger  wrote:
> > >>
> > >>> On 08/25/2017 09:20 AM, Cornelia Huck wrote:
> > >>
> >  OK, to recap:
> > 
> >  - the current pre-built bios seems fine
> >  - rebuilding the bios may yield a version that fails on some systems
> >    (different compiler?)
> >  - adding aligned(8) looks like the right thing to do
> >  - it seems to fix the problem, but on at least one system something
> >    still seems off (under investigation)
> > >>>
> > >>> Yes. I am out of office today, so for any aligned(8) patch
> > >>> Acked-by: Christian Borntraeger 
> > >>> even for 2.10.
> > >>
> > >> I fear the 2.10 train has already left the station, but any aligned(8)
> > >> patch should be cc:stable.
> > >
> > > I think this could be a topic for QEMU summit. Our process of not
> allowing
> > > fixes in rcx without requiring an rc(x+1) seems a bit odd. The Linux
> kernel
> > > style (there are fixes between the last rc and release) seems more
> balanced
> > > as long as we establish some safety nets.
> >
> > This sounds like a good idea to me, yes. And maybe we could also ease
> > the situation a little bit by providing the first stable .1 release
> > already two or three weeks after the .0 release [*] ? Then these "we are
> > not 100% sure whether this is a severe blocker or not" patches could
> > simply be provided to the public with that .1 release instead of
> > blocking the QEMU master branch in freeze state...
>
> I can give it a try for 2.10.1.
>
> At least initially, I would prefer to not have there be a set expectation
> that there will be a quick .1 release though, but rather anything tagged
> for-2.10, for instance, that doesn't make it in, will then fall into
> the "expedited 2.10.1" bucket, and for that to be the *only* way to get
> into that bucket (we'd still do the normal round-up and pull in any
> "Cc: qemu-sta...@nongnu.org" patches at that point though).
>

Hi Michael,
To check if I got that correctly:
- a 2.10.1 could happen rather soon (like end of september as suggested) as
several things seem still up in the air?
- but to "get in" you'd still expect all changes that should be considered
to hit "Cc: qemu-sta...@nongnu.org" and be bugfix only?

This would help ensure we don't steal focus from the .0 releases and allow
> those "is this a blocker?" discussions to happen in the proper context.
>
> >
> >  Thomas
> >
> >
> > [*] I know that means more additional work for Michael - sorry for that
> > ... but at least we should talk about this, I think. Maybe someone else
> > could also help with the releases if it's too much work for one person?
> >
>
>
>

[Qemu-devel] How to best handle the reoccurring of rom changes breaking cross version migrations?

[Christian Ehrhardt]

Hi,
migration issues due to rom changes seem to occur over and over in past
years [1], [2],[3],[4],[5].
>From the past I know several workarounds (like just truncating to the
bigger size) but all have various deficiencies.

But OTOH rom's will always change due to fixes in them. And recently I
found one such change [6] that affects the next Ubuntu release and wonder
what the ?right?, well lets say best way to fix it would be.
Current issue:
Length mismatch: :00:03.0/virtio-net-pci.rom: 0x4 in != 0x8:
Invalid argument
Due to efi-virtio.rom growing over 256k due to an update to a newer ipxe
from upstream.

I beg your pardon (for not being educated enough on this yet), but I want
to avoid to go a route that is fixing it in a sub-optimal way and ask for
some guidance. There might be better ways in the modern qemu of today than
there were in the past.
TL;DR I look for the best way (if any) to declare in the new qemu: "I know
that the old size was smaller, let me fix that up on migration".

I'll try on my own as I expect the machine type structures/mechanisms (and
we have Ubuntu specific types that could encapsulate the rom status from
the ipxe package to be coupled with the type) have all that is needed.
Yet me almost randomly trying around there surely isn't the best way to go
- so if there is some existing case or a short hint at what in there might
be the best way to fixup a changed rom size on a migration I'd be very
happy to hear about that.

[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536331
[2]: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01881.html
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1293566
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1090093
[5]: https://forge.univention.org/bugzilla/show_bug.cgi?id=38877
[6]: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1713490

P.S: As everybody else I don't mind so much on reverse migration to older
releases

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] [PULL 0/6] NBD pull request for 2.10-rc4

[Christian Ehrhardt]

On Wed, Aug 23, 2017 at 6:33 PM, Eric Blake  wrote:
[...]
>
> 
> nbd patches for 2017-08-23
>
> - Fam Zheng: 0/4 block: Fix non-shared storage migration
> - Stefan Hajnoczi: qemu-iotests: add 194 non-shared storage migration test
> - Stefan Hajnoczi: nbd-client: avoid spurious qio_channel_yield() re-entry
>
> 
> Fam Zheng (3):
>   block-backend: Refactor inactivate check
>   block-backend: Allow more "can inactivate" cases
>   mirror: Mark target BB as "force allow inactivate"
>
> Stefan Hajnoczi (3):
>   block: Update open_flags after ->inactivate() callback
>   qemu-iotests: add 194 non-shared storage migration test
>   nbd-client: avoid spurious qio_channel_yield() re-entry
>

... no need for tested-by after being applied already, but I wanted to
thank Fam, Stefan, David and everybody else involved.
With all six on top of rc3 the copy-storage migrations are working on 2.10
now - thanks!

Re: [Qemu-devel] [PATCH v2] configure: enable --s390-pgste linker option

[Christian Ehrhardt]

On Wed, Aug 23, 2017 at 8:53 AM, Christian Borntraeger <
borntrae...@de.ibm.com> wrote:

> KVM guests on s390 need a different page table layout than normal
> processes (2kb page table + 2kb page status extensions vs 2kb page table
> only). As of today this has to be enabled via the vm.allocate_pgste
> sysctl.
>
> Newer kernels (>= 4.12) on s390 check for an S390_PGSTE program header
> and enable the pgste page table extensions in that case. This makes the
> vm.allocate_pgste sysctl unnecessary. We enable this program header for
> the s390 system emulation (qemu-system-s390x) if we build on s390
> - for s390 system emulation
> - the linker supports --s390-pgste (binutils >= 2.29)
> - KVM is enabled
>
> This will allow distributions to disable the global vm.allocate_pgste
> sysctl, which will improve the page table allocation for non KVM
> processes as only 2kb chunks are necessary.
>

Hi Christian,
it is great to see context pgste come to life.
Currently vm.allocate_pgste defaults to 0 in the kernel but as you stated
mostly enabled for KVM support in Distros.
So when someone wants to disable it he has to drop the enabling
(e.g. /etc/sysctl.d/10-arch-specific.conf for us).

I want to be sure on the proper phasing of this - we can drop the
"enabling" of global pgste once for a release we:
- do not expect/support a kernel <4.12 to run there
- will have only qemu versions >= the one carrying this change (and have it
properly enabled)
- binutils >= 2.29 to get the linking right

But furthermore if we have a qemu with this enabled, there is no drawback
and we could still run it in:
- former releases with older kernels
- former releases with older build environments
That program header would just be ignored and we just would have to keep
the sysctl enabled there right?

Also for the time we want to check on the proper header, you surely have a
one liner you can share that you run against the binary to check if it was
generated correctly?
Maybe even one that you can run against a pid if the status is correct?

Re: [Qemu-devel] [PATCH for-2.10 v2 0/4] block: Fix non-shared storage migration

[Christian Ehrhardt]

On Tue, Aug 15, 2017 at 3:07 PM, Fam Zheng  wrote:

> v2: Don't leak blk->vmsh when BB is deleted before the callback is called.
> [Stefan]
> From stub functions, don't return g_malloc0(1) which is risky, return
> NULL.
> [Eric]


Thanks Fam Zheng and Kevin Wolf,
retesting on -rc3 clearly got me further.

Unfortunately the overall test of a libvirt controlled migration with
--copy-storage-all or --copy-storage-inc still does not work.
I have no good pointers yet where to look at, but wanted to give a heads up.

I'm tracking what I have in [1] so far and added upstream qemu as bug task
as well until we know better.

[1]: https://bugs.launchpad.net/qemu/+bug/1711602

Re: [Qemu-devel] migration issue with qemu 2.10-rc2: QEMU command 'nbd-server-add': Block node is read-only

[Christian Ehrhardt]

On Fri, Aug 11, 2017 at 2:37 PM, Kevin Wolf <kw...@redhat.com> wrote:

> Am 11.08.2017 um 14:04 hat Fam Zheng geschrieben:
> > On Fri, 08/11 13:07, Christian Ehrhardt wrote:
> > > Simplifying that to a smaller test:
> > >
>
[...]

> > > Block node is read-only
>
[...]

> >
> > This is actually caused by
> >
> > commit 9c5e6594f15b7364624a3ad40306c396c93a2145
> > Author: Kevin Wolf <kw...@redhat.com>
> > Date:   Thu May 4 18:52:40 2017 +0200
> >
> > block: Fix write/resize permissions for inactive images
> >
>

Yeah in the meantime an automated bisect run is through an agrees.
Thanks for pointing out the right change triggering that so early!

Thanks Kevin for all the suggestions already, I quickly looked at the code
but I'm lost there without taking much more time.
Is anybody experienced in that area looking at fixing that?
Because IMHO that is kind of a block bug for 2.10 by breaking formerly
working behavior (even as Kevin identified it seems to have done it wrong
all the time).

[Qemu-devel] migration issue with qemu 2.10-rc2: QEMU command 'nbd-server-add': Block node is read-only

[Christian Ehrhardt]

 (#block507):
/var/lib/uvtool/libvirt/images/kvmguest-artful-normal-ds.qcow (qcow2)
Attached to:  /machine/peripheral/virtio-disk1/virtio-backend
Cache mode:   writeback

# starting the server
(qemu) nbd_server_start 0.0.0.0:49153
# This gave me a valid server
tcp0  0 0.0.0.0:49153   0.0.0.0:*   LISTEN
 0  232898913593/qemu-system-x

# adding the disk
(qemu) nbd_server_add -w drive-virtio-disk0
Block node is read-only

Ok, so reproducible without libvirt on the receiving side.
Simplifying that to a smaller test:

$ qemu-img create -f qcow2 /tmp/test.qcow2 100M
$ qemu-system-x86_64 -S -m 512 -smp 1 -nodefaults --nographic -monitor
stdio -drive
file=/tmp/test.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -incoming
defer
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx
[bit 5]
nbd_server_start 0.0.0.0:49153
(qemu) nbd_server_add -w drive-virtio-disk0
Block node is read-only
(qemu) quit

It might be reasonable to keep the -device section to specify how it is
included.
Finally dropping -incoming defer makes a difference in the error message:

qemu-system-x86_64 -S -m 512 -smp 1 -nodefaults --nographic -monitor stdio
-drive file=/tmp/test.qcow2,format=qcow2,if=none,id=drive-virtio-disk0
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx
[bit 5]
info block
drive-virtio-disk0 (#block163): /tmp/test.qcow2 (qcow2)
Attached to:  /machine/peripheral/virtio-disk0/virtio-backend
Cache mode:   writeback
(qemu) nbd_server_start 0.0.0.0:49153
(qemu) nbd_server_add -w drive-virtio-disk0
Conflicts with use by drive-virtio-disk0 as 'root', which does not allow
'write' on #block163

Without -incoming defer in strace I see:
[pid 13720] fcntl(14, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET,
l_start=203, l_len=1}) = 0
[pid 13720] fcntl(14, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET,
l_start=204, l_len=1}) = 0
[pid 13720] writev(1, [{iov_base="Conflicts with use by drive-virt"...,
iov_len=95}], 1) = 95
Which makes me even more suspicious about the patch initially mentioned.

With -incoming defer set it seems to check things via a signalfd and then
give up on the "Block node is read-only"
[pid 13750] readv(0, [{iov_base="\33", iov_len=1}], 1) = 1
[pid 13750] ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15,
events=POLLIN}], 6, {tv_sec=47226, tv_nsec=19757}, NULL, 8) = 1
([{fd=0, revents=POLLIN}], left {tv_sec=47226, tv_nsec=197566613})
[pid 13750] readv(0, [{iov_base="[", iov_len=1}], 1) = 1
[pid 13750] ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15,
events=POLLIN}], 6, {tv_sec=47226, tv_nsec=197134000}, NULL, 8) = 1
([{fd=0, revents=POLLIN}], left {tv_sec=47226, tv_nsec=197130643})
[pid 13750] readv(0, [{iov_base="A", iov_len=1}], 1) = 1
[pid 13750] writev(1, [{iov_base="nbd_server_add -w drive-virtio-d"...,
iov_len=39}], 1) = 39
[pid 13750] ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15,
events=POLLIN}], 6, {tv_sec=47226, tv_nsec=196721000}, NULL, 8) = 1
([{fd=0, revents=POLLIN}], left {tv_sec=47225, tv_nsec=589631744})
[pid 13750] readv(0, [{iov_base="\r", iov_len=1}], 1) = 1
[pid 13750] writev(1, [{iov_base="\r\n", iov_len=2}], 1) = 2
[pid 13750] writev(1, [{iov_base="Block node is read-only\r\n",
iov_len=25}], 1) = 25

The last qemu I had around was a 2.8 where this works still fine.
If needed I might go bisecting but I have the feeling that I provided
enough data for the experts to easily "spot" it - so holding back the
bisect effort until needed.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] [PATCH 2/2] file-posix: Do runtime check for ofd lock API

[Christian Ehrhardt]

On Fri, Jul 21, 2017 at 2:36 PM, Eric Blake  wrote:

> On 07/21/2017 05:20 AM, Fam Zheng wrote:
> > It is reported that on Windows Subsystem for Linux, ofd operations fail
> > with -EINVAL. In other words, QEMU binary built with system headers that
> > exports F_OFD_SETLK doesn't necessarily run in an environment that
> > actually supports it:
> >
> > $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 \
> > -device virtio-blk-pci,drive=hd0
> > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to
> unlock byte 100
> > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to
> unlock byte 100
> > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to
> lock byte 100
> >
> > Let's do a runtime check to cope with that.
>
> You may want to mention that the same is possible on a system with old
> kernel but new glibc (ie. this issue is not necessarily specific to WSL).
>

I first thought that this combination hitting me as I run KVM in containers
which can diverge glibc (in container) a lot from kernel (in host).

My issue turned out to be an apparmor block instead.
But since I clearly see how my case could lead to the mentioned
old kernel but new glibc I wanted to ping here to refresh/reconsider
this change as well.

Also the reply might be worth as documentation if people search for the
error
message and get here that the following apparmor block leads to the same.

apparmor="DENIED" operation="file_lock"
namespace="root//lxd-testkvm-artful-from_"
profile="libvirt-f687a9b3-5bca-41bc-b206-6e616720cc5e"
name="/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow" pid=7001
comm="qemu-system-x86" requested_mask="k" denied_mask="k" fsuid=0 ouid=0

I'll work on libvirt's virt-aa-helper to generate a rule appropriate for
the new behavior.

[Qemu-devel] [PATCH] configure: allow enabling seccomp on s390x

[Christian Ehrhardt]

Allow enabling seccomp support on s390x if sufficient build
dependencies are provided.

Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
 configure | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure b/configure
index 86f5214..5056ba9 100755
--- a/configure
+++ b/configure
@@ -1927,6 +1927,9 @@ if test "$seccomp" != "no" ; then
 ppc|ppc64)
 libseccomp_minver="2.3.0"
 ;;
+s390|s390x)
+libseccomp_minver="2.3.0"
+;;
 *)
 libseccomp_minver=""
 ;;
-- 
2.7.4

Re: [Qemu-devel] QEMU static build

[Christian Ehrhardt]

Salil Bijur wrote:

On Jan 16, 2008 4:48 PM, Mulyadi Santosa [EMAIL PROTECTED] wrote:

Hi


On Jan 16, 2008 5:20 PM, Salil Bijur [EMAIL PROTECTED] wrote:

Hello,

I've been trying to build QEMU statically by first configuring it
using the --static option. The compiling gives me the same linker
errors as mentioned here:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg10721.html

I know this has been asked before but it hasn't been followed up. Any
ideas on how to fix this?

What do you want to do? to debug it? if yes, maybe you just want the
unstripped binary? dig qemu-devel and qemu-forum or at least try
the binary in target-i386..i believe it's unstripped. Can check it
here, because my box use gcc 4.x



I'm trying to build qemu-system-arm so my configure command is
./configure --target-list=arm-softmmu --static. I need a static
build to overcome dynamic library dependency issues. Doing a 'make'
with the above configure command breaks. I haven't found a solution on
the forums.

Thanks,
Salil


I sometimes use a static build for the same reasons on ppc.
I did not have the same issue but I usually set LDFLAGS=$LDFLAGS -pthread before 
doing configuremake.
Maybe it's worth a try if this helps your linker to find the pthread functions.


--

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization

[Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings

[Christian Ehrhardt]

Hi,
the following discussion is from kvm-ppc-devel, but it is actually an qemu 
discussion so I move th topic to qemu-devel.
The original thread is cited in the mail below, in short the issue is the 
following:

Newer gcc versions generate warnings about implicit casts between different 
signed pointers.
That hits a lot of qemu code at least what I saw it compiling for ppc or x86.
So my question is, is there already a preferred qemu approach to get rid of 
these warnings
either the -Wno-pointer-sign solution like in the kernel or something else (I 
did not find
anything like that in the latest cvs snapshot or on this list)?

--- thread from kvm-ppc-devel ---

Jimi Xenidis wrote:


On Jan 11, 2008, at 10:04 AM, Hollis Blanchard wrote:


On Fri, 2008-01-11 at 14:14 +0100, Christian Ehrhardt wrote:

Hi,
maybe its an issue of my build environment only, but when I compile
kvm-userspace for our platform I see a lot of warnings like that in
the qemu code:

warning: pointer targets in passing argument 3 of
'PPC_NVRAM_set_params' differ in signedness

The reason is that some code defines function prototypes and variables
with the type const unsigned char* and then assigns a literal like
PPC to it. But per default our platform seems to have const signed
char* for literals and so we get a lot of annoying warnings. E.g.
nearly every line in qemu/target-ppc/translate.c.

Should we do anything to prevent these Warnings or do you even see
those ?


That warning only appears in recent versions of gcc. In fact I believe
there are 3 different types: char *, unsigned char *, and signed char *,
and implicitly casting between them generates the warnings. :(


[...]


It's a qemu issue. If you want to fix it, you should bring it up on
qemu-devel and see what they think about it.


this is what:
# disable pointer signed / unsigned warnings in gcc 4.0
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)

In linux/Makefile is for.
-JX


--

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization

Re: [Qemu-devel] QEMU static build

[Christian Ehrhardt]

Salil Bijur wrote:

On Jan 16, 2008 5:59 PM, Christian Ehrhardt [EMAIL PROTECTED] wrote:

Salil Bijur wrote:

On Jan 16, 2008 4:48 PM, Mulyadi Santosa [EMAIL PROTECTED] wrote:

Hi


On Jan 16, 2008 5:20 PM, Salil Bijur [EMAIL PROTECTED] wrote:

Hello,

I've been trying to build QEMU statically by first configuring it
using the --static option. The compiling gives me the same linker
errors as mentioned here:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg10721.html

I know this has been asked before but it hasn't been followed up. Any
ideas on how to fix this?

What do you want to do? to debug it? if yes, maybe you just want the
unstripped binary? dig qemu-devel and qemu-forum or at least try
the binary in target-i386..i believe it's unstripped. Can check it
here, because my box use gcc 4.x


I'm trying to build qemu-system-arm so my configure command is
./configure --target-list=arm-softmmu --static. I need a static
build to overcome dynamic library dependency issues. Doing a 'make'
with the above configure command breaks. I haven't found a solution on
the forums.

Thanks,
Salil

I sometimes use a static build for the same reasons on ppc.
I did not have the same issue but I usually set LDFLAGS=$LDFLAGS -pthread before 
doing configuremake.
Maybe it's worth a try if this helps your linker to find the pthread functions.



Thanks - I did 'export LDFLAGS=$LDFLAGS -pthread' before configure
and it compiles further.

But there are further linker errors with respect to libasound (for
ALSA) and libSDL. This can be solved by adding -ldl, -lartsc, etc. for
every dependency of these libs but would be very tedious, especially
for libSDL. Any better solution?



The question is if you really need SDL for your environment - if not you can just add 
--disable-sdl and do the same with everything else e.g. alsa that is missing 
but not really needed.



--

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization

[Qemu-devel] Re: [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync icache for morearchitectures

[Christian Ehrhardt]

Hollis Blanchard wrote:

On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote:

Hollis Blanchard wrote:

A comment to explain why the icache needs flushing only in the KVM

case

would be useful. Other than that I'm fine with it.

Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]

AFAIK Plain qemu does not directly execute guest code on the
processor,
so the icache is not an issue for it.
Qemu itself has the flush_icache_range function only as helper for the
dynamic code generation.
But we may now write executable guest code with our intercepted mmio
handling that is directly executed when switching back to the guest
context, therefore we need that invalidation in the kvm case.

For the case that I'm overlooking something in plain qemu, so that it
might need it too I add qemu-devel@nongnu.org for comments from there,
but currently I think to have it in #ifdef USE_KVM is the right way.


P.S. Hollis did you mean you would like to see a comment in the code
where that call takes place?


Yes! Hopefully much shorter than this email... :-P


comment added, rebased and resent together with a updated mmio
callback simplification patch - I hope I didn't overlook a response
to the mmio callback thread again this time ;-)

--

Grüsse / regards, 
Christian Ehrhardt


IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
[EMAIL PROTECTED]
[EMAIL PROTECTED]

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen 
Geschäftsführung: Herbert Kircher 
Sitz der Gesellschaft: Böblingen

Registergericht: Amtsgericht Stuttgart, HRB 243294