[Qemu-devel] [Bug 1777969] Re: Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

2018-07-11 Thread Matthew Stapleton
It looks like this crash is fixed with git commit:
bed9bcfa3275a9cfee82846a9f521c4858a9739a

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

Title:
  Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

Status in QEMU:
  New

Bug description:
  I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode
  with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0.
  The crash doesn't occur if I compile with --enable-trace-
  backends=simple or if I use virtio-scsi.  The original crash was
  noticed on Gentoo with hardened gcc 6.4.0 and an Intel CPU, the test
  system to reproduce the crash is on Gentoo with non-hardened gcc 5.4.0
  and an Intel CPU.

  OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz

  Here is the commands I have run on qemu 2.12.0 to reproduce the issue 
although it also crashes with accel=kvm removed:
  ./configure --target-list="x86_64-softmmu"
  make
  qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive 
if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on 
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive 
file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device 
ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk

  Valgrind says "Bad permissions for mapped region at address
  0x4C022FE0" for the crash.

  Here is a backtrace from gdb:
  Program received signal SIGSEGV, Segmentation fault.
  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  (gdb) bt
  #0  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  #1  0x7f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0
  #2  0x55a3ff9def8f in qemu_aio_get 
(aiocb_info=aiocb_info@entry=0x55a4001b39a0 , 
bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 , 
opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33
  #3  0x55a3ff9e0249 in thread_pool_submit_aio 
(pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 , 
arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 , 
  opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251
  #4  0x55a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, 
func=func@entry=0x55a3ff956620 , arg=arg@entry=0x55a400bd30b0) at 
util/thread-pool.c:289
  #5  0x55a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=, offset=362702848, qiov=, bytes=2048, type=1) at 
block/file-posix.c:1536
  #6  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #7  0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
  at block/io.c:1228
  #8  0x55a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324
  #9  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #10 0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=512, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
  at block/io.c:1228
  #11 0x55a3ff960434 in bdrv_co_preadv (child=0x55a400be92c0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=flags@entry=0) at block/io.c:1324
  #12 0x55a3ff94f4ce in blk_co_preadv (blk=0x55a400bf8ba0, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at 
block/block-backend.c:1158
  #13 0x55a3ff94f5ac in blk_read_entry (opaque=0x7f42961e3670) at 
block/block-backend.c:1206
  #14 0x55a3ff94e000 in blk_prw (blk=0x55a400bf8ba0, offset=362702848, 
buf=, bytes=bytes@entry=2048, 
co_entry=co_entry@entry=0x55a3ff94f590 , flags=flags@entry=0) 
at block/block-backend.c:1243
  #15 0x55a3ff94f076 in blk_pread (blk=, offset=, buf=, count=count@entry=2048) at block/block-backend.c:1409
  #16 0x55a3ff7d8b93 in cd_read_sector_sync (s=0x55a401a0faa0) at 
hw/ide/atapi.c:124
  #17 ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:269
  #18 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
  #19 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
  #20 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
  #21 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
  #22 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
  #23 0x55a3ff7d870c 

[Qemu-devel] [Bug 1777969] Re: Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

2018-06-22 Thread Matthew Stapleton
With git bisect, I have narrowed down the crash to git commit:
e4baa9f00b9ddf47ac2811eb58a3931434b848f7 .  For git commit:
0e168d35519ee04590a439cd6631f53cd954edd0 , I don't get the crash.

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

Title:
  Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

Status in QEMU:
  New

Bug description:
  I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode
  with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0.
  The crash doesn't occur if I compile with --enable-trace-
  backends=simple or if I use virtio-scsi.  The original crash was
  noticed on Gentoo with hardened gcc 6.4.0 and an Intel CPU, the test
  system to reproduce the crash is on Gentoo with non-hardened gcc 5.4.0
  and an Intel CPU.

  OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz

  Here is the commands I have run on qemu 2.12.0 to reproduce the issue 
although it also crashes with accel=kvm removed:
  ./configure --target-list="x86_64-softmmu"
  make
  qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive 
if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on 
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive 
file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device 
ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk

  Valgrind says "Bad permissions for mapped region at address
  0x4C022FE0" for the crash.

  Here is a backtrace from gdb:
  Program received signal SIGSEGV, Segmentation fault.
  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  (gdb) bt
  #0  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  #1  0x7f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0
  #2  0x55a3ff9def8f in qemu_aio_get 
