From: John Snow <jsnow@redhat.com>
To: "Fernando Casas Schössow" <casasfernando@outlook.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Cc: Peter Krempa <pkrempa@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Subject: Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Date: Wed, 23 Oct 2019 11:34:45 -0400 [thread overview]
Message-ID: <dbb363cf-bc3a-6de5-a62a-1467208d0017@redhat.com> (raw)
In-Reply-To: <VI1PR03MB481484C08A04458ACA64F7A0A46C0@VI1PR03MB4814.eurprd03.prod.outlook.com>
On 10/18/19 5:41 PM, Fernando Casas Schössow wrote:
> Hi,
>
Hi! Thanks for the report.
> Today while working with two different Windows Server 2012 R2 guests I
> found that when I try to attach an ISO file to a SCSI CD-ROM device
> through libvirt (virsh or virt-manager) while the guest is running,
> qemu crashes and the following message is logged:
>
> Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx
> (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c:
> virtio_scsi_ctx_check: 246)
>
> I can repro this at will. All I have to do is to try to attach an ISO
> file to the SCSI CDROM while the guest is running.
> The SCSI controller model is virtio-scsi with iothread enabled.
> Please find below all the details about my setup that I considered
> relevant but I missed something please don't hesitate to let me know:
>
Looks like we got aio_context management wrong with iothread for the
media change events somewhere. Should be easy enough to fix if we figure
out where the bad assumption is.
> Host arch: x86_64
> Distro: Alpine Linux 3.10.2
> qemu version: 4.0
Do you have the ability to try 4.1, or the latest development head with
debugging symbols enabled?
> Linux kernel version: 4.19.67
> libvirt: 5.5.0
> Emulated SCSI controller: virtio-scsi (with iothread enabled)
> Guest firmware: OVMF-EFI
> Guest OS: Window Server 2012 R2
> Guest virtio drivers version: 171 (current stable)
>
> qemu command line:
>
> /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S
> -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes
> -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu
> IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
> -drive
> file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on
> -drive
> file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1
> -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1
> -object iothread,id=iothread1 -uuid
> f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults
> -chardev socket,id=charmonitor,fd=33,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc
> base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay
> -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global
> PIIX4_PM.disable_s4=1 -boot strict=on -device
> qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device
> virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5
> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
> file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads
> -device
> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device
> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
> -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3
> -chardev
> socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait
> -device isa-serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> -chardev socket,id=charchannel1,fd=45,server,nowait -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
> -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0
> -device
> virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0
> -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice
> port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on
> -device
> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
> -chardev spicevmc,id=charredir0,name=usbredir -device
> usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev
> spicevmc,id=charredir1,name=usbredir -device
> usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox
> on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
> -msg timestamp=on
>
> I can provide a core dump of the process if needed for debugging and
> the guest XML as well.
>
A backtrace is probably a great starting point (from gdb: `thread apply
all bt`.) I don't know exactly what codepath is being exercised when you
"attach an ISO file" through libvirt's interface.
If you don't mind the hassle, trying on the 4.1 (or a development build
would be even more luxurious) and giving a stacktrace would be nice.
> Thanks.
>
> Fernando
>
>
Thanks!
--js
next prev parent reply other threads:[~2019-10-23 15:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 21:41 qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt Fernando Casas Schössow
2019-10-23 15:34 ` John Snow [this message]
2019-10-23 17:28 ` Fernando Casas Schössow
2019-10-23 17:33 ` John Snow
2019-10-23 17:57 ` Fernando Casas Schössow
[not found] ` <VI1PR03MB48142C8AFFD94EDD5339F6D6A46B0@VI1PR03MB4814.eurprd03.prod.outlook.c om>
2019-10-24 21:07 ` Fernando Casas Schössow
[not found] ` <VI1PR03MB48142C8AFFD94EDD5339F6D6A46B0@VI1PR03MB4814.eurprd03.prod.outlook.c>
[not found] ` <VI1PR03MB48149BEC6D7D02A08EECDE9BA46A0@VI1PR03MB4814.eurprd03.prod.outlook.c om>
2019-10-24 21:25 ` Fernando Casas Schössow
2019-10-25 10:07 ` Kevin Wolf
2019-10-25 10:28 ` Fernando Casas Schössow
[not found] ` <VI1PR03MB48140DB2BA084EAEBD980302A4650@VI1PR03MB4814.eurprd03.prod.outlook.c om>
2019-10-25 10:45 ` Fernando Casas Schössow
-- strict thread matches above, loose matches on Subject: below --
2019-10-18 21:26 Fernando Casas Schössow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dbb363cf-bc3a-6de5-a62a-1467208d0017@redhat.com \
--to=jsnow@redhat.com \
--cc=casasfernando@outlook.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).