Bug 1653554

Summary:	Pass more devices via the interface between QEMU and firmware while booting up a guest
Product:	Red Hat Enterprise Linux 8	Reporter:	Min Deng <mdeng>
Component:	qemu-kvm	Assignee:	Virtualization Maintenance <virt-maint>
qemu-kvm sub component:	General	QA Contact:	Min Deng <mdeng>
Status:	CLOSED DEFERRED	Docs Contact:
Severity:	medium
Priority:	medium	CC:	bugproxy, cohuck, dhildenb, hannsj_uhl, knoel, lcapitulino, mdeng, qzhang, rbalakri, smitterl, thuth, tstaudt, virt-maint, virt-qe-z
Version:	8.0	Keywords:	Triaged
Target Milestone:	rc
Target Release:	8.4
Hardware:	s390x
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-20 14:09:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1796871

Description Min Deng 2018-11-27 06:15:15 UTC

Description of problem:
Failed to boot up a guest while there was virtio-net-ccw with bootindex=1

Version-Release number of selected component (if applicable):
qemu-kvm-2.12.0-42.module+el8+2173+537e5cb5.s390x
kernel-4.18.0-44.el8.s390x

How reproducible:
3/3
Steps to Reproduce:
1.boot up a guest manually
  /usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine s390-ccw-virtio -nodefaults -vga none -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -chardev socket,id=qmp_id_catch_monitor,path=/tmp/2,server,nowait -mon chardev=qmp_id_catch_monitor,mode=control -chardev socket,id=serial_id_serial0,path=/tmp/3,server,nowait -device sclpconsole,chardev=serial_id_serial0 -device virtio-scsi-ccw,id=virtio_scsi_ccw0 -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=rhel80-s390x-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1,bootindex=2 -m 2048 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -cpu host -nographic -rtc base=utc,clock=host,driftfix=slew -boot strict=on -no-shutdown -enable-kvm -monitor stdio -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:65:54:cf,bootindex=1

2.connect to console
[root@kernelqe2 mdeng]# nc -U /tmp/3
done
  Using IPv4 address: 192.168.122.8
  Requesting file "" via TFTP from 192.168.122.1
  Receiving data:  0 KBytesICMP ERROR "port unreachable"
Failed to load OS from network


Actual results:
It should continue to boot up from disk (bootindex=2) but it failed to do so.

Expected results:
The guest can boot up from disk since it was unreachable from network(*bootindex=1*).

Additional info:
Changing step 1's command line from bootindex=1 to bootindex=3,guest boots up successfully

Comment 1 Qunfang Zhang 2018-11-28 02:10:07 UTC

Min, 

You added "-boot strict=on" parameter, can you remove it and re-test? 

Thanks,
Qunfang

Comment 2 Min Deng 2018-11-28 05:38:09 UTC

Hi Qunfang,
  The bug still could be reproduced with "-boot strict=on"
Thanks
Min

Comment 3 Min Deng 2018-11-28 08:55:02 UTC

The problem still could be reproduced even without "-boot strict=on",thanks.

Comment 4 Thomas Huth 2018-11-28 13:37:32 UTC

Thanks, I can reproduce the problem, and I also already know why it happens (the solution is unfortunately not very trivial, though).

FWIW, here's a shorter reproducer line (for developers convenience):

/usr/libexec/qemu-kvm -nographic -netdev user,id=n0 \
  -device virtio-net-ccw,netdev=n0,bootindex=1 \
  -drive if=none,id=d0,file=/var/lib/libvirt/images/guest.qcow2 \
  -device virtio-blk,drive=d0,bootindex=2

Comment 5 Thomas Huth 2018-11-28 15:44:42 UTC

It's even not only related to virtio-net - you can always only boot from the very first device with a "bootindex" on s390x. For example, this fails, too:

 qemu-img create -f qcow2 /tmp/empty.qcow2 1G
 /usr/libexec/qemu-kvm -nographic \
   -drive if=none,id=d0,file=/var/lib/libvirt/images/guest.qcow2 \
   -device virtio-blk,drive=d0,bootindex=2 \
   -drive if=none,id=d1,file=/tmp/empty.qcow2 \
   -device virtio-blk,drive=d1,bootindex=1

I've asked someone from IBM, and the problem is that the specification that defines the interface between QEMU and the firmware currently only allows one device to be passed. To properly fix this, the specification needs to be extended first (from IBM), and this will take some time. Thus I'm deferring this BZ to 8.1.

Comment 6 IBM Bug Proxy 2019-08-26 08:40:21 UTC

------- Comment From cborntra.com 2019-08-26 04:36 EDT-------
We do not have a new interface specification yet that would allow for passing more than one boot device.
Needs to be deferred further.

Comment 7 Ademar Reis 2020-02-05 22:51:50 UTC

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 8 IBM Bug Proxy 2020-04-20 14:01:24 UTC

------- Comment From tstaudt.com 2020-04-20 09:53 EDT-------
A development item has been opened in IBM's feature tracking system.
We will open a request once this is ready for inclusion.
Closing as Enhancement.
Thanks, everyone.