All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>, Thomas Huth <thuth@redhat.com>
Cc: qemu-s390x@nongnu.org, Pierre Morel <pmorel@linux.vnet.ibm.com>,
	Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v2 1/3] s390x/ccs: add ccw-testdev emulated device
Date: Thu, 7 Dec 2017 13:38:22 +0100	[thread overview]
Message-ID: <87df13b9-c494-c8b4-49cf-b7ef4640d05a@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171207125901.47be0af1.cohuck@redhat.com>



On 12/07/2017 12:59 PM, Cornelia Huck wrote:
> On Thu, 7 Dec 2017 07:33:19 +0100
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> On 08.11.2017 17:54, Halil Pasic wrote:
> 
>>> +static ccw_cb_t get_ccw_cb(CcwTestDevOpMode op_mode)
>>> +{
>>> +    switch (op_mode) {
>>> +    case OP_MODE_FIB:
>>> +        return ccw_testdev_ccw_cb_mode_fib;
>>> +    case OP_MODE_NOP:
>>> +    default:
>>> +        return ccw_testdev_ccw_cb_mode_nop;  
>>
>> Do we really want to use "nop" for unknown modes? Or should there rather
>> be a ccw_testdev_ccw_cb_mode_error instead, too?
> 
> I like the idea of an error mode.

What would be the benefit of the error mode? The idea is that
the tester in the guest has a certain set of tests implemented
each requiring certain behavior from the device. This behavior
is represented by the mode.

If the device does not support the mode, the set of tests can't
be executed meaningfully. The only option is either ignore them
(and preferably report them as ignored), or fail them (not soo
good in my opinion).

The in guest tester should simply iterate over it test sets
and try to select the mode the test set (or suite in other
terminology) requires. If selecting the mode fails, than
means you are working with an old ccw-testdev.

> 
> Related: Should the device have a mechanism to report the supported
> modes?
> 

I don't see the value. See above. I think the set mode operation
reporting failure is sufficient.

But if you have something in mind, please do tell. I'm open.

>>
>>> +    }
>>> +}
> 
> (...)
> 
>>> +/* TODO This is the out-of-band variant. We may want to get rid of it */  
>>
>> I agree, this should rather go away in the final version.
> 
> I'm not sure that the in-band variant with its magic buffer value is
> superior to this version using a dedicated hypercall.
> 

I have a similar todo comment for the in-band variant. It is basically
up to us to decide which one do we want to keep. It's been a while since
I've looked at this, but AFAIR the out-of-band appears cleaner.

>>
>>> +static int set_mode_diag(const uint64_t *args)
>>> +{
>>> +    uint64_t subch_id = args[0];
>>> +    uint64_t op_mode = args[1];
>>> +    SubchDev *sch;
>>> +    CcwTestDevDevice *dev;
>>> +    int cssid, ssid, schid, m;
>>> +
>>> +    if (ioinst_disassemble_sch_ident(subch_id, &m, &cssid, &ssid, &schid)) {
>>> +        return -EINVAL;
>>> +    }
>>> +    sch = css_find_subch(m, cssid, ssid, schid);
>>> +    if (!sch || !css_subch_visible(sch)) {
>>> +        return -EINVAL;
>>> +    }
>>> +    dev = CCW_TESTDEV(sch->driver_data);
>>> +    if (dev->op_mode_locked) {
>>> +        return op_mode == dev->op_mode ? 0 : -EINVAL;
>>> +    }
>>> +    dev->op_mode = op_mode;
>>> +    sch->ccw_cb = get_ccw_cb(dev->op_mode);
>>> +    return 0;
> 

  reply	other threads:[~2017-12-07 12:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 16:54 [Qemu-devel] [RFC PATCH v2 0/3] tests for CCW IDA Halil Pasic
2017-11-08 16:54 ` [Qemu-devel] [RFC PATCH v2 1/3] s390x/ccs: add ccw-testdev emulated device Halil Pasic
2017-11-22 18:10   ` Cornelia Huck
2017-11-23  8:20   ` Dong Jia Shi
2017-11-23 11:38     ` Halil Pasic
2017-12-07  6:33   ` Thomas Huth
2017-12-07 11:59     ` Cornelia Huck
2017-12-07 12:38       ` Halil Pasic [this message]
2017-12-07 12:57         ` Cornelia Huck
2017-12-07 16:35           ` Halil Pasic
2017-12-07 16:42             ` Cornelia Huck
2017-12-07 12:35   ` Halil Pasic
2017-11-08 16:54 ` [Qemu-devel] [RFC PATCH NOT QEMU v2 2/3] ccw-tester: a tester device for ccw I/O Halil Pasic
2017-11-08 16:54 ` [Qemu-devel] [RFC PATCH NOT QEMU v2 3/3] ccw-tester: add tic test Halil Pasic
2017-11-22 14:19 ` [Qemu-devel] [RFC PATCH v2 0/3] tests for CCW IDA Halil Pasic
2017-12-06 15:43   ` Halil Pasic
2017-12-07  6:38 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2017-12-07  9:01   ` Thomas Huth
2017-12-07 11:53     ` Cornelia Huck
2017-12-11 23:10       ` Halil Pasic

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=87df13b9-c494-c8b4-49cf-b7ef4640d05a@linux.vnet.ibm.com \
    --to=pasic@linux.vnet.ibm.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.