Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt

[John Snow]

On 10/23/19 1:28 PM, Fernando Casas Schössow wrote:
> Hi John,
> 
> Thanks for looking into this.
> I can quickly repro the problem with qemu 4.0 binary with debugging
> symbols enabled as I have it available already.
> Doing the same with qemu 4.1 or development head may be too much hassle
> but if it's really the only way I can give it try.
> 
> Would it worth it to try with 4.0 first and get the strack trace or it
> will not help and the only way to go is with 4.1 (or dev)?
> 
> Thanks,
> 
> Fernando
> 

If 4.0 is what you have access to, having the stack trace for that is
better than not, but confirming it happens on the latest release would
be nice.

Can you share your workflow for virsh that reproduces the failure?

--js

> On mié, oct 23, 2019 at 5:34 PM, John Snow <address@hidden> wrote:
>> 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
> 
>