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

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

Re: [Qemu-devel] QEMU static build

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

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

Re: [Qemu-devel] QEMU static build

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

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

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

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

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

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

ev(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] migration issue with qemu 2.10-rc2: QEMU command 'nbd-server-add': Block node is read-only

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 i

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

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

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

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,

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

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 fol

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

hive/html/qemu-block/2016-04/msg00349.html -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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)

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

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

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

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

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

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 Jan

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

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 >

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

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

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

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 t

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

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

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

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

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

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.

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

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

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

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

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

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

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

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? > >> &g

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

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

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

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

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

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

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

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

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

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-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

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

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

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] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

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

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

** 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. +  *

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

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:

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

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

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

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 rp

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

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 thi

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

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

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

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

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

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

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

e 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 1823152] Re: QEMU not able to boot ubuntu 18.04 as a guest

$ ll /usr/bin/qemu-system-x86_64-spice lrwxrwxrwx 1 root root 18 Mär 25 13:32 /usr/bin/qemu-system-x86_64-spice -> qemu-system-x86_64* This is just a compat symlink for a very old history. It should not be used directly anymore, but then also not matter. I have not seen the same with Ubuntu

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

Ubuntu Ee-series) Status: New => Triaged ** Changed in: qemu (Ubuntu Ee-series) Assignee: (unassigned) => Christian Ehrhardt  (paelzer) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs

[Qemu-devel] [Bug 1823169] Re: qemu displays message "Setup failed, please check external storage is available and has enough room."

I agree to Thomas, and in that case referring to your comment #2 - qemu versions in Ubuntu are associated with the base Ubuntu version - so Ubuntu 16.04 will stick to qemu 2.5 + fixes. Ubuntu 19.10 released next week has qemu 3.1 btw, see [1] And vice versa for an upstream report (which is

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

Thanks Daniel and MarcAndre for chiming in here. Atfer thinking more about it I agree to Daniel that actually mesa should honor and stick with its affinity assignment. For documentation purpose: the solution proposed on the ML is at

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

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-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

>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

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

@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

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

** Also affects: mesa (Ubuntu Disco) Importance: Medium Status: Confirmed ** Also affects: qemu (Ubuntu Disco) Importance: Undecided Status: Triaged ** No longer affects: qemu (Ubuntu Disco) ** Changed in: mesa (Ubuntu Disco) Status: Confirmed => Triaged ** Changed

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

The PPA was built against -proposed so I had to enable that to install all libs. That done the 19.0.0~rc6-1ubuntu0.1 with the set affinity change reverted works quite nicely. It would be great to get that into Ubuntu 19.04 until the involved upstreams agreed how to proceed with it and we can

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

Hi Timo, I tried to test with the mesa from ppa:canonical-x/x-staging But there is a dependency issue in that PPA - I can't install all packages from there. It seems most of the X* packages will need a transition for the new mesa and those are not in this ppa right now. Installing all that I

[Qemu-devel] [Bug 1820247] Re: QEMU random crash caused by libspice-server

:~# cat /var/log/libvirt/qemu/instance-0038.log 2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhardt Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 LC_ALL=C PATH=/usr/local

[Qemu-devel] [Bug 1820247] Re: QEMU random crash caused by libspice-server

or version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers root@pre-node1:~# cat /var/log/libvirt/qemu/instance-0038.log 2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhard

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

This is done upstream, no need for the upstream bug task. For Ubuntu I'll update the tasks to match the statement of sbeattie. There are discussions to reconsider some of the backports, but unfortunately the IA32_ARCH_CAPABILITIES infrastructure is a rather big set of changes. ** Changed in:

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

** Tags added: qemu-19.10 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1830821 Title: Expose ARCH_CAP_MDS_NO in guest Status in intel: New Status in QEMU: New Bug description:

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

Hi, Ken - I think all I said in comment #2 still applies (and likely won't change). It really is a non-issue warning - and even if you e.g. have a zero- warning-allowed policy then you can easily avoid that by using a CPU type that doesn't enable it by default or switch it on/off as needed. In

[Qemu-devel] [Bug 1562653] Re: Ubuntu 15.10: QEMU VM hang if memory >= 1T

I only saw this because it expired now :-/ Anyone affected by this might want to take a look at bug 1776189 where Ubuntu added a special machine type to more easily set "host-phys-bits" which is the qemu flag to have more (usually the host has more) available (at the cost of migratability). That

Re: [Qemu-devel] [Bug 1823458] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu

> @cpaelzer, if you have any suggestions for specific tests/configurations > that might be good to test the specific code changed here, please let me > know. I have ran the few test that would cover that area in the past on PPAs already. Unfortunately this is a very specific path and I don't have

[Qemu-devel] [Bug 1834113] Re: QEMU touchpad input erratic after wakeup from sleep

Hi Avi, for the sake of giving it a try I had a second level guest and suspended/resumed the first level guest a few times. I can't reproduce it. OTOH you seem to have a hard time to identify which change introduced this - if it was any change at all and not just by accident not showing up

