Debian Bug report logs - #964793
qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: 小太 <nospam@kota.moe>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Date: Sat, 11 Jul 2020 00:29:13 +1000

Package: qemu-system-x86
Version: 1:5.0-5
Severity: important

I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
migrated to testing).

After upgrading, trying to boot a Xen HVM DomU (in this case named "windows")
crashes immediately, with the following logs in /var/log/xen/xl-windows.log:

> Waiting for domain windows (domid 1) to die [pid 2583]
> Domain 1 has shut down, reason code 3 0x3
> Action for shutdown reason code 3 is destroy
> Domain 1 needs to be cleaned up: destroying the domain
> Done. Exiting now

(reason code 3 means "crashed":
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/sched.h;hb=3fdc211b01b29f252166937238efe02d15cb5780#l178)

I tried again with a minimal xl.cfg file, and it resulted in the same crash.
The minimal xl.cfg contents:

> name = "windows"
> builder = "hvm"
> vcpus = "4"
> memory = "1024"
> boot = "c"

After downgrading qemu-system-x86 back down to 1:5.0-5, functionality was
restored and the DomU was able to boot again.

---

I vaguely remember these crash-at-boot problems are often caused by Xen and
Qemu versions being out of sync.

I see a new version of xen in unstable (4.11.4+24-gddaaccbbab-1), but not yet
promoted to testing yet, so I haven't installed or tested it.

However, if it ends up fixing the problem with qemu 1:5.0-6, then maybe the
real bug is that qemu and xen releases should be coordinated to be promoted
together?



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu             1.0.0+git-20190125.36a4c85-5
ii  libaio1               0.3.112-8
ii  libasound2            1.2.2-2.3
ii  libbrlapi0.7          6.0+dfsg-6
ii  libc6                 2.30-8
ii  libcacard0            1:2.6.1-1
ii  libcapstone3          4.0.1+really+3.0.5-2
ii  libepoxy0             1.5.4-1
ii  libfdt1               1.6.0-1
ii  libgbm1               20.1.2-1
ii  libgcc-s1             10.1.0-4
ii  libglib2.0-0          2.64.3-2
ii  libgnutls30           3.6.14-2
ii  libibverbs1           29.0-1
ii  libjpeg62-turbo       1:1.5.2-2+b1
ii  libncursesw6          6.2-1
ii  libnettle7            3.5.1+really3.5.1-2
ii  libnuma1              2.0.12-1+b1
ii  libpixman-1-0         0.36.0-1
ii  libpmem1              1.8-1
ii  libpng16-16           1.6.37-2
ii  librdmacm1            29.0-1
ii  libsasl2-2            2.1.27+dfsg-2
ii  libseccomp2           2.4.3-1+b1
ii  libslirp0             4.2.0-2
ii  libspice-server1      0.14.3-1
ii  libtinfo6             6.2-1
ii  liburing1             0.6-3
ii  libusb-1.0-0          2:1.0.23-2
ii  libusbredirparser1    0.8.0-1+b1
ii  libvdeplug2           2.3.2+r586-2.2+b1
ii  libvirglrenderer1     0.8.2-2
ii  libxendevicemodel1    4.11.4-1
ii  libxenevtchn1         4.11.4-1
ii  libxenforeignmemory1  4.11.4-1
ii  libxengnttab1         4.11.4-1
ii  libxenmisc4.11        4.11.4-1
ii  libxenstore3.0        4.11.4-1
ii  libxentoolcore1       4.11.4-1
ii  qemu-system-common    1:5.0-6
ii  qemu-system-data      1:5.0-6
ii  seabios               1.13.0-1
ii  zlib1g                1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf             2020.05-2
ii  qemu-system-gui  1:5.0-6
ii  qemu-utils       1:5.0-6

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra            <none>
ii  qemu-system-data [sgabios]  1:5.0-6
pn  samba                       <none>
pn  vde2                        <none>

-- no debconf information

Message #10 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 小太 <nospam@kota.moe>, 964793@bugs.debian.org

Subject: Re: Bug#964793: qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Date: Sat, 11 Jul 2020 13:37:26 +0300

10.07.2020 17:29, 小太 wrote:
> Package: qemu-system-x86
> Version: 1:5.0-5
> Severity: important
> 
> I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
> migrated to testing).
> 
> After upgrading, trying to boot a Xen HVM DomU (in this case named "windows")
> crashes immediately, with the following logs in /var/log/xen/xl-windows.log:

