from:"Christian Ehrhardt "

** 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.
https://bugs.launchpad.net/bugs/1848556

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Confirmed

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

[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   

  
No errors were found on the image.  

  
Image end offset: 262144

Local check and remote check both work just fine.

I recognized the image that you have there and then did:
$ cd /var/www/html/
$ wget 
https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img
# local
$ qemu-img check bionic-server-cloudimg-amd64.img
No errors were found on the image.
16651/36032 = 46.21% allocated, 98.92% fragmented, 98.49% compressed clusters
Image end offset: 344195072
# remote
$ qemu-img check http://localhost:80/bionic-server-cloudimg-amd64.img


Therefore I can confirm the behavior you described.

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

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

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

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Confirmed

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

[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 /usr/include/x86_64-linux-gnu/bits/poll2.h:77
#2  qemu_poll_ns (fds=, nfds=, timeout=) at ./util/qemu-timer.c:322
#3  0x560db89570eb in aio_poll (ctx=ctx@entry=0x560dba5e83b0, 
blocking=blocking@entry=true) at ./util/aio-posix.c:666
#4  0x560db888c21d in bdrv_check (bs=, res=, 
fix=) at ./block.c:4149
#5  0x560db887e6ab in collect_image_check (bs=0x560dba5ed680, 
check=0x560dba6143d0, filename=0x7ffe3d7c48d7 
"http://localhost:80/bionic-server-cloudimg-amd64.img";, fix=, 
fmt=) at ./qemu-img.c:615
#6  0x560db88825e1 in img_check (argc=, argv=) at ./qemu-img.c:774
#7  0x560db887bd2e in main (argc=2, argv=) at 
./qemu-img.c:4987

And from strace we know that the FD is from
260 [pid 20469]  0.67 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 8 
<0.41>

-- 
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 QEMU:
  Confirmed

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

[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 based qemu-utils work fine

Maybe that helps to identify a known patch that might already exist.
Even it if doesn't the simple repro in comment #2 should still help.

If there is no immediate idea out of the data we have let me know, this
seems bisectable to me.

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

Title:
  qemu-img check failing on remote image in Eoan

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

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

Since it seemed so easy, while bisecting I found that it hangs with
v4.0.0 and v3.1.0 from git and even v3.0.0.

Since the reported good version was 3.1 I began to wonder if I might have 
overlooked something.
I wondered if it might be e.g. the apache version providing a different 
behavior on http.


I was trying to access the same apache server with 4.0 and 3.1 and ran it 
against the download target:
$ qemu-img check 
https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2

3.1 ran into a segfault and 4.0 seems to hang on that.
Maybe I should take a break and revisit that later, as people might have an 
idea already what this might be about.

-- 
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 QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  New

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

Hi Max,
libcurl 7.65.3-1ubuntu3 and was >7.59 for several releases (more than a year at 
least) - so there must be something else going on that this triggers now.

But never the less with the fix from [1] I can again get it to work
successfully.

I think I should backport that to our qemu 4.0 in Ubunutu.
It seems to apply fine (just offset -3, no fuzz)
The former seem not affected e.g. qemu 3.1 along libcurl 7.64.0-2ubuntu1 does 
not expose the behavior.

@Max - As the Author, just to check, do you see any issue backporting
that to qemu 4.0

[1]:
https://git.qemu.org/?p=qemu.git;a=commit;h=bfb23b480a49114315877aacf700b49453e0f9d9

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

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

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

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

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

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

-- 
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 QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Triaged

Bug description:
  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

** Description changed:

+ Ubuntu SRU Template:
+ 
+ [Impact]
+ 
+  * There is fallout due to changes in libcurl that affect qemu and might 
+lead to a hang.
+ 
+  * Fix by backporting the upstream fix
+ 
+ [Test Case]
+ 
+  * If you have network just run
+$ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
+ 
+  * Without network, install apache2, and get a complex qemu file (like a 
+cloud image) onto the system. Then access the file via apache http but 
+not localhost (that would work)
+ 
+ [Regression Potential]
+ 
+  * The change is local to the libcurl usage of qemu, so that could be 
+affected. But then this is what has been found to not work here, so I'd 
+expect not too much trouble. But if so then in the curl usage (which 
+means disks on http)
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ ---
+ 
  The "qemu-img check" function is failing on remote (HTTP-hosted) images,
  beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-0ubuntu9).
  With previous versions, through Ubuntu 19.04/qemu-utils version 1:3.1
  +dfsg-2ubuntu3.5, the following worked:
  
  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384
  
  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several .img
  files on the server, ranging from Bionic to Eoan, with the same results
  with all of them.

** Changed in: qemu
   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/1848556

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Triaged

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

@Rod: Your self built issue seems like at config/make time there were
not all build deps available. I have put a test build in PPA [1], could
you give that one a try on your end as well?

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1848556-qemu-
img-curl-hang-eoan

-- 
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 QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Triaged

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

For me with the version from the PPA works fine on local as well as remote http 
connections.
Thanks @Max for the fix.

@Rod:
Waiting for you to test and verify based on the PPA.

-- 
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 QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Triaged

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

2019-11-21 Thread Christian Ehrhardt 

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.
https://bugs.launchpad.net/bugs/1848556

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Fix Released

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

2019-11-25 Thread Christian Ehrhardt 

Eoan - without fix -> hang

With fix:
qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img


No errors were found on the image.  

  
19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters   

  
Image end offset: 514064384

Setting verified

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

-- 
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 QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Eoan:
  Fix Committed
Status in qemu source package in Focal:
  Fix Released

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

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

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

2019-07-29 Thread Christian Ehrhardt 

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 all installed packages and their versions (dpkg -l)?

You might use apport-collect [1] to gather some of that info
automatically.

[1]: http://manpages.ubuntu.com/manpages/bionic/man1/apport-bug.1.html

