RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1653554 - Pass more devices via the interface between QEMU and firmware while booting up a guest
Summary: Pass more devices via the interface between QEMU and firmware while booting u...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: s390x
OS: Linux
medium
medium
Target Milestone: rc
: 8.4
Assignee: Virtualization Maintenance
QA Contact: Min Deng
URL:
Whiteboard:
Depends On:
Blocks: 1796871
TreeView+ depends on / blocked
 
Reported: 2018-11-27 06:15 UTC by Min Deng
Modified: 2020-07-08 08:41 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-20 14:09:31 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 180729 0 None None None 2019-08-20 12:16:14 UTC

Internal Links: 1846975

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.
Note You need to log in before you can comment on or make changes to this bug.