Can you see where exactly it is failing, can you get a backtrace for it?

There's no changes in 5.0-6 (compared to 5.0-5) which are related to xen.
However there is a significant change in the toolchain, I wonder if this
might be related.. With this in mind, I wonder if compiling 5.0-5 with
current toolchain will make any difference, in this case if it will make
the same issue to pop up in 5.0-5 too.

Thanks!

/mjt

Message #15 received at 964793@bugs.debian.org (full text, mbox, reply):

From: ‍小太 <nospam@kota.moe>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 964793@bugs.debian.org

Subject: Re: Bug#964793: qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Date: Sun, 12 Jul 2020 19:25:42 +1000

On Sat, 11 Jul 2020 at 20:37, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> 10.07.2020 17:29, 小太 wrote:
> > Package: qemu-system-x86
> > Version: 1:5.0-5
> > Severity: important
> >
> > I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
> > migrated to testing).
> >
> > After upgrading, trying to boot a Xen HVM DomU (in this case named "windows")
> > crashes immediately, with the following logs in /var/log/xen/xl-windows.log:
>
> Can you see where exactly it is failing, can you get a backtrace for it?

I'm not sure where it's failing - running qemu under gdb results in it
receiving a SIGHUP, after xl has claimed the domain has exited.
Starting the domain as paused and attaching to it shows the memory as
empty, and then unpausing the domain immediately exits it (despite gdb
paused on the first instruction).

Perhaps it's somewhere in Xen code? Though I don't really know how to
debug Xen itself (xl dmesg doesn't show anything unusual).
Maybe it's something better suited for a Xen dev to debug?

>
> There's no changes in 5.0-6 (compared to 5.0-5) which are related to xen.
> However there is a significant change in the toolchain, I wonder if this
> might be related.. With this in mind, I wonder if compiling 5.0-5 with
> current toolchain will make any difference, in this case if it will make
> the same issue to pop up in 5.0-5 too.
>
> Thanks!
>
> /mjt

Message #20 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 小太 <nospam@kota.moe>, 964793@bugs.debian.org

Subject: Re: Bug#964793: qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Date: Sun, 12 Jul 2020 12:55:56 +0300

10.07.2020 17:29, 小太 wrote:
> Package: qemu-system-x86
> Version: 1:5.0-5

> I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
> migrated to testing).
[bug/crash]

> After downgrading qemu-system-x86 back down to 1:5.0-5, functionality was
> restored and the DomU was able to boot again.

So, I'm not sure I understand, -- why did you file this bug against -5, when
what you describe sounds like -5 didn't have it while -6 did? Am I right
guessing that you just used the wrong version number when filing the bugreport?

Thanks!

/mjt

Message #25 received at 964793@bugs.debian.org (full text, mbox, reply):

From: ‍小太 <nospam@kota.moe>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 964793@bugs.debian.org

Subject: Re: Bug#964793: qemu-system-x86: qemu 1:5.0-6 causes xen 4.11.4-1 HVM domains to crash at boot

Date: Sun, 12 Jul 2020 20:05:56 +1000

On Sun, 12 Jul 2020 at 19:55, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> 10.07.2020 17:29, 小太 wrote:
> > Package: qemu-system-x86
> > Version: 1:5.0-5
>
> > I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
> > migrated to testing).
> [bug/crash]
>
> > After downgrading qemu-system-x86 back down to 1:5.0-5, functionality was
> > restored and the DomU was able to boot again.
>
> So, I'm not sure I understand, -- why did you file this bug against -5, when
> what you describe sounds like -5 didn't have it while -6 did? Am I right
> guessing that you just used the wrong version number when filing the bugreport?

I used the reportbug tool, which never asked me for a qemu version.
Presumably it just put the currently-installed version into the bug
report, rather than the version I actually wanted to report the bug
against

>
> Thanks!
>
> /mjt

Message #34 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Christian Ehrhardt <christian.ehrhardt@canonical.com>