Re: [Qemu-devel] [PATCH v2] linux-user: fix to handle variably sized SIOCGSTAMP with new kernels

ound this topic being almost a month old. And related to this fedora bug [1] was closed by adding [2] which matches [3] that was nacked in the discussion here. Since I found nothing later (neither qemu commits nor further discussions) I wonder if it has fallen through the cracks OR if there was a kernel fix/change to resolve it (if that is the case a pointer to the related kernel change would be nice)? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1718926 [2]: https://src.fedoraproject.org/rpms/qemu/blob/master/f/0005-NOT-UPSTREAM-Build-fix-with-latest-kernel.patch [3]: https://patchew.org/QEMU/20190604071915.288045-1-borntrae...@de.ibm.com/ > Thanks, > Laurent > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

[Qemu-devel] [Bug 1834113] Re: QEMU touchpad input erratic after wakeup from sleep

Related changes are 3 * SECURITY UPDATE: DoS via incorrect permissions check 4 - debian/patches/CVE-2019-3886-1.patch: disallow virDomainGetHostname 5 for read-only connections in src/libvirt-domain.c. 6 -

[Qemu-devel] [Bug 1838312] Re: Qemu virt-manager Segmentation fault

That is a long list of install commands Hans Peter, wouldn't dependencies just take care of it as well? Anyway, I installed the same set of packages and it works fine for me. Which Ubuntu release are you on? What machine are you on? Any further configuration done to libvirt yet? Maybe a list of

[Qemu-devel] [Bug 1838312] Re: Qemu virt-manager Segmentation fault

That crash seems to be from sessioninstaller which is not related to virt-manager. But never the less from your log: "ValueError: Namespace GtK not available" But virt-manager could require the same. In fact things are provided by gir1.2-gtk-3.0 and virt-manager has: Depends: ...

[Qemu-devel] [Bug 1838569] Re: virtio-balloon change breaks post 4.0 upgrade

** Also affects: qemu (Ubuntu) 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/1838569 Title: virtio-balloon change breaks post 4.0 upgrade Status in

[Qemu-devel] [Bug 1838569] Re: virtio-balloon change breaks post 4.0 upgrade

In regard to "similar bugs" it sounds more like [1] to me. Which was around needing [2]. But just like the commit David mentioned is in 2.8 this one is in since 2.6 (and backported). [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 [2]:

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

Focal is complete the MPs reviewed, SRU Teamplates ready and pre-tests done. Uploading to E-unapproved for the SRU Teams consideration. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1848556 Title:

Best practices to handle shared objects through qemu upgrades?

would require fake hotplugs which seems wrong - Required additional upgrade pre-planning - kills most benefits of modular code without an actual need for it being loaded c) go back to non modular build - No :-) d) anything else out there? -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd

Re: Best practices to handle shared objects through qemu upgrades?

On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé wrote: > > On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote: > > Hi everyone, > > we've got a bug report recently - on handling qemu .so's through > > upgrades - that got me wondering how to best handl

Re: [Bug 1852781] Re: qemu s390x on focal - applications breaking

Hi Colin, I didn't read much if the details but I think it is clear. Per request of IBM focal got -march=z13 but tcg has no emulation for some of the instructions of this cpu. That is the breakage that you are seeing and afaik there is nothing we can do than waiting for qemu to grow that

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

This was tonight first accepted and then immediately rejected as it was surpassed by a security fix. => Rebased and uploaded 1:4.0+dfsg-0ubuntu9.2 to eoan-unapproved again. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

** Changed in: qemu (Ubuntu Eoan) Assignee: (unassigned) => Christian Ehrhardt  (paelzer) ** Changed in: qemu (Ubuntu Focal) Assignee: (unassigned) => Christian Ehrhardt  (paelzer) -- You received this bug notification because you are a member of qemu- devel-ml, which is subs

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

Now that Focal is open I have opened proper Focal MP replacing the old one and also an Eoan SRU MP right away. => https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374770 => https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374771 -- You received

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

FYI: uploaded to 20.04 Focal, considering SRUs (Eoan) after this completes -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1848556 Title: qemu-img check failing on remote image in Eoan Status in

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

Quick checks: - does not depend on the exact image, e.g. https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img or https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2 hang as well - the former qemu 3.1

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

The stuck poll is at: #0 0x7fafb935ad26 in __GI_ppoll (fds=0x560dba615670, nfds=1, timeout=, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x560db89550b9 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

** Attachment added: "strace of the hanging qemu-img" https://bugs.launchpad.net/qemu/+bug/1848556/+attachment/5298128/+files/qemu-img-hangs.strace -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

Hi Rod, I did try to recreate with the qemu version that you have. $ apt install apache2 qemu-system-x86 $ qemu-img create -f qcow2 /var/www/html/test.img 1G # local $ qemu-img check test.img No errors were found on the image. # remote $ qemu-img check http://localhost:80/test.img

  1   2   3   >