(aiocb_info=aiocb_info@entry=0x55a4001b39a0 , 
bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 , 
opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33
  #3  0x55a3ff9e0249 in thread_pool_submit_aio 
(pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 , 
arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 , 
  opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251
  #4  0x55a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, 
func=func@entry=0x55a3ff956620 , arg=arg@entry=0x55a400bd30b0) at 
util/thread-pool.c:289
  #5  0x55a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=, offset=362702848, qiov=, bytes=2048, type=1) at 
block/file-posix.c:1536
  #6  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #7  0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
  at block/io.c:1228
  #8  0x55a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324
  #9  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #10 0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=512, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
  at block/io.c:1228
  #11 0x55a3ff960434 in bdrv_co_preadv (child=0x55a400be92c0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=flags@entry=0) at block/io.c:1324
  #12 0x55a3ff94f4ce in blk_co_preadv (blk=0x55a400bf8ba0, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at 
block/block-backend.c:1158
  #13 0x55a3ff94f5ac in blk_read_entry (opaque=0x7f42961e3670) at 
block/block-backend.c:1206
  #14 0x55a3ff94e000 in blk_prw (blk=0x55a400bf8ba0, offset=362702848, 
buf=, bytes=bytes@entry=2048, 
co_entry=co_entry@entry=0x55a3ff94f590 , flags=flags@entry=0) 
at block/block-backend.c:1243
  #15 0x55a3ff94f076 in blk_pread (blk=, offset=, buf=, count=count@entry=2048) at block/block-backend.c:1409
  #16 0x55a3ff7d8b93 in cd_read_sector_sync (s=0x55a401a0faa0) at 
hw/ide/atapi.c:124
  #17 ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:269
  #18 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
  #19 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
  #20 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
  #21 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
  #22 

[Qemu-devel] [Bug 1777969] Re: Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

2018-06-21 Thread Matthew Stapleton
Okay thanks.  I forgot to mention I am running the Gentoo version of
kernel 4.14 series.  Here is the configure settings for gcc from my
desktop system used to reproduce the crash that originally occurred on
the hardened server, and even though the desktop system isn't using
hardened profile, this gcc is using some hardened features:

/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info --with-gxx-
include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-
gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.4.0-r3 p1.3, pie-0.6.5' --enable-libstdcxx-
time --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-
libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-
libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv
--enable-lto --without-isl --enable-libsanitizer

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

Title:
  Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

Status in QEMU:
  New

Bug description:
  I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode
  with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0.
  The crash doesn't occur if I compile with --enable-trace-
  backends=simple or if I use virtio-scsi.  The original crash was
  noticed on Gentoo with hardened gcc 6.4.0 and an Intel CPU, the test
  system to reproduce the crash is on Gentoo with non-hardened gcc 5.4.0
  and an Intel CPU.

  OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz

  Here is the commands I have run on qemu 2.12.0 to reproduce the issue 
although it also crashes with accel=kvm removed:
  ./configure --target-list="x86_64-softmmu"
  make
  qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive 
if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on 
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive 
file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device 
ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk

  Valgrind says "Bad permissions for mapped region at address
  0x4C022FE0" for the crash.

  Here is a backtrace from gdb:
  Program received signal SIGSEGV, Segmentation fault.
  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  (gdb) bt
  #0  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
  #1  0x7f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0
  #2  0x55a3ff9def8f in qemu_aio_get 