To: 964793@bugs.debian.org

Subject: odd qemu/xen crashes + toolchain rings a bell

Date: Mon, 13 Jul 2020 09:01:18 +0200

[Message part 1 (text/plain, inline)]

Hi,
I was seeing the bug updates flying by and just wanted to mention that we
have seen something similar in Ubuntu - but back then things weren't
replicable on Debian so we couldn't contribute things back.
It seemed to be due to the newer and different-defaults toolchain that we
had in Ubuntu at the time.

But here qemu/xen crashes + new toolchain come together again which
reminded me.

So without any promises that it really is related I wanted to FYI you to
these two fixes we needed for Xen:
https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/groovy-devel
https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1000-flags-fcs-protect-none.patch?h=ubuntu/groovy-devel

This would seem more applicable if the new toolchain would have recently
rebuilt xen and not qemu as in this case. But as an FYI it is still worth a
ping.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

[Message part 2 (text/html, inline)]

Message #39 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Hans van Kranenburg <hans@knorrie.org>

To: 964793@bugs.debian.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Michael Tokarev <mjt@tls.msk.ru>, 小太 <nospam@kota.moe>

Subject: Re: odd qemu/xen crashes + toolchain rings a bell

Date: Mon, 13 Jul 2020 16:19:44 +0200

(Adding more To:; Note that mailing the bug number does not make it end
up at the submitter automatically, only the package maintainer).

Hi Christian,

thanks for the hints!

On Mon, 13 Jul 2020 09:01:18 +0200 Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Hi,
> I was seeing the bug updates flying by and just wanted to mention that we
> have seen something similar in Ubuntu - but back then things weren't
> replicable on Debian so we couldn't contribute things back.
> It seemed to be due to the newer and different-defaults toolchain that we
> had in Ubuntu at the time.
> 
> But here qemu/xen crashes + new toolchain come together again which
> reminded me.
> 
> So without any promises that it really is related I wanted to FYI you to
> these two fixes we needed for Xen:
> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/groovy-devel

I guess this first one would be one needed? "Force fcf-protection off
when using -mindirect-branch".

In that case want this one, it's not backported to 4.11-stable:

"x86/build: Unilaterally disable -fcf-protection"

https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a218961b16f1f4feb1147f56338faf1ac8f5703

> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1000-flags-fcs-protect-none.patch?h=ubuntu/groovy-devel

This one is about the build failing.

> This would seem more applicable if the new toolchain would have recently
> rebuilt xen and not qemu as in this case. But as an FYI it is still worth a
> ping.

小太, can you do...

  xl create -vvv <domU.cfg>

...which should show how qemu is invoked. Can you show that command?

I can provide you with some test packages with the mentioned upstream
patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
your domU starts with them.

If so, we can request the backport upstream and/or maybe pick it for
Debian 4.11 into the patch queue, whatever happens earlier.

Thanks,
Hans (Debian Xen Team)

Message #44 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Hans van Kranenburg <hans@knorrie.org>

To: 964793@bugs.debian.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Michael Tokarev <mjt@tls.msk.ru>, 小太 <nospam@kota.moe>

Subject: Re: odd qemu/xen crashes + toolchain rings a bell

Date: Tue, 14 Jul 2020 00:27:08 +0200

However,

On 7/13/20 4:19 PM, Hans van Kranenburg wrote:
> (Adding more To:; Note that mailing the bug number does not make it end
> up at the submitter automatically, only the package maintainer).
> 
> Hi Christian,
> 
> thanks for the hints!
> 
> On Mon, 13 Jul 2020 09:01:18 +0200 Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
>> Hi,
>> I was seeing the bug updates flying by and just wanted to mention that we
>> have seen something similar in Ubuntu - but back then things weren't
>> replicable on Debian so we couldn't contribute things back.
>> It seemed to be due to the newer and different-defaults toolchain that we
>> had in Ubuntu at the time.
>>
>> But here qemu/xen crashes + new toolchain come together again which
>> reminded me.
>>
>> So without any promises that it really is related I wanted to FYI you to
>> these two fixes we needed for Xen:
>> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/groovy-devel
> 
> I guess this first one would be one needed? "Force fcf-protection off
> when using -mindirect-branch".
> 
> In that case want this one, it's not backported to 4.11-stable:
> 
> "x86/build: Unilaterally disable -fcf-protection"
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a218961b16f1f4feb1147f56338faf1ac8f5703

