From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1epEmd-0003gs-SZ for qemu-devel@nongnu.org; Fri, 23 Feb 2018 09:57:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1epEma-00021y-NG for qemu-devel@nongnu.org; Fri, 23 Feb 2018 09:57:11 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47514) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1epEma-00021J-Ev for qemu-devel@nongnu.org; Fri, 23 Feb 2018 09:57:08 -0500 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NEscV2001986 for ; Fri, 23 Feb 2018 09:57:07 -0500 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gak44n3gn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Feb 2018 09:57:06 -0500 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 23 Feb 2018 09:57:05 -0500 References: <1519241752-28083-1-git-send-email-walling@linux.vnet.ibm.com> <29048432-906e-5fbe-d927-0814b0c24e4d@de.ibm.com> <25e410d1-3b6a-1178-d46c-87f247eacea9@linux.vnet.ibm.com> <11d66e11-7a56-c5d0-f285-2a532e85fcf8@de.ibm.com> <450ee50a-660b-6ec8-7de4-e5c9ce8fa26a@linux.vnet.ibm.com> <173adc8c-f251-73e4-9cda-f278b2483186@linux.vnet.ibm.com> From: "Collin L. Walling" Date: Fri, 23 Feb 2018 09:57:00 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Message-Id: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v8 00/13] Interactive Boot Menu for DASD and SCSI Guests on s390x List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , Thomas Huth , Viktor Mihajlovski , qemu-s390x@nongnu.org, qemu-devel@nongnu.org Cc: frankja@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, david@redhat.com, cohuck@redhat.com On 02/23/2018 05:11 AM, Christian Borntraeger wrote: > > On 02/23/2018 11:07 AM, Thomas Huth wrote: >> On 22.02.2018 20:40, Collin L. Walling wrote: >>> On 02/22/2018 11:45 AM, Collin L. Walling wrote: >>>> On 02/22/2018 10:44 AM, Christian Borntraeger wrote: >>>>> On 02/22/2018 04:40 PM, Collin L. Walling wrote: >>>>>> On 02/22/2018 07:23 AM, Viktor Mihajlovski wrote: >>>>>>> On 22.02.2018 12:51, Christian Borntraeger wrote: >>>>>>>> Series >>>>>>>> Acked-by: Christian Borntraeger >>>>>> Thanks!!! >>>>>> >>>>>>>> menu on scsi and dasd bootmaps tested successfully. >>>>>>>> >>>>>>>> There is one thing that we might want to fix (can be an addon >>>>>>>> patch since this is a non-customer >>>>>>>> scenario (no libvirt)). >>>>>>>> >>>>>>>> If you start QEMU manually without a bootindex, the -boot menu=3D= on >>>>>>>> is ignored >>>>>>>> if no drive has a bootindex. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> -drive file=3D/dev/dasda,if=3Dnone,id=3Dd1 -device >>>>>>>> virtio-blk-ccw,drive=3Dd1,bootindex=3D1 -boot menu=3Don >>>>>>>> does work >>>>>>>> >>>>>>>> -drive file=3D/dev/dasda -boot menu=3Don >>>>>>>> does not >>>>>>>> >>>>>>>> instead it prints: >>>>>>>> qemu-system-s390x: boot menu is not supported for this device ty= pe. >>>>>>>> >>>>>>>> and the boots up the default entry. >>>>>>>> >>>>>>> That should indeed be a separate patch, as it would move logic >>>>>>> currently >>>>>>> in the BIOS up to QEMU (find the first defined virtio disk and >>>>>>> select it >>>>>>> as boot disk). >>>>>>> In fact it's more complicated than that, because it would have to >>>>>>> properly account for -boot order=3D[acdn] and produce the respect= ive >>>>>>> IPLB. >>>>>>> While it makes sense, I wouldn't rush that in but rather change t= he >>>>>>> error message to indicate that -device bootindex is needed to act= ivate >>>>>>> the menu, at least for the time being. >>>>>>> [...] >>>>>>> >>>>>> I can look into it.=C2=A0 Theoretically, the easier fix should jus= t >>>>>> involve parsing all >>>>>> of the -device commands and looking for a "bootindex=3D1" field. T= he >>>>>> Qemu options >>>>>> code already handles a bulk of this work, so it's just a matter of >>>>>> putting it all >>>>>> together. >>>>>> >>>>>> Shall I whip something up and post what I have as a reply to this >>>>>> email chain? >>>>> In fact, it should already be there. >>>>> >>>>> static bool s390_gen_initial_iplb(S390IPLState *ipl) >>>>> { >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 DeviceState *dev_st; >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 dev_st =3D get_boot_device(0); >>>>> >>>>> --> if this returns 0 we have no bootindex statement anywhere and t= he >>>>> BIOS will IPL the default >>>>> disk. >>>>> >>>>> >>>> Makes sense.=C2=A0 I'm working on making this patch look as clean as >>>> possible. The fact that no boot menu >>>> options present means we fallback to using zipl values for CCW being >>>> tied into the switch statement >>>> is making things a bit tricky. Just have to think the logic through = a >>>> bit.=C2=A0 Will get back to you once >>>> I have something good. >>>> >>> This should do the trick (this can also be squished painlessly into 6= /13 >>> if desired) >> Patch looks fine to me. I can either take it directly like this, or in >> case you have to respin (depends on the problem that Christian reporte= d >> with the Ubuntu guest), I'm also fine if you squash it into an earlier >> patch instead. > FWIW, my problem (a menu happens even without -boot menu=3Don or loadpa= rm) also > happens with other guests (e.g. fedora). > > Is this on guests using DASD?=C2=A0 If so, a boot menu will appear if the= =20 appropriate zipl configuration values are set (even if no -boot menu or loadparm).=C2=A0 Patch 12/13 goe= s=20 into more detail. Is this not wanted behavior? --=20 - Collin L Walling