(aiocb_info=aiocb_info@entry=0x55a4001b39a0 , 
bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 , 
opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33
  #3  0x55a3ff9e0249 in thread_pool_submit_aio 
(pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 , 
arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 , 
  opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251
  #4  0x55a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, 
func=func@entry=0x55a3ff956620 , arg=arg@entry=0x55a400bd30b0) at 
util/thread-pool.c:289
  #5  0x55a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=, offset=362702848, qiov=, bytes=2048, type=1) at 
block/file-posix.c:1536
  #6  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #7  0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
  at block/io.c:1228
  #8  0x55a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324
  #9  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
  #10 0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 

[Qemu-devel] [Bug 1777969] [NEW] Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0

2018-06-20 Thread Matthew Stapleton
Public bug reported:

I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode
with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0.
The crash doesn't occur if I compile with --enable-trace-backends=simple
or if I use virtio-scsi.  The original crash was noticed on Gentoo with
hardened gcc 6.4.0 and an Intel CPU, the test system to reproduce the
crash is on Gentoo with non-hardened gcc 5.4.0 and an Intel CPU.

OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz

Here is the commands I have run on qemu 2.12.0 to reproduce the issue although 
it also crashes with accel=kvm removed:
./configure --target-list="x86_64-softmmu"
make
qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive 
if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on 
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive 
file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device 
ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk

Valgrind says "Bad permissions for mapped region at address 0x4C022FE0"
for the crash.

Here is a backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
(gdb) bt
#0  0x7f42dcbc5833 in malloc () from /lib64/libc.so.6
#1  0x7f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0
#2  0x55a3ff9def8f in qemu_aio_get 
(aiocb_info=aiocb_info@entry=0x55a4001b39a0 , 
bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 , 
opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33
#3  0x55a3ff9e0249 in thread_pool_submit_aio 
(pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 , 
arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 , 
opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251
#4  0x55a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, 
func=func@entry=0x55a3ff956620 , arg=arg@entry=0x55a400bd30b0) at 
util/thread-pool.c:289
#5  0x55a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=, offset=362702848, qiov=, bytes=2048, type=1) at 
block/file-posix.c:1536
#6  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
#7  0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
at block/io.c:1228
#8  0x55a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, 
offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324
#9  0x55a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924
#10 0x55a3ff960154 in bdrv_aligned_preadv 
(child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=512, 
qiov=qiov@entry=0x7f42961e3650, flags=0)
at block/io.c:1228
#11 0x55a3ff960434 in bdrv_co_preadv (child=0x55a400be92c0, 
offset=offset@entry=362702848, bytes=bytes@entry=2048, 
qiov=qiov@entry=0x7f42961e3650, flags=flags@entry=0) at block/io.c:1324
#12 0x55a3ff94f4ce in blk_co_preadv (blk=0x55a400bf8ba0, offset=362702848, 
bytes=2048, qiov=0x7f42961e3650, flags=0) at block/block-backend.c:1158
#13 0x55a3ff94f5ac in blk_read_entry (opaque=0x7f42961e3670) at 
block/block-backend.c:1206
#14 0x55a3ff94e000 in blk_prw (blk=0x55a400bf8ba0, offset=362702848, 
buf=, bytes=bytes@entry=2048, 
co_entry=co_entry@entry=0x55a3ff94f590 , flags=flags@entry=0) 
at block/block-backend.c:1243
#15 0x55a3ff94f076 in blk_pread (blk=, offset=, buf=, count=count@entry=2048) at block/block-backend.c:1409
#16 0x55a3ff7d8b93 in cd_read_sector_sync (s=0x55a401a0faa0) at 
hw/ide/atapi.c:124
#17 ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:269
#18 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
#19 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
#20 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
#21 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
#22 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
#23 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
#24 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
#25 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 
hw/ide/atapi.c:285
#26 0x55a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at 
hw/ide/ahci.c:1325
#27 0x55a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at 

[Qemu-devel] [Bug 1331334] Re: driftfix=none and migration on Win7 guest causes time to go 10 times as fast

2018-02-15 Thread Matthew Stapleton
I am unable to reproduce this with qemu 2.11.0

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

Title:
  driftfix=none and migration on Win7 guest causes time to go 10 times
  as fast

Status in QEMU:
  Incomplete

Bug description:
  With -rtc base=localtime,clock=host,driftfix=none on a Win7 guest,
  stopping it with migration and then starting it again about 1 hour
  later makes the guest time go 10 times as fast as real time until
  Windows is rebooted.  I have tried qith qemu-2.0.0 and the problem
  still exists there.

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



[Qemu-devel] [Bug 1679126] [NEW] null pointer access on migration resume of systemrescuecd boot menu with qxl-vga

2017-04-03 Thread Matthew Stapleton
Public bug reported:

With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when resuming
from a migration state file created from a VM suspended while showing
the System Rescue CD 4.9.2 boot menu and using the QXL VGA device, I get
a null point access in pixman_image_get_data called from
qemu_spice_create_update (spice-display.c:215).  When I added
assert(ssd->mirror != NULL) above that line, assert failed.  I don't get
the crash when using standard VGA or cirrus-vga.  I am using gcc-4.9.3
on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel: 4.9.15-gentoo.