** Changed in: virt-manager (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/1838312

Title:
  Qemu virt-manager Segmentation fault

Status in QEMU:
  Invalid
Status in virt-manager package in Ubuntu:
  Incomplete

Bug description:
  Hi!

  I installed all these packages:

  sudo apt install qemu
  sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3
  sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1 
libvirglrenderer0 libxen-4.9 libxenstore3.0
  sudo apt install cpu-checker ibverbs-providers ipxe-qemu libibverbs1 
libiscsi7 libnl-route-3-200 librados2 librbd1 librdmacm1 msr-tools sharutils
  sudo apt install qemu-block-extra qemu-system-common qemu-system-data 
qemu-system-gui qemu-utils
  sudo apt install --no-install-recommends qemu-kvm qemu-system-x86
  sudo apt install libauparse0 ebtables gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 
gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 
libvde0 libvdeplug2 libgovirt-common libgovirt2 libgtk-vnc-2.0-0 libgvnc-1.0-0 
libosinfo-1.0-0 libphodav-2.0-0 libphodav-2.0-common libspice-client-glib-2.0-8 
libspice-client-gtk-3.0-5 libusbredirhost1 libvirt-clients libvirt-daemon 
libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-glib-1.0-0 
libvirt0 osinfo-db python3-libvirt python3-libxml2 
spice-client-glib-usb-acl-helper vde2 vde2-cryptcab virt-viewer virtinst 
virt-manager

  without the i386 packages for Qemu because I want only 64 bit.

  I installed all these packages without error, but when I run

  # virt-manager

  Output: ...shows me:

  Segmentation fault

  
  My hardware is 100% ok.
  Maybee a broken lib?


  How can I fix that?

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

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

2019-07-30 Thread Christian Ehrhardt 

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: ... gir1.2-gtk-3.0 (>= 3.10)

You could clear your /var/crash directory (IIRC by default it won't collect 
crashes over and over until cleared or reported). And then run virt-mamager 
again.
Is a new crash created, and if so how does that one look then?

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

Title:
  Qemu virt-manager Segmentation fault

Status in QEMU:
  Invalid
Status in virt-manager package in Ubuntu:
  Incomplete

Bug description:
  Hi!

  I installed all these packages:

  sudo apt install qemu
  sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3
  sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1 
libvirglrenderer0 libxen-4.9 libxenstore3.0
  sudo apt install cpu-checker ibverbs-providers ipxe-qemu libibverbs1 
libiscsi7 libnl-route-3-200 librados2 librbd1 librdmacm1 msr-tools sharutils
  sudo apt install qemu-block-extra qemu-system-common qemu-system-data 
qemu-system-gui qemu-utils
  sudo apt install --no-install-recommends qemu-kvm qemu-system-x86
  sudo apt install libauparse0 ebtables gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 
gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 
libvde0 libvdeplug2 libgovirt-common libgovirt2 libgtk-vnc-2.0-0 libgvnc-1.0-0 
libosinfo-1.0-0 libphodav-2.0-0 libphodav-2.0-common libspice-client-glib-2.0-8 
libspice-client-gtk-3.0-5 libusbredirhost1 libvirt-clients libvirt-daemon 
libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-glib-1.0-0 
libvirt0 osinfo-db python3-libvirt python3-libxml2 
spice-client-glib-usb-acl-helper vde2 vde2-cryptcab virt-viewer virtinst 
virt-manager

  without the i386 packages for Qemu because I want only 64 bit.

  I installed all these packages without error, but when I run

  # virt-manager

  Output: ...shows me:

  Segmentation fault

  
  My hardware is 100% ok.
  Maybee a broken lib?


  How can I fix that?

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

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

2019-08-07 Thread Christian Ehrhardt 

** 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:
  New
Status in qemu package in Ubuntu:
  New

Bug description:
  We upgraded the libvirt UCA packages from 3.6 to 4.0 and qemu 2.10 to 2.11  
as part of a queens upgrade and noticed that
  virtio-ballon is broken when instances live migrate (started with a prior 3.6 
version)  with:

  2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware 
file in legacy mode: etc/msr_feature_control
  2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < 
last_avail_idx 0xb57 - used_idx 0xb59
  2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load 
virtio-balloon:virtio
  2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for 
instance 0x0 of device ':00:05.0/virtio-balloon'
  2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: 
Operation not permitted
  2019-07-24 06:47:22.430+: shutting down, reason=failed

  This seem to be the exact problem as reported by
  https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html

  Listed the packages which changed:

  Start-Date: 2019-07-06  06:40:55
  Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o 
Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu 
qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc 
qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils 
qemu-user qemu-kvm
  Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), 
libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), 
ipxe-qemu-256k-compat-efi-roms:amd64 
(1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic)
  Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 
4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 
(3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), 
qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 
(3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 
4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 
4.0.0-1ubuntu8.10~cloud0)
  End-Date: 2019-07-06  06:41:08

  At this point the instances would have to be hard rebooted or
  stopped/started to fix the issue for future live migration attemps

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

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

2019-08-07 Thread Christian Ehrhardt 

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]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=4eae2a657d1ff5ada56eb9b4966eae0eff333b0b

-- 
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:
  New
Status in qemu package in Ubuntu:
  New

Bug description:
  We upgraded the libvirt UCA packages from 3.6 to 4.0 and qemu 2.10 to 2.11  
as part of a queens upgrade and noticed that
  virtio-ballon is broken when instances live migrate (started with a prior 3.6 
version)  with:

  2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware 
file in legacy mode: etc/msr_feature_control
  2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < 
last_avail_idx 0xb57 - used_idx 0xb59
  2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load 
virtio-balloon:virtio
  2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for 
instance 0x0 of device ':00:05.0/virtio-balloon'
  2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: 
Operation not permitted
  2019-07-24 06:47:22.430+: shutting down, reason=failed

  This seem to be the exact problem as reported by
  https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html

  Listed the packages which changed:

  Start-Date: 2019-07-06  06:40:55
  Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o 
Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu 
qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc 
qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils 
qemu-user qemu-kvm
  Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), 
libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), 
ipxe-qemu-256k-compat-efi-roms:amd64 
(1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic)
  Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 
4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 
(3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), 
qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 
(3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 
4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 
(1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), 
qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 
1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 
4.0.0-1ubuntu8.10~cloud0)
  End-Date: 2019-07-06  06:41:08

  At this point the instances would have to be hard rebooted or
  stopped/started to fix the issue for future live migration attemps

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

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

2020-02-07 Thread Christian Ehrhardt 

FYI - Focal now contains 4.2 which might (or not) have the bits you need.
You most likely get further, but I can't give guarantees if enough of march=z13 
is supported to work for a full Focal (not sure on vector instructions for 
example) including all of userspace.

Marking it incomplete - if someone wants to try please go for it and let us 
know.
Otherwise let it expire again ...

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

Title:
  qemu s390x on focal - applications breaking

Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Expired

Bug description:
  Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal
  host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering
  random breakage, for example:

  sudo apt-get update && sudo apt-get dist-upgrade

  ...
  ...

  Unpacking debianutils (4.9) over (4.8.6.3) ...
  Setting up debianutils (4.9) ...
  Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime 
line 43.
  (Reading database ... 83640 files and directories currently installed.)
  Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ...
  Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ...
  Setting up bash (5.0-5ubuntu1) ...
  [12124.788618] User process fault: interruption code 0007 ilc:3 in 
bash[2aa3d78+149000]
  dpkg: error processing package bash (--configure):
   installed bash package post-installation script subprocess was killed by 
signal (Floating point exception), core du
  mped
  Errors were encountered while processing:
   bash
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  And now bash is completely broken:

  cking@eoan-s390x:~$ bash
  [12676.204389] User process fault: interruption code 0007 ilc:3 in 
bash[2aa1478+149000]

  Floating point exception (core dumped)

  The upgrade works OK on a s390x, so I'm assuming it's something to do
  with the qemu emulation.

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

** Attachment added: "Serial log "as it was once working""
   
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327028/+files/working-guest-serial.log

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

** Attachment added: "Guest XML "as it was once working""
   
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327027/+files/vm1-as-deployed-by-maas.xml

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

The one that currently is deployed is using the same "list network and hd" 
which should not work.
It will boot network but should not internally fall back to disk.
 10 
 
 11 hvm  
 
 12
 
 13 
 
 14   

Now lets understand how/what works here...

Qemu is given both boot options (we know it will ignore the second ... or at 
least we think and are told so).
   ... -boot strict=on ... id=virtio-disk0,bootindex=2 ... 
mac=52:54:00:02:a3:f9,devno=fe.0.0001,bootindex=1

I'd expect this one to "just" netboot, but we need to understand how it got 
"up" from there.
Fortunately there was a full log of the serial console on disk.

Attaching files from this test ...

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

Here are the interesting bits from the log:

   1 LOADPARM=[]^M  
  
   2 Network boot device detected^M 
  
   3 ^M 
  
   4 Network boot starting...^M 
  
   5   Using MAC address: 52:54:00:02:a3:f9^M   
  
   6   Requesting information via DHCP: ^H^H^H010^H^H^H^Hdone^M 
  
   7   Using IPv4 address: 192.168.122.102^M
  
   8   Using TFTP server: 192.168.122.1^M   
  
   9   Bootfile name: 'boots390x.bin'^M 
  
  10   Receiving data:  0 KBytes^M  
  
  11   TFTP error: file not found: boots390x.bin^M  
  
  12 Trying pxelinux.cfg files...^M^M   
  