However, this is a workaround for a gcc bug that is fixed in:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a03efb266f

This fix is included in gcc-9 in Debian since 9.3.0-12:

https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-9-debian/debian/changelog#L55
(it's the PR target/93654 (x86))

Reporter says the 4.11.4-1 package is used, which is built using gcc
9.3.0-13:

https://buildd.debian.org/status/fetch.php?pkg=xen&arch=all&ver=4.11.4-1&stamp=1590602099&raw=0

>> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1000-flags-fcs-protect-none.patch?h=ubuntu/groovy-devel
> 
> This one is about the build failing.
> 
>> This would seem more applicable if the new toolchain would have recently
>> rebuilt xen and not qemu as in this case. But as an FYI it is still worth a
>> ping.
> 
> 小太, can you do...
> 
>   xl create -vvv <domU.cfg>
> 
> ...which should show how qemu is invoked. Can you show that command?
> 
> I can provide you with some test packages with the mentioned upstream
> patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> your domU starts with them.
> 
> If so, we can request the backport upstream and/or maybe pick it for
> Debian 4.11 into the patch queue, whatever happens earlier.

So, the above info tells us that this probably is not the issue that
we're looking at. (I'm fine with still making some test packages for
reporter to test with to 100% check this.)

Then, let's see what shows up in the xl -vvv output and if there's
anything that can be debugged when starting the qemu process with those
args?

> Thanks,
> Hans (Debian Xen Team)
> 

Message #49 received at 964793@bugs.debian.org (full text, mbox, reply):

From: ‍小太 <nospam@kota.moe>

To: Hans van Kranenburg <hans@knorrie.org>

Cc: 964793@bugs.debian.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Michael Tokarev <mjt@tls.msk.ru>

Subject: Re: odd qemu/xen crashes + toolchain rings a bell

Date: Tue, 14 Jul 2020 19:21:57 +1000

On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg <hans@knorrie.org> wrote:
> 小太, can you do...
>
>   xl create -vvv <domU.cfg>
>
> ...which should show how qemu is invoked. Can you show that command?
>
> I can provide you with some test packages with the mentioned upstream
> patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> your domU starts with them.
>
> If so, we can request the backport upstream and/or maybe pick it for
> Debian 4.11 into the patch queue, whatever happens earlier.

I've updated Xen to 4.11.4+24-gddaaccbbab-1 now, but qemu is still at 1:5.0-5.
I'll update qemu again to 1:5.0-6 tomorrow and run a test, but for
now, here's the relevant output with 1:5.0-5

I'd be happy to run any custom version of qemu you have in mind

libxl: debug: libxl_dm.c:2331:libxl__spawn_local_dm: Domain 2:Spawning
device-model /usr/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
/usr/bin/qemu-system-i386
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -xen-domid
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  2
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -chardev
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -no-shutdown
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -mon
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -chardev
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-2,server,nowait
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -mon
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
chardev=libxenstat-cmd,mode=control
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -nodefaults
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -no-user-config
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -name
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  windows2
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -vnc
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
127.0.0.1:0,to=99
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -display
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  none
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -device
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:
cirrus-vga,vgamem_mb=8
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -boot
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  order=c
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -smp
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  4,maxcpus=4
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -net
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  none
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -machine
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  xenfv
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  -m
libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 2:  504
libxl: debug: libxl_dm.c:2335:libxl__spawn_local_dm: Domain 2:Spawning
device-model /usr/bin/qemu-system-i386 with additional environment:
libxl: debug: libxl_dm.c:2337:libxl__spawn_local_dm: Domain 2:
XEN_QEMU_CONSOLE_LIMIT=1048576

Message #54 received at 964793@bugs.debian.org (full text, mbox, reply):

From: ‍小太 <nospam@kota.moe>

To: Hans van Kranenburg <hans@knorrie.org>

Cc: 964793@bugs.debian.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Michael Tokarev <mjt@tls.msk.ru>

Subject: Re: odd qemu/xen crashes + toolchain rings a bell