Here is the valgrind trace from the git version:
==2634== Thread 1:
==2634== Invalid read of size 4
==3516==at 0x65F3050: pixman_image_get_data (in 
/usr/lib64/libpixman-1.so.0.34.0)
==3516==by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215)
==3516==by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502)
==3516==by 0x58CF77: display_refresh (qxl.c:1948)
==3516==by 0x6E8084: do_safe_dpy_refresh (console.c:1591)
==3516==by 0x6E80D5: dpy_refresh (console.c:1604)
==3516==by 0x6E4508: gui_update (console.c:201)
==3516==by 0x81898E: timerlist_run_timers (qemu-timer.c:536)
==3516==by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547)
==3516==by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662)
==3516==by 0x81952A: main_loop_wait (main-loop.c:514)
==3516==by 0x4ADD29: main_loop (vl.c:1898)

Minimal steps to reproduce:

Compile (debug compile flags are just so valgrind works, the crash occurs with 
non-debug compile flags as well):
CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure 
--target-list=i386-softmmu,x86_64-softmmu
./configure
make

Start VM and leave it on the System Rescue CD graphical boot menu:
x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive 
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device 
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor 
unix:monitor.sock,server,nowait -display gtk

Suspend VM and save state:
socat - unix:monitor.sock
  stop
  migrate "exec:cat > vm.state"
  quit

Attempt to resume VM (but this crashes):
x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive 
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device 
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor 
unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state"

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  null pointer access on migration resume of systemrescuecd boot menu
  with qxl-vga

Status in QEMU:
  New

Bug description:
  With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when
  resuming from a migration state file created from a VM suspended while
  showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA
  device, I get a null point access in pixman_image_get_data called from
  qemu_spice_create_update (spice-display.c:215).  When I added
  assert(ssd->mirror != NULL) above that line, assert failed.  I don't
  get the crash when using standard VGA or cirrus-vga.  I am using
  gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel:
  4.9.15-gentoo.

  Here is the valgrind trace from the git version:
  ==2634== Thread 1:
  ==2634== Invalid read of size 4
  ==3516==at 0x65F3050: pixman_image_get_data (in 
/usr/lib64/libpixman-1.so.0.34.0)
  ==3516==by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215)
  ==3516==by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502)
  ==3516==by 0x58CF77: display_refresh (qxl.c:1948)
  ==3516==by 0x6E8084: do_safe_dpy_refresh (console.c:1591)
  ==3516==by 0x6E80D5: dpy_refresh (console.c:1604)
  ==3516==by 0x6E4508: gui_update (console.c:201)
  ==3516==by 0x81898E: timerlist_run_timers (qemu-timer.c:536)
  ==3516==by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547)
  ==3516==by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662)
  ==3516==by 0x81952A: main_loop_wait (main-loop.c:514)
  ==3516==by 0x4ADD29: main_loop (vl.c:1898)

  Minimal steps to reproduce:

  Compile (debug compile flags are just so valgrind works, the crash occurs 
with non-debug compile flags as well):
  CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure 
--target-list=i386-softmmu,x86_64-softmmu
  ./configure
  make

  Start VM and leave it on the System Rescue CD graphical boot menu:
  x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive 
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device 
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor 
unix:monitor.sock,server,nowait -display gtk

  Suspend VM and save state:
  socat - unix:monitor.sock
stop
migrate "exec:cat > vm.state"
quit

  Attempt to resume VM (but this crashes):
  

[Qemu-devel] [Bug 1331334] [NEW] driftfix=none and migration on Win7 guest causes time to go 10 times as fast

2014-06-18 Thread Matthew Stapleton
Public bug reported:

With -rtc base=localtime,clock=host,driftfix=none on a Win7 guest,
stopping it with migration and then starting it again about 1 hour later
makes the guest time go 10 times as fast as real time until Windows is
rebooted.  I have tried qith qemu-2.0.0 and the problem still exists
there.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  driftfix=none and migration on Win7 guest causes time to go 10 times
  as fast

Status in QEMU:
  New

Bug description:
  With -rtc base=localtime,clock=host,driftfix=none on a Win7 guest,
  stopping it with migration and then starting it again about 1 hour
  later makes the guest time go 10 times as fast as real time until
  Windows is rebooted.  I have tried qith qemu-2.0.0 and the problem
  still exists there.

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