...
  14 TFTP: Received s390x/01-52-54-00-02-a3-f9 (581 bytes)^M
  
  15 Loading pxelinux.cfg entry 'execute'^M 
  
...
  17   TFTP: Received ubuntu/s390x/ga-19.04/disco/daily/boot-kernel (4318 
KBytes)^M   
...
  19   TFTP: Received ubuntu/s390x/ga-19.04/disco/daily/boot-initrd (19360 
KBytes)^M  
  20 Network loading done, starting kernel...^M 
  
  21 ^M 
  
  22 [0.439873] Linux version 5.0.0-38-generic (buildd@bos02-s390x-020) 
(gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #41-Ubuntu SMP Tue Dec 3 00:26:40 
UTC 2019 (Ubuntu 5.0.0-38.41-generic  5.0.21)

...

38 ^M[0.451953] Kernel command line: nomodeset ro
root=squash:http://192.168.122.1:5248/images/ubuntu/s390x/ga-19.04/disco/daily/squashfs
ip=vm1:BOOTIF ip6=off overlayroot=tmpfs ov
erlayroot_cfgdisk=disabled cc:{'datasource_list': ['MAAS']}end_cc cloud-
config-url=http://192-168-122-0--24.maas-
internal:5248/MAAS/metadata/latest/by-id/wpr3yp/?op=get_preseed apparmor
=0 log_host=192.168.122.1 log_port=5247 --- console=tty1 console=ttyS0
BOOTIF=01-52-54-00-02-a3-f9

...

 155 Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
IP-Config: enc1 hardware address 52:54:00:02:a3:f9 mtu 1500 DHCP RARP^M
 156 hostname vm1 IP-Config: no response after 2 secs - giving up^M 
  
 157 IP-Config: enc1 hardware address 52:54:00:02:a3:f9 mtu 1500 DHCP RARP^M
  
 158 hostname vm1 hostname vm1 IP-Config: enc1 complete (dhcp from 
192.168.122.1):^M  
 159  address: 192.168.122.102  broadcast: 192.168.122.255  netmask: 
255.255.255.0   ^M
 160  gateway: 192.168.122.254  dns0 : 192.168.122.1dns1   : 
10.245.236.13   ^M
 161  domain : maas
^M 
 162  rootserver: 192.168.122.1 rootpath: ^M
  
 163  filename  : lpxelinux.0^M 
  
 164 :: 
root=squash:http://192.168.122.1:5248/images/ubuntu/s390x/ga-19.04/disco/daily/squashfs^M
 165 :: mount_squash downloading 
http://192.168.122.1:5248/images/ubuntu/s390x/ga-19.04/disco/daily/squashfs to 
/root.tmp.img^M
 166 Connecting to 192.168.122.1:5248 (192.168.122.1:5248)^M
  
 167 ^Mroot.tmp.img  21% |** | 66726k  
0:00:03 ETA^Mroot.tmp.img  98% |** |   296M 
 0:00:00 ETA^Mroot.tmp.img  100% |***|  
 301M  0:00:00 ETA^M
 168 :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'^M
  
 169 done.


^^ all of this seems to be the initial deployment ^^
We see curtin doing its things as instructed by maas.


Later on we see the reboot after install then

1362 -END SSH HOST KEY KEYS-^M  
  
1363 [  202.776296] cloud-init[1567]: Cloud-init v. 
19.3-41-gc4735dd3-0ubuntu1~19.04.1 running 'modules:final' at Mon, 10 Feb 2020 
10:42:08 +. Up 114.97 seconds.^M
1364 [  202.776472] cloud-init[1567]: Cloud-init v. 
19.3-41-gc4735dd3-0ubuntu1~19.04.1 finished at Mon, 10 Feb 2020 10:43:36 +. 
Datasource DataSourceMAAS [http://192-168-122-0--24.maas-i 
nternal:5248/MAAS/metadata/curtin].  Up 202.74 seconds^M
1365 [^[[0;32m  OK  ^[[0m] Started ^[[0;1;39mExecute cloud user/final 
scripts^[[0m.^M 
1366 [^[[0;32m  OK  ^[[0m] Reached target ^[[0;1;39mCloud-init target^[[0m.^M   
  
1367 [^[[0;32m  OK  ^[[0m] Stopped target ^[[0;1;39mGraphical Interface^[[0m.^M 
  
1368 [^[[0;32m  OK  ^[[0m] Stopped target ^[[0;1;39mCloud-init target^[[0m.

...

1487 [^[[0;32m  OK  ^[[0m] Reached target ^[[0;1;39mReboot^[[0m.^M  
  
1488 LOADPARM=[]^M

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

I flipped 



to




And JFH started it from the MAAS UI again.
Now things work (obviously as expected)

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

@sfeole - after initial deployment just do the change to your guest XMLs
you see in comment #27

@maas - as I said in comment #26 (and before) this needs coding in maas
to switch the XML content (or waiting a long time on IBM)

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

The assumption from here was that this only appeared to be working due
to:

a) Deploy = netboot + reboot from disk = working

but at the same time

b) Start = netboot (fail) + no fallback = fail


To get that from Maas UI we stopped the guest (it went down as expected).
Then from Maas we said "power on" again.

There on (b) it failed as maas didn't provide it with an install image.
If you track it in the console you see:

$virsh start vm1 --console
setlocale: No such file or directory
Domain vm1 started
Connected to domain vm1
Escape character is ^]
done
  Using IPv4 address: 192.168.122.102
  Using TFTP server: 192.168.122.1
  Bootfile name: 'boots390x.bin'
  Receiving data:  0 KBytes
  TFTP error: file not found: boots390x.bin
Trying pxelinux.cfg files...
  Receiving data:  0 KBytes
  Receiving data:  0 KBytes
Failed to load OS from network

Maas tries a few times as we see the guest flip between "shut off" and "paused" 
state.
But then fives up.

The super-TL;DR matching the current insights is:
- deploy s390x Maas-KVM @ s390x worked and still does
- poweroff/poweron s390x Maas-KVM @ s390x never worked and still does not

To fix the latter we either need
a) upstream to implement a fallback to the next boot mechanism
b) maas to modify the XML after deploy to boot from disk

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

OR
Maas can boot from network (always) and if not deploying just issue a "reboot 
from disk" command

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

Title:
  [2.6] Unable to reboot s390x KVM machine after initial deploy

Status in MAAS:
  New
Status in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 
requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] 
s390x/default requested by 10.246.75.160

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

Re: [RESEND PATCH v2] target/i386: Switch back XFRM value

2023-03-27 Thread Christian Ehrhardt

On Thu, Oct 27, 2022 at 2:36 AM Yang, Weijiang  wrote:
>
>
> On 10/26/2022 7:57 PM, Zhong, Yang wrote:
> > The previous patch wrongly replaced FEAT_XSAVE_XCR0_{LO|HI} with
> > FEAT_XSAVE_XSS_{LO|HI} in CPUID(EAX=12,ECX=1):{ECX,EDX}, which made
> > SGX enclave only supported SSE and x87 feature(xfrm=0x3).
> >
> > Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based 
> > features")
> >
> > Signed-off-by: Yang Zhong 
> > ---
> >   target/i386/cpu.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index ad623d91e4..19aaed877b 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5584,8 +5584,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> > uint32_t count,
> >   } else {
> >   *eax &= env->features[FEAT_SGX_12_1_EAX];
> >   *ebx &= 0; /* ebx reserve */
> > -*ecx &= env->features[FEAT_XSAVE_XSS_LO];
> > -*edx &= env->features[FEAT_XSAVE_XSS_HI];
> > +*ecx &= env->features[FEAT_XSAVE_XCR0_LO];
> > +*edx &= env->features[FEAT_XSAVE_XCR0_HI];
>
> Oops, that's my fault to replace with wrong definitions, thanks for the fix!
>
> Reviewed-by:  Yang Weijiang 

Hi,
I do not have any background on this but stumbled over this and wondered,
is there any particular reason why this wasn't applied yet?

It seemed to fix a former mistake, was acked and then ... silence

> >
> >   /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> >   *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
>


-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

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

2023-04-18 Thread Christian Ehrhardt 

While the bugzilla case wasn't updated this landed in v8.7.0 via a series around
https://gitlab.com/libvirt/libvirt/-/commit/e6c29f09e5b75d7a8d79ae670407060446282c78

v9.0.0 of libvirt is in Ubuntu Lunar, due to that - from now on - one
can control the physical bit settings in a defined way through libvirt.

See maxphysaddr in [1] for how to use that.

Mid term Ubuntu will consider no more adding further variants of the
workaround, that was providing machine types with the -hpb suffix to
allow larger guests.

[1]: https://libvirt.org/formatdomain.html#cpu-model-and-topology

** Changed in: libvirt (Ubuntu)
   Status: Triaged => 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/1769053

Title:
  Ability to control phys-bits through libvirt

Status in libvirt:
  Confirmed
Status in QEMU:
  Invalid
Status in libvirt package in Ubuntu:
  Fix Released
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

[PATCH] tools/virtiofsd: Add rseq syscall to the seccomp allowlist

2022-02-09 Thread christian . ehrhardt

From: Christian Ehrhardt 

The virtiofsd currently crashes when used with glibc 2.35.
That is due to the rseq system call being added to every thread
creation [1][2].

[1]: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/
[2]: https://sourceware.org/pipermail/libc-alpha/2022-February/136040.html

This happens not at daemon start, but when a guest connects

/usr/lib/qemu/virtiofsd -f --socket-path=/tmp/testvfsd -o sandbox=chroot \
-o source=/var/guests/j-virtiofs --socket-group=kvm
virtio_session_mount: Waiting for vhost-user socket connection...
# start ok, now guest will connect
virtio_session_mount: Received vhost-user socket connection
virtio_loop: Entry
fv_queue_set_started: qidx=0 started=1
fv_queue_set_started: qidx=1 started=1
Bad system call (core dumped)

We have to put rseq on the seccomp allowlist to avoid that the daemon
is crashing in this case.

Reported-by: Michael Hudson-Doyle 
Signed-off-by: Christian Ehrhardt 
---
 tools/virtiofsd/passthrough_seccomp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/virtiofsd/passthrough_seccomp.c 
b/tools/virtiofsd/passthrough_seccomp.c
index a3ce9f898d..21b8f53bd9 100644
--- a/tools/virtiofsd/passthrough_seccomp.c
+++ b/tools/virtiofsd/passthrough_seccomp.c
@@ -116,6 +116,9 @@ static const int syscall_allowlist[] = {
 SCMP_SYS(write),
 SCMP_SYS(writev),
 SCMP_SYS(umask),
+#ifdef __NR_rseq
+SCMP_SYS(rseq), /* required since glibc 2.35 */
+#endif
 };
 
 /* Syscalls used when --syslog is enabled */
-- 
2.35.0

Re: [PATCH] tcg: Remove dh_alias indirection for dh_typecode

2022-02-17 Thread Christian Ehrhardt

On Thu, Feb 17, 2022 at 4:48 AM Richard Henderson
 wrote:
>
> The dh_alias redirect is intended to handle TCG types as distinguished
> from C types.  TCG does not distinguish signed int from unsigned int,
> because they are the same size.  However, we need to retain this
> distinction for dh_typecode, lest we fail to extend abi types properly
> for the host call parameters.

Thank you Richard and Keith for the fix for
- https://github.com/keith-packard/snek/issues/58
- https://gitlab.com/qemu-project/qemu/-/issues/876

I did apply that and tested it on s390x with the load that originally found it.
With qemu 6.2 + that patch I ran the full testsuite of snek-arm on
s390x and it works great now.
If you like feel free to add any combination of the following when committing:

Fixes: #876
Fixes: 7319d83a735 ("tcg: Combine dh_is_64bit and dh_is_signed to dh_typecode")
Reported-by: Christian Ehrhardt 
Tested-by: Christian Ehrhardt 

> This bug was detected when running the 'arm' emulator on an s390
> system. The s390 uses TCG_TARGET_EXTEND_ARGS which triggers code
> in tcg_gen_callN to extend 32 bit values to 64 bits; the incorrect
> sign data in the typemask for each argument caused the values to be
> extended as unsigned values.
>
> This simple program exhibits the problem:
>
> static volatile int num = -9;
> static volatile int den = -5;
>
> int
> main(void)
> {
> int quo = num / den;
> printf("num %d den %d quo %d\n", num, den, quo);
> exit(0);
> }
>
> When run on the broken qemu, this results in:
>
> num -9 den -5 quo 0
>
> The correct result is:
>
> num -9 den -5 quo 1
>
> Reported-by: Keith Packard 
> Signed-off-by: Richard Henderson 
> ---
>  include/exec/helper-head.h   | 19 ++-
>  target/hppa/helper.h |  2 ++
>  target/i386/ops_sse_header.h |  3 +++
>  target/m68k/helper.h |  1 +
>  target/ppc/helper.h  |  3 +++
>  5 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/include/exec/helper-head.h b/include/exec/helper-head.h
> index b974eb394a..734af067fe 100644
> --- a/include/exec/helper-head.h
> +++ b/include/exec/helper-head.h
> @@ -53,13 +53,16 @@
>  # ifdef TARGET_LONG_BITS
>  #  if TARGET_LONG_BITS == 32
>  #   define dh_alias_tl i32
> +#   define dh_typecode_tl dh_typecode_i32
>  #  else
>  #   define dh_alias_tl i64
> +#   define dh_typecode_tl dh_typecode_i64
>  #  endif
>  # endif
> -# define dh_alias_env ptr
>  # define dh_ctype_tl target_ulong
> +# define dh_alias_env ptr
>  # define dh_ctype_env CPUArchState *
> +# define dh_typecode_env dh_typecode_ptr
>  #endif
>
>  /* We can't use glue() here because it falls foul of C preprocessor
> @@ -92,18 +95,16 @@
>  #define dh_typecode_i64 4
>  #define dh_typecode_s64 5
>  #define dh_typecode_ptr 6
> -#define dh_typecode(t) glue(dh_typecode_, dh_alias(t))
> +#define dh_typecode_int dh_typecode_s32
> +#define dh_typecode_f16 dh_typecode_i32
> +#define dh_typecode_f32 dh_typecode_i32
> +#define dh_typecode_f64 dh_typecode_i64
> +#define dh_typecode_cptr dh_typecode_ptr
> +#define dh_typecode(t) dh_typecode_##t
>
>  #define dh_callflag_i32  0
> -#define dh_callflag_s32  0
> -#define dh_callflag_int  0
>  #define dh_callflag_i64  0
> -#define dh_callflag_s64  0
> -#define dh_callflag_f16  0
> -#define dh_callflag_f32  0
> -#define dh_callflag_f64  0
>  #define dh_callflag_ptr  0
> -#define dh_callflag_cptr dh_callflag_ptr
>  #define dh_callflag_void 0
>  #define dh_callflag_noreturn TCG_CALL_NO_RETURN
>  #define dh_callflag(t) glue(dh_callflag_, dh_alias(t))
> diff --git a/target/hppa/helper.h b/target/hppa/helper.h
> index fe8a9ce493..c7e35ce8c7 100644
> --- a/target/hppa/helper.h
> +++ b/target/hppa/helper.h
> @@ -1,7 +1,9 @@
>  #if TARGET_REGISTER_BITS == 64
>  # define dh_alias_tr i64
> +# define dh_typecode_tr  dh_typecode_i64
>  #else
>  # define dh_alias_tr i32
> +# define dh_typecode_tr  dh_typecode_i32
>  #endif
>  #define dh_ctype_tr  target_ureg
>
> diff --git a/target/i386/ops_sse_header.h b/target/i386/ops_sse_header.h
> index e68af5c403..cef28f2aae 100644
> --- a/target/i386/ops_sse_header.h
> +++ b/target/i386/ops_sse_header.h
> @@ -30,6 +30,9 @@
>  #define dh_ctype_Reg Reg *
>  #define dh_ctype_ZMMReg ZMMReg *
>  #define dh_ctype_MMXReg MMXReg *
> +#define dh_typecode_Reg dh_typecode_ptr
> +#define dh_typecode_ZMMReg dh_typecode_ptr
> +#define dh_typecode_MMXReg dh_typecode_ptr
>
>  DEF_HELPER_3(glue(psrlw, SUFFIX), void, env, Reg, Reg)
>  DEF_HELPER_3(glue(psraw, SUFFIX), void, en

Re: [PATCH] acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block

2023-02-28 Thread Christian Ehrhardt

On Thu, Jan 5, 2023 at 8:14 AM Laszlo Ersek  wrote:
>
> On 1/4/23 13:35, Michael S. Tsirkin wrote:
> > On Wed, Jan 04, 2023 at 10:01:38AM +0100, Laszlo Ersek wrote:
> >> The modern ACPI CPU hotplug interface was introduced in the following
> >> series (aa1dd39ca307..679dd1a957df), released in v2.7.0:
> >>
> >>   1  abd49bc2ed2f docs: update ACPI CPU hotplug spec with new protocol
> >>   2  16bcab97eb9f pc: piix4/ich9: add 'cpu-hotplug-legacy' property
> >>   3  5e1b5d93887b acpi: cpuhp: add CPU devices AML with _STA method
> >>   4  ac35f13ba8f8 pc: acpi: introduce AcpiDeviceIfClass.madt_cpu hook
> >>   5  d2238cb6781d acpi: cpuhp: implement hot-add parts of CPU hotplug
> >>   interface
> >>   6  8872c25a26cc acpi: cpuhp: implement hot-remove parts of CPU hotplug
> >>   interface
> >>   7  76623d00ae57 acpi: cpuhp: add cpu._OST handling
> >>   8  679dd1a957df pc: use new CPU hotplug interface since 2.7 machine type
> >>
...
>
> The solution to the riddle

Hi,
just to add to this nicely convoluted case an FYI to everyone involved
back then,
the fix seems to have caused a regression [1] in - as far as I've
found - an edge case.

[1]: https://gitlab.com/qemu-project/qemu/-/issues/1520

...

> Laszlo
>
>


-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

[PATCH] build: disable fcf-protection on -march=486 -m16

2022-03-23 Thread christian . ehrhardt

From: Christian Ehrhardt 

Some of the roms build with -march=i486 -m16 which is incompatible
with -fcf-protection. That in turn is can be set by default, for
example in Ubuntu [1].
That causes:
 cc1: error: ‘-fcf-protection’ is not compatible with this target

This won't work on -march=i486 -m16 and no matter if set or not we can
override it to "none" if the option is known to the compiler to be
able to build reliably.

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

[1]: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection

Signed-off-by: Christian Ehrhardt 
---
 pc-bios/optionrom/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
index 5d55d25acc..f1ef898073 100644
--- a/pc-bios/optionrom/Makefile
+++ b/pc-bios/optionrom/Makefile
@@ -14,6 +14,10 @@ cc-option = $(if $(shell $(CC) $1 -c -o /dev/null -xc 
/dev/null >/dev/null 2>&1
 
 override CFLAGS += -march=i486 -Wall
 
+# If -fcf-protection is enabled in flags or compiler defaults that will
+# conflict with -march=i486
+override CFLAGS += $(call cc-option, -fcf-protection=none)
+
 # Flags for dependency generation
 override CPPFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d
 
-- 
2.35.1

Re: [PATCH-for-7.0] build: disable fcf-protection on -march=486 -m16

2022-03-24 Thread Christian Ehrhardt

On Wed, Mar 23, 2022 at 11:54 AM Philippe Mathieu-Daudé
 wrote:
>
> On 23/3/22 10:07, christian.ehrha...@canonical.com wrote:
> > From: Christian Ehrhardt 
> >
> > Some of the roms build with -march=i486 -m16 which is incompatible
> > with -fcf-protection. That in turn is can be set by default, for
> > example in Ubuntu [1].
> > That causes:
> >   cc1: error: ‘-fcf-protection’ is not compatible with this target
> >
> > This won't work on -march=i486 -m16 and no matter if set or not we can
> > override it to "none" if the option is known to the compiler to be
> > able to build reliably.
> >
> > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/889
> >
> > [1]: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection
> >
> > Signed-off-by: Christian Ehrhardt 
> > ---
> >   pc-bios/optionrom/Makefile | 4 
> >   1 file changed, 4 insertions(+)
>
> Reviewed-by: Philippe Mathieu-Daudé 

Thank you for the review Thomas and Philippe!
For the sake of testing other than my local build checks, the CI jobs
on [1] on gitlab also all passed for this.

[1]: https://gitlab.com/paelzer/qemu/-/pipelines/498917375

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

Hi,
sorry this has fallen through the cracks, but bug 1928075 made me re-discover 
it and it is time finally to complete that.

** Tags added: server-next

** Description changed:

  [Impact]
  
-  * The current space reserved can be too small and we can end up
-with no space at all for BRK. It can happen to any case, but is
-much more likely with the now common PIE binaries.
+  * The current space reserved can be too small and we can end up
+    with no space at all for BRK. It can happen to any case, but is
+    much more likely with the now common PIE binaries.
  
-  * Backport the upstream fix which reserves a bit more space while loading
-and giving it back after interpreter and stack is loaded.
+  * Backport the upstream fix which reserves a bit more space while loading
+    and giving it back after interpreter and stack is loaded.
  
  [Test Plan]
  
-  * On x86 run:
+  * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
-  libc-bin
+  libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  
  
+ Second test from bug 1928075
+ 
+ $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
+ http://ftp.debian.org/debian
+ 
+ In the bad case this is failing like
+ W: Failure trying to run: /sbin/ldconfig
+ W: See //debootstrap/debootstrap.log for detail
+ 
+ And in that log file you'll see the segfault
+ $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
+ qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+ Segmentation fault (core dumped)
+ 
  [Where problems could occur]
  
-  * Regressions would be around use-cases of linux-user that is
-emulation not of a system but of binaries.
-Commonly uses for cross-tests and cross-builds so that is the
-space to watch for regressions
+  * Regressions would be around use-cases of linux-user that is
+    emulation not of a system but of binaries.
+    Commonly uses for cross-tests and cross-builds so that is the
+    space to watch for regressions
  
  [Other Info]
-  
-  * n/a
  
+  * n/a
  
  ---
  
  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being broken
  when run under qemu-user (for all target architectures, host being amd64
  for me).
  
  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)
  
  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c
  
  When we disable this internal implementation and rely on glibc's malloc,
  then everything is fine. But it might be that glibc has a fallback when
  sbrk() is not working properly and it might hide the underlying problem
  in qemu-user.
  
  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080
  
  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb
  
  The version of qemu I have been using is 2.11 (Debian package qemu-user-
  static version 1:2.11+dfsg-1) but I have had reports that the problem is
  reproducible with older versions (back to 2.8 at least).
  
  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599
  
  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/up

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

SRU template updated, PPA rebuilt, Merge requests updated.
Also bundled another bug fix.

Waiting for MR review 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/1749393

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Second test from bug 1928075

  $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
  http://ftp.debian.org/debian

  In the bad case this is failing like
  W: Failure trying to run: /sbin/ldconfig
  W: See //debootstrap/debootstrap.log for detail

  And in that log file you'll see the segfault
  $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [Where problems could occur]

   * Regressions would be around use-cases of linux-user that is
     emulation not of a system but of binaries.
     Commonly uses for cross-tests and cross-builds so that is the
     space to watch for regressions

  [Other Info]

   * n/a

  ---

  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being
  broken when run under qemu-user (for all target architectures, host
  being amd64 for me).

  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)

  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c

  When we disable this internal implementation and rely on glibc's
  malloc, then everything is fine. But it might be that glibc has a
  fallback when sbrk() is not working properly and it might hide the
  underlying problem in qemu-user.

  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb

  The version of qemu I have been using is 2.11 (Debian package qemu-
  user-static version 1:2.11+dfsg-1) but I have had reports that the
  problem is reproducible with older versions (back to 2.8 at least).

  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599

  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

** Changed in: qemu (Ubuntu Focal)
   Status: Triaged => In Progress

** 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 subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Second test from bug 1928075

  $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
  http://ftp.debian.org/debian

  In the bad case this is failing like
  W: Failure trying to run: /sbin/ldconfig
  W: See //debootstrap/debootstrap.log for detail

  And in that log file you'll see the segfault
  $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [Where problems could occur]

   * Regressions would be around use-cases of linux-user that is
     emulation not of a system but of binaries.
     Commonly uses for cross-tests and cross-builds so that is the
     space to watch for regressions

  [Other Info]

   * n/a

  ---

  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being
  broken when run under qemu-user (for all target architectures, host
  being amd64 for me).

  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)

  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c

  When we disable this internal implementation and rely on glibc's
  malloc, then everything is fine. But it might be that glibc has a
  fallback when sbrk() is not working properly and it might hide the
  underlying problem in qemu-user.

  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb

  The version of qemu I have been using is 2.11 (Debian package qemu-
  user-static version 1:2.11+dfsg-1) but I have had reports that the
  problem is reproducible with older versions (back to 2.8 at least).

  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599

  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

Uploaded to F-unapproved, waiting for the SRU team to accept 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/1749393

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Second test from bug 1928075

  $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
  http://ftp.debian.org/debian

  In the bad case this is failing like
  W: Failure trying to run: /sbin/ldconfig
  W: See //debootstrap/debootstrap.log for detail

  And in that log file you'll see the segfault
  $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [Where problems could occur]

   * Regressions would be around use-cases of linux-user that is
     emulation not of a system but of binaries.
     Commonly uses for cross-tests and cross-builds so that is the
     space to watch for regressions

  [Other Info]

   * n/a

  ---

  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being
  broken when run under qemu-user (for all target architectures, host
  being amd64 for me).

  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)

  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c

  When we disable this internal implementation and rely on glibc's
  malloc, then everything is fine. But it might be that glibc has a
  fallback when sbrk() is not working properly and it might hide the
  underlying problem in qemu-user.

  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb

  The version of qemu I have been using is 2.11 (Debian package qemu-
  user-static version 1:2.11+dfsg-1) but I have had reports that the
  problem is reproducible with older versions (back to 2.8 at least).

  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599

  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

Focal

old

$ sudo apt install --reinstall qemu-user-static=1:4.2-3ubuntu6.18
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 21.3 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 
qemu-user-static amd64 1:4.2-3ubuntu6.18 [21.3 MB]
Fetched 21.3 MB in 1s (16.4 MB/s)   
(Reading database ... 126154 files and directories currently installed.)
Preparing to unpack .../qemu-user-static_1%3a4.2-3ubuntu6.18_amd64.deb ...
Unpacking qemu-user-static (1:4.2-3ubuntu6.18) over (1:4.2-3ubuntu6.18) ...
Setting up qemu-user-static (1:4.2-3ubuntu6.18) ...
Processing triggers for man-db (2.9.1-1) ...

ubuntu@f-1928075-qemuuserstatic:~$ sudo chroot /home/ubuntu/bullseye-arm64 
/bin/sh /debootstrap/debootstrap --second-stage
W: Failure trying to run:  /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details
ubuntu@f-1928075-qemuuserstatic:~$ tail -n 2 
bullseye-arm64/debootstrap/debootstrap.log
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

Upgrade


ubuntu@f-1928075-qemuuserstatic:~$ apt-cache policy qemu-user-static
qemu-user-static:
  Installed: 1:4.2-3ubuntu6.18
  Candidate: 1:4.2-3ubuntu6.19
  Version table:
 1:4.2-3ubuntu6.19 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 
Packages
 *** 1:4.2-3ubuntu6.18 500
500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 
Packages
100 /var/lib/dpkg/status
 1:4.2-3ubuntu6.17 500
500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 
Packages
 1:4.2-3ubuntu6 500
500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
ubuntu@f-1928075-qemuuserstatic:~$ sudo apt install qemu-user-static
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  qemu-user-static
1 upgraded, 0 newly installed, 0 to remove and 65 not upgraded.
Need to get 21.3 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 
qemu-user-static amd64 1:4.2-3ubuntu6.19 [21.3 MB]
Fetched 21.3 MB in 2s (9092 kB/s)   
(Reading database ... 126160 files and directories currently installed.)
Preparing to unpack .../qemu-user-static_1%3a4.2-3ubuntu6.19_amd64.deb ...
Unpacking qemu-user-static (1:4.2-3ubuntu6.19) over (1:4.2-3ubuntu6.18) ...
Setting up qemu-user-static (1:4.2-3ubuntu6.19) ...
Processing triggers for man-db (2.9.1-1) ...
ubuntu@f-1928075-qemuuserstatic:~$ sudo update-binfmts  --test --display  
qemu-aarch64
qemu-aarch64 (enabled):
 package = qemu-user-static
type = magic
  offset = 0
   magic = 
\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00
mask = 
\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
 interpreter = /usr/bin/qemu-aarch64-static
detector = 


Test with new versio

ubuntu@f-1928075-qemuuserstatic:~$ sudo chroot /home/ubuntu/bullseye-arm64 
/bin/sh /debootstrap/debootstrap --second-stage
I: Installing core packages...
W: Failure trying to run:  dpkg --force-depends --install 
/var/cache/apt/archives/base-passwd_3.5.51_arm64.deb
W: See //debootstrap/debootstrap.log for details
ubuntu@f-1928075-qemuuserstatic:~$ tail -n 2 
bullseye-arm64/debootstrap/debootstrap.log
dpkg: error: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 duplicate value for 'Package' field


That is the good case and also a full run now completes.

$ sudo rm -rf bullseye-arm64; sudo qemu-debootstrap --arch=arm64 bullseye 
bullseye-arm64 http://ftp.debian.org/debian
I: Running command: debootstrap --arch arm64 --foreign bullseye bullseye-arm64 
http://ftp.debian.org/debian
W: Cannot check Release signature; keyring file not available 
/usr/share/keyrings/debian-archive-keyring.gpg
I: Retrieving InRelease 
I: Retrieving Packages 
...
I: Configuring tasksel...
I: Configuring libc-bin...
I: Base system installed successfully.


I can't run the docker test due to networking restrictions, but it was
the same fault and the same fix - so that should be ok. If anyone else
can test -proposed with docker please feel free to do so.

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

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

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

Re: [PATCH] acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block

2023-03-02 Thread Christian Ehrhardt

On Wed, Mar 1, 2023 at 9:04 AM Laszlo Ersek  wrote:
>
> Hello Christian,
>
> On 3/1/23 08:17, Christian Ehrhardt wrote:
> > On Thu, Jan 5, 2023 at 8:14 AM Laszlo Ersek  wrote:
> >>
> >> On 1/4/23 13:35, Michael S. Tsirkin wrote:
> >>> On Wed, Jan 04, 2023 at 10:01:38AM +0100, Laszlo Ersek wrote:
> >>>> The modern ACPI CPU hotplug interface was introduced in the following
> >>>> series (aa1dd39ca307..679dd1a957df), released in v2.7.0:
> >>>>
> >>>>   1  abd49bc2ed2f docs: update ACPI CPU hotplug spec with new protocol
> >>>>   2  16bcab97eb9f pc: piix4/ich9: add 'cpu-hotplug-legacy' property
> >>>>   3  5e1b5d93887b acpi: cpuhp: add CPU devices AML with _STA method
> >>>>   4  ac35f13ba8f8 pc: acpi: introduce AcpiDeviceIfClass.madt_cpu hook
> >>>>   5  d2238cb6781d acpi: cpuhp: implement hot-add parts of CPU hotplug
> >>>>   interface
> >>>>   6  8872c25a26cc acpi: cpuhp: implement hot-remove parts of CPU hotplug
> >>>>   interface
> >>>>   7  76623d00ae57 acpi: cpuhp: add cpu._OST handling
> >>>>   8  679dd1a957df pc: use new CPU hotplug interface since 2.7 machine 
> >>>> type
> >>>>
> > ...
> >>
> >> The solution to the riddle
> >
> > Hi,
> > just to add to this nicely convoluted case an FYI to everyone involved
> > back then,
> > the fix seems to have caused a regression [1] in - as far as I've
> > found - an edge case.
> >
> > [1]: https://gitlab.com/qemu-project/qemu/-/issues/1520
>
> After reading the gitlab case, here's my theory on it:
>
> - Without the patch applied, the CPU hotplug register block in QEMU is
> broken. Effectively, it has *always* been broken; to put it differently,
> you have most likely *never* seen a QEMU in which the CPU hotplug
> register block was not broken. The reason is that the only QEMU release
> without the breakage (as far as a guest could see it!) was v5.0.0, but
> it got exposed to the guest as early as v5.1.0 (IOW, in the 5.* series,
> the first stable release already exposed the issue), and the symptom has
> existed since (up to and including 7.2).
>
> - With the register block broken, OVMF's multiprocessing is broken, and
> the random chaos just happens to play out in a way that makes OVMF think
> it's running on a uniprocessor system.
>
> - With the register block *fixed* (commit dab30fbe applied), OVMF
> actually boots up your VCPUs. With MT-TCG, this translates to as many
> host-side VCPU threads running in your QEMU process as you have VCPUs.
>
> - Furthermore, if your OVMF build includes the SMM driver stack, then
> each UEFI variable update will require all VCPUs to enter SMM. All VCPUs
> entering SMM is a "thundering herd" event, so it seriously spins up all
> your host-side threads. (I assume the SMM-enabled binaries are what you
> refer to as "signed OVMF cases" in the gitlab ticket.)
>
> - If you overcommit the VCPUs (#vcpus > #pcpus), then your host-side
> threads will be competing for PCPUs. On s390x, there is apparently some
> bottleneck in QEMU's locking or in the host kernel or wherever else that
> penalizes (#threads > #pcpus) heavily, while on other host arches, the
> penalty is (apparently) not as severe.
>
> So, the QEMU fix actually "only exposes" the high penalty of the MT-TCG
> VCPU thread overcommit that appears characteristic of s390x hosts.
> You've not seen this symptom before because, regardless of how many
> VCPUs you've specified in the past, OVMF has never actually attempted to
> bring those up, due to the hotplug regblock breakage "masking" the
> actual VCPU counts (the present-at-boot VCPU count and the possible max
> VCPU count).

Thank you for the detailed thoughts - if we can confirm this we can
close the case as "it is odd that there is so much penalty, but =>
Won't Fix / Works as Intended"

> Here's a test you could try: go back to QEMU v5.0.0 *precisely*, and try
> to reproduce the symptom. I expect that it should reproduce.

v5.0.0 - 1 host cpu vs 2 vcpu - 58.47s
v5.0.0 - 1 host cpu vs 1 vcpu -  5.33s
v5.0.0 - 2 host cpu vs 2 vcpu -  5.27s
v5.1.0 - 1 host cpu vs 2 vcpu -  7.18s
v5.1.0 - 1 host cpu vs 1 vcpu -  5.22s
v5.1.0 - 2 host cpu vs 2 vcpu -  5.40s

Yes, v5.0.0 behaves exactly like the recent master branch does since your fix.
And v5.1.0 does no more, just as you predicted

> Here's another test you can try: with latest QEMU, boot an x86 Linux
> guest, but using SeaBIOS, not OVMF, on your s390x host. T

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

2021-12-16 Thread Christian Ehrhardt 

FYI the release of this is slowed down by the slow verification of bug
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1929926

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

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Second test from bug 1928075

  $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
  http://ftp.debian.org/debian

  In the bad case this is failing like
  W: Failure trying to run: /sbin/ldconfig
  W: See //debootstrap/debootstrap.log for detail

  And in that log file you'll see the segfault
  $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [Where problems could occur]

   * Regressions would be around use-cases of linux-user that is
     emulation not of a system but of binaries.
     Commonly uses for cross-tests and cross-builds so that is the
     space to watch for regressions

  [Other Info]

   * n/a

  ---

  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being
  broken when run under qemu-user (for all target architectures, host
  being amd64 for me).

  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)

  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c

  When we disable this internal implementation and rely on glibc's
  malloc, then everything is fine. But it might be that glibc has a
  fallback when sbrk() is not working properly and it might hide the
  underlying problem in qemu-user.

  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb

  The version of qemu I have been using is 2.11 (Debian package qemu-
  user-static version 1:2.11+dfsg-1) but I have had reports that the
  problem is reproducible with older versions (back to 2.8 at least).

  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599

  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

2022-01-03 Thread Christian Ehrhardt 

Thank you Frank for that extra confirmation,
by now also all the blockers on the other bug fixed are good. I expect this to 
be released as soon as the SRU Team is back from the Christmas shutdown.

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

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

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

Bug description:
  [Impact]

   * The current space reserved can be too small and we can end up
     with no space at all for BRK. It can happen to any case, but is
     much more likely with the now common PIE binaries.

   * Backport the upstream fix which reserves a bit more space while loading
     and giving it back after interpreter and stack is loaded.

  [Test Plan]

   * On x86 run:
  sudo apt install -y qemu-user-static docker.io
  sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt 
install -y wget'
  ...
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Second test from bug 1928075

  $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64
  http://ftp.debian.org/debian

  In the bad case this is failing like
  W: Failure trying to run: /sbin/ldconfig
  W: See //debootstrap/debootstrap.log for detail

  And in that log file you'll see the segfault
  $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [Where problems could occur]

   * Regressions would be around use-cases of linux-user that is
     emulation not of a system but of binaries.
     Commonly uses for cross-tests and cross-builds so that is the
     space to watch for regressions

  [Other Info]

   * n/a

  ---

  In Debian unstable, we recently switched bash to be a PIE-compiled
  binary (for hardening). Unfortunately this resulted in bash being
  broken when run under qemu-user (for all target architectures, host
  being amd64 for me).

  $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)

  bash has its own malloc implementation based on sbrk():
  https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c

  When we disable this internal implementation and rely on glibc's
  malloc, then everything is fine. But it might be that glibc has a
  fallback when sbrk() is not working properly and it might hide the
  underlying problem in qemu-user.

  This issue has also been reported to the bash upstream author and he 
suggested that the issue might be in qemu-user so I'm opening a ticket here. 
Here's the discussion with the bash upstream author:
  https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

  You can find the problematic bash binary in that .deb file:
  
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb

  The version of qemu I have been using is 2.11 (Debian package qemu-
  user-static version 1:2.11+dfsg-1) but I have had reports that the
  problem is reproducible with older versions (back to 2.8 at least).

  Here are the related Debian bug reports:
  https://bugs.debian.org/889869
  https://bugs.debian.org/865599

  It's worth noting that bash used to have this problem (when compiled as a PIE 
binary) even when run directly but then something got fixed in the kernel and 
now the problem only appears when run under qemu-user:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

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

[Bug 1868116] Re: QEMU monitor no longer works

2021-05-04 Thread Christian Ehrhardt 

@Thomas - there is a leftover task here and I've filed [1] for it in the new 
tracker.
What is the right state to move this bug here into now?

[1]: https://gitlab.com/qemu-project/qemu/-/issues/137

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

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

Title:
  QEMU monitor no longer works

Status in QEMU:
  Incomplete
Status in qemu package in Ubuntu:
  Invalid
Status in vte2.91 package in Ubuntu:
  Fix Released
Status in qemu package in Debian:
  Fix Released

Bug description:
  Repro:
  VTE
  $ meson _build && ninja -C _build && ninja -C _build install

  qemu:
  $ ../configure --python=/usr/bin/python3 --disable-werror --disable-user 
--disable-linux-user --disable-docs --disable-guest-agent --disable-sdl 
--enable-gtk --disable-vnc --disable-xen --disable-brlapi --disable-fdt 
--disable-hax --disable-vde --disable-netmap --disable-rbd --disable-libiscsi 
--disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir 
--disable-seccomp --disable-glusterfs --disable-tpm --disable-numa 
--disable-opengl --disable-virglrenderer --disable-xfsctl --disable-vxhs 
--disable-slirp --disable-blobs --target-list=x86_64-softmmu --disable-rdma 
--disable-pvrdma --disable-attr --disable-vhost-net --disable-vhost-vsock 
--disable-vhost-scsi --disable-vhost-crypto --disable-vhost-user 
--disable-spice --disable-qom-cast-debug --disable-vxhs --disable-bochs 
--disable-cloop --disable-dmg --disable-qcow1 --disable-vdi --disable-vvfat 
--disable-qed --disable-parallels --disable-sheepdog --disable-avx2 
--disable-nettle --disable-gnutls --disable-capstone --disable-tools 
--disable-libpmem --disable-iconv --disable-cap-ng
  $ make

  Test:
  $ LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH 
./build/x86_64-softmmu/qemu-system-x86_64 -enable-kvm --drive 
media=cdrom,file=http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso
  - switch to monitor with CTRL+ALT+2
  - try to enter something

  Affects head of both usptream git repos.

  
  --- original bug ---

  It was observed that the QEMU console (normally accessible using
  Ctrl+Alt+2) accepts no input, so it can't be used. This is being
  problematic because there are cases where it's required to send
  commands to the guest, or key combinations that the host would grab
  (as Ctrl-Alt-F1 or Alt-F4).

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: qemu 1:4.2-3ubuntu2
  Uname: Linux 5.6.0-rc6+ x86_64
  ApportVersion: 2.20.11-0ubuntu20
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Thu Mar 19 12:16:31 2020
  Dependencies:

  InstallationDate: Installed on 2017-06-13 (1009 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine:
   COMMAND STAT  EUID  RUID PIDPPID %CPU COMMAND
   qemu-system-x86 Sl+   1000  1000   34275   25235 29.2 qemu-system-x86_64 -m 
4G -cpu Skylake-Client -device virtio-vga,virgl=true,xres=1280,yres=720 -accel 
kvm -device nec-usb-xhci -serial vc -serial stdio -hda 
/home/usuario/Sistemas/androidx86.img -display gtk,gl=on -device usb-audio
   kvm-nx-lpage-re S0 0   34284   2  0.0 [kvm-nx-lpage-re]
   kvm-pit/34275   S0 0   34286   2  0.0 [kvm-pit/34275]
  MachineType: LENOVO 80UG
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc6+ 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 
kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 
i915.enable_gvt=1 i915.fastboot=1 cgroup_enable=memory swapaccount=1 
zswap.enabled=1 zswap.zpool=z3fold 
resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M 
usbhid.quirks=0x0079:0x0006:0x10 config_scsi_mq_default=y 
scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 
nbd.max_part=63
  SourcePackage: qemu
  UpgradeStatus: Upgraded to focal on 2019-12-22 (87 days ago)
  dmi.bios.date: 08/09/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN45WW
  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:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO
  mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240

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

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

2017-01-18 Thread Christian Ehrhardt

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

Signed-off-by: Christian Ehrhardt 
---
 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] [PATCH for-2.10 v2 0/4] block: Fix non-shared storage migration

2017-08-18 Thread 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] [PATCH v2] configure: enable --s390-pgste linker option

2017-08-23 Thread 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] [PULL 0/6] NBD pull request for 2.10-rc4

2017-08-23 Thread 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!

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

2017-08-28 Thread 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] [PATCH 2/2] file-posix: Do runtime check for ofd lock API

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

2017-08-11 Thread Christian Ehrhardt

AxNzA4MTA=
(chain depth: 1)

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

2017-08-11 Thread Christian Ehrhardt

On Fri, Aug 11, 2017 at 2:37 PM, Kevin Wolf  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 
> > 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).

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

2018-01-23 Thread 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] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Christian Ehrhardt

On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
 wrote:
>
>
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
>> 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/
>
> 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] proposed release schedule for QEMU 2.12

2018-01-31 Thread 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

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

2017-12-13 Thread 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 
---
 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] [PATCH v3 0/3] s390x/kvm: implement new hardware/firmware features

2018-01-18 Thread 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/

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

2018-01-22 Thread 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
 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 
> ---
>  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] Live migration from Qemu 2.12 hosts to Qemu 3.2 hosts, with VMX flag enabled in the guest?

2019-01-17 Thread 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(&vmx_mig_blocker,
> +   "Nested VMX virtualization does not support live
> migration yet");
> +r = migrate_add_blocker(vmx_mig_blocker, &local_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 1769053] Re: Cannot start a guest with more than 1TB of RAM

2018-05-15 Thread  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

2018-05-15 Thread  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

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

2018-05-15 Thread  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 1722074] Re: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

2018-05-23 Thread  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 1722074] Re: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

2018-05-23 Thread  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

2018-05-23 Thread  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 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 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

[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 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 **: 16:01:45.7

[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 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/libspi

[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.
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/libsp

[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 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-system-x86

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

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

* Shut it down and use v

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