Date: Wed, 15 Jul 2020 14:41:33 +1000

[Message part 1 (text/plain, inline)]

On Tue, 14 Jul 2020 at 19:21, ‍小太 <nospam@kota.moe> wrote:
>
> On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg <hans@knorrie.org> wrote:
> > 小太, can you do...
> >
> >   xl create -vvv <domU.cfg>
> >
> > ...which should show how qemu is invoked. Can you show that command?
> >
> > I can provide you with some test packages with the mentioned upstream
> > patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> > your domU starts with them.
> >
> > If so, we can request the backport upstream and/or maybe pick it for
> > Debian 4.11 into the patch queue, whatever happens earlier.
>
> I've updated Xen to 4.11.4+24-gddaaccbbab-1 now, but qemu is still at 1:5.0-5.
> I'll update qemu again to 1:5.0-6 tomorrow and run a test

I've tried qemu 1:5.0-6 with xen 4.11.4+24-gddaaccbbab-1 today, and
attached is the full output of: xl -vvv create windows.xen.cfg -F
It's a bit too long to directly include in this email :/

The contents on windows.xen.cfg for this run were:

name = "windows"
builder = "hvm"
vcpus = "4"
memory = "1024"
boot = "c"

[xl.log (text/x-log, attachment)]

Message #59 received at 964793@bugs.debian.org (full text, mbox, reply):

From: ‍小太 <nospam@kota.moe>

To: Hans van Kranenburg <hans@knorrie.org>

Cc: 964793@bugs.debian.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Michael Tokarev <mjt@tls.msk.ru>

Subject: Re: odd qemu/xen crashes + toolchain rings a bell

Date: Wed, 15 Jul 2020 14:53:00 +1000

[Message part 1 (text/plain, inline)]

On Wed, 15 Jul 2020 at 14:41, ‍小太 <nospam@kota.moe> wrote:
>
> On Tue, 14 Jul 2020 at 19:21, ‍小太 <nospam@kota.moe> wrote:
> >
> > On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg <hans@knorrie.org> wrote:
> > > 小太, can you do...
> > >
> > >   xl create -vvv <domU.cfg>
> > >
> > > ...which should show how qemu is invoked. Can you show that command?
> > >
> > > I can provide you with some test packages with the mentioned upstream
> > > patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> > > your domU starts with them.
> > >
> > > If so, we can request the backport upstream and/or maybe pick it for
> > > Debian 4.11 into the patch queue, whatever happens earlier.
> >
> > I've updated Xen to 4.11.4+24-gddaaccbbab-1 now, but qemu is still at 1:5.0-5.
> > I'll update qemu again to 1:5.0-6 tomorrow and run a test
>
> I've tried qemu 1:5.0-6 with xen 4.11.4+24-gddaaccbbab-1 today, and
> attached is the full output of: xl -vvv create windows.xen.cfg -F
> It's a bit too long to directly include in this email :/
>
> The contents on windows.xen.cfg for this run were:
>
> name = "windows"
> builder = "hvm"
> vcpus = "4"
> memory = "1024"
> boot = "c"

And attached is the same command and config output, but with qemu 1:5.0-5

There appears to be no practical difference between the two logs (at
least before the crash)

[xl-working.log (text/x-log, attachment)]

Message #64 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Max Ried <max.ried@hhu.de>

To: 964793@bugs.debian.org

Subject: qemu-system-x86 crash

Date: Mon, 20 Jul 2020 13:55:40 +0200

[Message part 1 (text/plain, inline)]

Hi,

I experience exactly the same bevahiour after installing 
1:3.1+dfsg-8+deb10u6 on Debian as Dom0 with Xen version 
4.11.4+24-gddaaccbbab-1~deb10u1. No interessting output in any log files 
as far as I can tell. Downgrading the qemu-system-x86 packet to 
1:3.1+dfsg-8+deb10u5 immediately fixes the problem.

Thanks,
Max

-- 
Max Ried
Heinrich-Heine-Universität Düsseldorf
Institut für Informatik
Systemadministration
Gebäude 25.12, Raum 01.28
Universitätsstr. 1
40225 Düsseldorf
Tel: +49 211 81 10715

[smime.p7s (application/pkcs7-signature, attachment)]

