From: Eric Farman <farman@linux.ibm.com>
To: jjherne@linux.ibm.com, qemu-devel@nongnu.org,
qemu-s390x@nongnu.org, cohuck@redhat.com, pasic@linux.ibm.com,
alifm@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v3 16/16] s390-bios: dasd-ipl: Use control unit type to customize error data
Date: Thu, 7 Mar 2019 13:15:02 -0500 [thread overview]
Message-ID: <a7a8cf41-149a-4a59-5046-a05d2331f5c2@linux.ibm.com> (raw)
In-Reply-To: <2e4625fb-6682-a632-3bf9-0f47aa61ba67@linux.ibm.com>
On 03/07/2019 09:38 AM, Jason J. Herne wrote:
> On 3/4/19 12:02 PM, Eric Farman wrote:
>>
>>
>> On 03/01/2019 01:59 PM, Jason J. Herne wrote:
>>> Propagate control unit type from main through the dasd ipl call chain.
>>> The control unit type can be used to determine if we are attempting to
>>> boot from a real dasd device. If something goes wrong we'll want to
>>> print
>>> detailed dasd sense data (for diagnostic use) but only if we're
>>> attempting
>>> to boot from a real dasd device.
>>>
>>> Note: We also query and print the dasd sense data if we fail while
>>> attempting to determine the control unit type. In this case, we don't
>>> know
>>> if we're dealing with a real dasd device yet, but if we are, then the
>>> sense
>>> data may be useful for figuring out what went wrong. Since determining
>>> the control unit type is the very first thing we do with any real
>>> dasd device,
>>> this is our most likely point of failure.
>>>
>>> Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com>
>>> ---
>>> pc-bios/s390-ccw/cio.c | 16 ++++++++++------
>>> pc-bios/s390-ccw/cio.h | 6 ++++--
>>> pc-bios/s390-ccw/dasd-ipl.c | 25 +++++++++++++------------
>>> pc-bios/s390-ccw/dasd-ipl.h | 2 +-
>>> pc-bios/s390-ccw/main.c | 2 +-
>>> pc-bios/s390-ccw/virtio.c | 2 +-
>>> 6 files changed, 30 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/pc-bios/s390-ccw/cio.c b/pc-bios/s390-ccw/cio.c
>>> index c528bbf..593fb33 100644
>>> --- a/pc-bios/s390-ccw/cio.c
>>> +++ b/pc-bios/s390-ccw/cio.c
>>> @@ -54,14 +54,15 @@ uint16_t cu_type(SubChannelId schid)
>>> sense_id_ccw.count = sizeof(sense_data);
>>> sense_id_ccw.flags |= CCW_FLAG_SLI;
>>> - if (do_cio(schid, ptr2u32(&sense_id_ccw), CCW_FMT1)) {
>>> + if (do_cio(schid, CU_TYPE_UNKNOWN, ptr2u32(&sense_id_ccw),
>>> CCW_FMT1)) {
>>> panic("Failed to run SenseID CCw\n");
>>> }
>>> return sense_data.cu_type;
>>> }
>>> -void basic_sense(SubChannelId schid, void *sense_data, uint16_t
>>> data_size)
>>> +void basic_sense(SubChannelId schid, uint16_t cutype, void *sense_data,
>>> + uint16_t data_size)
>>> {
>>> Ccw1 senseCcw;
>>> @@ -69,7 +70,7 @@ void basic_sense(SubChannelId schid, void
>>> *sense_data, uint16_t data_size)
>>> senseCcw.cda = ptr2u32(sense_data);
>>> senseCcw.count = data_size;
>>> - if (do_cio(schid, ptr2u32(&senseCcw), CCW_FMT1)) {
>>> + if (do_cio(schid, cutype, ptr2u32(&senseCcw), CCW_FMT1)) {
>>> panic("Failed to run Basic Sense CCW\n");
>>> }
>>> }
>>> @@ -364,7 +365,7 @@ static int __do_cio(SubChannelId schid, uint32_t
>>> ccw_addr, int fmt, Irb *irb)
>>> *
>>> * Returns non-zero on error.
>>> */
>>> -int do_cio(SubChannelId schid, uint32_t ccw_addr, int fmt)
>>> +int do_cio(SubChannelId schid, uint16_t cutype, uint32_t ccw_addr,
>>> int fmt)
>>> {
>>> Irb irb = {};
>>> SenseDataEckdDasd sd;
>>
>> Missed this one? :)
>>
> This field is used in two places. 1) For an ECKD Dasd only path. 2) In
> an error recovery path where we need to issue a basic sense to clear
> status but we never examine the data. So I guess having the struct named
> "SenseDataEckdDasd" and using it in a potentially generic path *might*
> be slightly misleading, it seems superior to allocating a new chunk of
> memory we'll never use. I assume this is the issue you are hinting at?
>
Nope... I guess my git hunk got cut off... I get a compile error for
the basic_sense() call with only three parameters in this function. (if
(unit_check(&irb)) ...
diff --git a/pc-bios/s390-ccw/cio.c b/pc-bios/s390-ccw/cio.c
index 593fb33fbd..0bf551d313 100644
--- a/pc-bios/s390-ccw/cio.c
+++ b/pc-bios/s390-ccw/cio.c
@@ -393,7 +393,7 @@ int do_cio(SubChannelId schid, uint16_t cutype,
uint32_t ccw_addr, int fmt)
*/
if ((unit_check(&irb) || iface_ctrl_check(&irb)) && retries <=
2) {
if (unit_check(&irb)) {
- basic_sense(schid, &sd, sizeof(sd));
+ basic_sense(schid, cutype, &sd, sizeof(sd));
}
retries++;
continue;
next prev parent reply other threads:[~2019-03-07 18:15 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 18:59 [Qemu-devel] [PATCH v3 00/16] s390: vfio-ccw dasd ipl support Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 01/16] s390 vfio-ccw: Add bootindex property and IPLB data Jason J. Herne
2019-03-04 13:40 ` Cornelia Huck
2019-03-06 14:55 ` Jason J. Herne
2019-03-06 15:27 ` Cornelia Huck
2019-03-06 16:28 ` Jason J. Herne
2019-03-06 17:31 ` Cornelia Huck
2019-03-04 16:09 ` Farhan Ali
2019-03-06 15:16 ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 02/16] s390-bios: decouple cio setup from virtio Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 03/16] s390-bios: decouple common boot logic " Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 04/16] s390-bios: Extend find_dev() for non-virtio devices Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 05/16] s390-bios: Factor finding boot device out of virtio code path Jason J. Herne
2019-03-04 17:07 ` Cornelia Huck
2019-03-04 19:26 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-05 8:38 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 06/16] s390-bios: Clean up cio.h Jason J. Herne
2019-03-04 17:23 ` Cornelia Huck
2019-03-05 5:51 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-06 18:42 ` Jason J. Herne
2019-03-07 8:08 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 07/16] s390-bios: Decouple channel i/o logic from virtio Jason J. Herne
2019-03-04 17:28 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 08/16] s390-bios: Map low core memory Jason J. Herne
2019-03-04 17:46 ` Cornelia Huck
2019-03-05 6:27 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-06 19:28 ` Jason J. Herne
2019-03-07 8:11 ` Cornelia Huck
2019-03-06 19:42 ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 09/16] s390-bios: ptr2u32 and u32toptr Jason J. Herne
2019-03-05 7:22 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-07 14:11 ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 10/16] s390-bios: Support for running format-0/1 channel programs Jason J. Herne
2019-03-04 18:25 ` Cornelia Huck
2019-03-07 19:25 ` Jason J. Herne
2019-03-08 9:19 ` Cornelia Huck
2019-03-05 7:32 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 11/16] s390-bios: cio error handling Jason J. Herne
2019-03-04 18:35 ` Cornelia Huck
2019-03-07 19:31 ` Jason J. Herne
2019-03-08 9:21 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 12/16] s390-bios: Refactor virtio to run channel programs via cio Jason J. Herne
2019-03-05 12:30 ` Cornelia Huck
2019-03-07 15:09 ` Jason J. Herne
2019-03-07 15:37 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 13/16] s390-bios: Use control unit type to determine boot method Jason J. Herne
2019-03-05 12:27 ` Cornelia Huck
2019-03-07 16:27 ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 14/16] s390-bios: Add channel command codes/structs needed for dasd-ipl Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 15/16] s390-bios: Support booting from real dasd device Jason J. Herne
2019-03-05 13:03 ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 16/16] s390-bios: dasd-ipl: Use control unit type to customize error data Jason J. Herne
2019-03-04 17:02 ` [Qemu-devel] [qemu-s390x] " Eric Farman
2019-03-07 14:38 ` Jason J. Herne
2019-03-07 18:15 ` Eric Farman [this message]
2019-03-07 18:26 ` Jason J. Herne
2019-03-04 17:51 ` [Qemu-devel] " Cornelia Huck
2019-03-01 21:26 ` [Qemu-devel] [PATCH v3 00/16] s390: vfio-ccw dasd ipl support no-reply
2019-03-01 21:30 ` no-reply
2019-03-01 21:35 ` no-reply
2019-03-01 21:38 ` no-reply
2019-03-01 21:45 ` no-reply
2019-03-01 21:49 ` no-reply
2019-03-04 16:24 ` Cornelia Huck
2019-03-04 17:53 ` Christian Borntraeger
2019-03-04 17:28 ` no-reply
2019-03-04 17:51 ` no-reply
2019-03-05 5:55 ` no-reply
2019-03-05 7:30 ` no-reply
2019-03-05 8:42 ` no-reply
2019-03-05 13:08 ` no-reply
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=a7a8cf41-149a-4a59-5046-a05d2331f5c2@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=jjherne@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@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).