qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).