Message #69 received at 964793@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Max Ried <max.ried@hhu.de>, 964793@bugs.debian.org

Subject: Re: Bug#964793: qemu-system-x86 crash

Date: Mon, 20 Jul 2020 17:51:26 +0300

Control: tag -1 + confirmed upstream


I'm working on this. Reproduced, found the "messenger", now
trying to find the root case.

/mjt

Message #78 received at 964793-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 964793-close@bugs.debian.org

Subject: Bug#964793: fixed in qemu 1:5.0-11

Date: Mon, 20 Jul 2020 16:05:28 +0000

Source: qemu
Source-Version: 1:5.0-11
Done: Michael Tokarev <mjt@tls.msk.ru>

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 964793@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 20 Jul 2020 18:41:17 +0300
Source: qemu
Architecture: source
Version: 1:5.0-11
Distribution: unstable
Urgency: high
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 964793
Changes:
 qemu (1:5.0-11) unstable; urgency=high
 .
   * d/control-in: only enable opengl (libdrm&Co) on linux
   * d/control-in: spice: drop versioned deps (even jessie version is enough),
     drop libspice-protocol-dev (automatically pulled by libspice-server-dev),
     and build on more architectures
   * change from debhelper versioned dependency to debhelper-compat (=12)
   * acpi-allow-accessing-acpi-cnt-register-by-byte.patch' (Closes: #964793)
     This is another incarnation of the recent bugfix which actually enabled
     memory access constraints, like #964247
     Urgency = high due to this issue.
Checksums-Sha1:
 1d274990f08ada7dd8b264f4c42bd9b25156a119 6737 qemu_5.0-11.dsc
 63fc5f60f167ce0d000b9593eb47d0698835b181 108840 qemu_5.0-11.debian.tar.xz
 7ae342164fe0e78c9f9210985034510b05b025d8 9221 qemu_5.0-11_source.buildinfo
Checksums-Sha256:
 40c4a489003c23174d1713398b3cb30896c3cfbb24c87182dedde6490c1b4467 6737 qemu_5.0-11.dsc
 1ff29fade52ce585a1155b6bdfd1ed01f3db12ba9534a98ad9477e1584a69795 108840 qemu_5.0-11.debian.tar.xz
 4cf1f457079cd2740c99938287182cb96f38ff075bf95f1878b6c91e07ddedb9 9221 qemu_5.0-11_source.buildinfo
Files:
 2be16fcc81009224b064cd150874cd27 6737 otherosfs optional qemu_5.0-11.dsc
 6303f4f3d059ad444f68ec417d3bab70 108840 otherosfs optional qemu_5.0-11.debian.tar.xz
 8eef539b3159c7e93e2026e259e33f1c 9221 otherosfs optional qemu_5.0-11_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEe3O61ovnosKJMUsicBtPaxppPlkFAl8VvBwPHG1qdEB0bHMu
bXNrLnJ1AAoJEHAbT2saaT5ZIbUH/0rLUxW+7kTOPceM68eGZMux+het8QTCM2Eq
6/HfaSXzdf7OdwowrG1z0+NhNJ34JIh6ja4qs1Tqlj1KdSg96xqZlVhWbJN8jnnU
nADX+Vp5qtGGVS8V3UXlfhg+T7+NSTaqChrfnCbQlDNDuskfWVDjmM5UoH2ZE5tX
SgDFpMsA4HXVIrjv390jPA/6YP/kZxFYgzmQt/MvRIMOt4xDrd33jTc6U9gT2TEk
0A4iX6/DvFKQeAdjh4cET6ebqJu5iQwyJak4WDmxQqI2UZCMdWprcvmZWmKkiygi
NGbd4y2ivuMc537O70RftKqL0qfjw/Gwvd/Jox5iQ0sf58MZy/A=
=/jQE
-----END PGP SIGNATURE-----

Message #107 received at 964793-done@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 964793-done@bugs.debian.org

Subject: severity is normal

Date: Wed, 22 Jul 2020 18:23:04 +0300

Control: severity -1 normal


Don't piggy-back the severity levels.
This has nothing to do with "critical" severity.

One particular aspect of this package is broken, that's for sure.
One might argue it is "important", but it doesn't even count at
"serious", as per https://www.debian.org/Bugs/Developer#severities


As of "reopening", again, if you don't understand debian
bug report life time, it's up to you. The bug _is_ fixed
in the version specified. I made sure it is fixed as fast
as possible. If you disagree you can show additional info
that the version given as "fixed" is still not fixed.

/mjt

Message #118 received at 964793-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 964793-close@bugs.debian.org

Subject: Bug#964793: fixed in qemu 1:3.1+dfsg-8+deb10u7

Date: Sat, 25 Jul 2020 16:02:07 +0000

Source: qemu
Source-Version: 1:3.1+dfsg-8+deb10u7
Done: Michael Tokarev <mjt@tls.msk.ru>

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 964793@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 22 Jul 2020 11:21:45 +0300
Source: qemu
Architecture: source
Version: 1:3.1+dfsg-8+deb10u7
Distribution: buster-security
Urgency: medium
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 964793
Changes:
 qemu (1:3.1+dfsg-8+deb10u7) buster-security; urgency=medium
 .
   * acpi-accept-byte-and-word-access-to-core-ACPI-registers.patch
     replace acpi-tmr-allow-2-byte-reads.patch with a more complete patch
     Closes: #964793
   * xhci-fix-valid.max_access_size-to-access-address-registers.patch
     This is another issue revealed after the CVE-2020-13754 fix
   * slirp-tcp_emu-fix-unsafe-snprintf-usages-CVE-2020-8608.patch
     (and a preparational patch, slirp-add-fmt-helpers.patch)
     Closes: CVE-2020-8608
Checksums-Sha1:
 658447a2fcb2a49dcb0d6d4e4517b1a3c9759a3a 6155 qemu_3.1+dfsg-8+deb10u7.dsc
 385ba7f1e80e01bd6b2fe74bacf1728bb73a8d1b 111272 qemu_3.1+dfsg-8+deb10u7.debian.tar.xz
 4159e5bc5ed46a61346d19d3821b3153869a79b5 8663 qemu_3.1+dfsg-8+deb10u7_source.buildinfo
Checksums-Sha256:
 8eca0b49e3dae4d8760a95ecc0eae6edb447620adf043549a078dfe12035e099 6155 qemu_3.1+dfsg-8+deb10u7.dsc
 706fb44f8876f7c9cce576fe9b2dda154522cf4b548f544ef7a77e2680cf975d 111272 qemu_3.1+dfsg-8+deb10u7.debian.tar.xz
 79ecdf5df97719d3ec2d235cb398176f2f3c2b96f11da309208029557f00e57f 8663 qemu_3.1+dfsg-8+deb10u7_source.buildinfo
Files:
 2aea51fd9090c54be269c20220145bea 6155 otherosfs optional qemu_3.1+dfsg-8+deb10u7.dsc
 2d356722f077e7b347b6432451835d72 111272 otherosfs optional qemu_3.1+dfsg-8+deb10u7.debian.tar.xz
 9bc38f2b7bc9abb7816f3499e507f497 8663 otherosfs optional qemu_3.1+dfsg-8+deb10u7_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEe3O61ovnosKJMUsicBtPaxppPlkFAl8X95YPHG1qdEB0bHMu
bXNrLnJ1AAoJEHAbT2saaT5ZpR4H/0i5/9c9uBhxkh6YPg1VQyo4uRnlDf+2DaW4
n1Jd0qxUfgzdsAz9qtLZOePZZYYTkBcVwDx3eUAshWGyZ7M7ri8IaGSSsuY7ciaX
0sC7e0NSgSGCN203kQDVxFRAitDGffA6Z5YcPHcgL1ObKsuU0rFTxm+eOvyA9jbf
l1+x5IUQVA3YUGvuyB/cBDqyXvVscfgLPimnJI2ki7/rwIH/z2lVJ4AOIlU9WEY1
hRcwN4UFEs7lpXC1epi3VZc40vKXoHkjoPQuVJ6M38nd2+HquyvCSbRo7DupTPp2
PL8KMtO+JO5f4aH3l3lh9jxgU5Y49mKTtoOXznV1RE4a6X5/kYI=
=b/dh
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.