From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>,
Pierre Morel <pmorel@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream
Date: Wed, 6 Sep 2017 14:40:48 +0200 [thread overview]
Message-ID: <bd30a18f-6d22-e5a7-6e8c-08f628466cc4@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170906141846.0be413fb.cohuck@redhat.com>
On 09/06/2017 02:18 PM, Cornelia Huck wrote:
> On Tue, 5 Sep 2017 13:16:41 +0200
> Halil Pasic <pasic@linux.vnet.ibm.com> wrote:
>
>> This is a preparation for introducing handling for indirect data
>> addressing and modified indirect data addressing (CCW). Here we introduce
>> an interface which should make the addressing scheme transparent for the
>> client code. Here we implement only basic scheme (no IDA or MIDA).
>
> s/basic scheme/the basic scheme/
>
Nod.
>>
>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> ---
>> hw/s390x/css.c | 55 +++++++++++++++++++++++++++++++++++++++++
>> include/hw/s390x/css.h | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 122 insertions(+)
>>
>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
>> index 1880b1a0ff..87d913f81c 100644
>> --- a/hw/s390x/css.c
>> +++ b/hw/s390x/css.c
>> @@ -783,6 +783,61 @@ static CCW1 copy_ccw_from_guest(hwaddr addr, bool fmt1)
>> }
>> return ret;
>> }
>> +/**
>> + * If out of bounds marks the stream broken. If broken returns -EINVAL,
>> + * otherwise the requested length (may be zero)
>
> s/requested length/requested length/
>
Nod.
>> + */
>> +static inline int cds_check_len(CcwDataStream *cds, int len)
>> +{
>> + if (cds->at_byte + len > cds->count) {
>> + cds->flags |= CDS_F_STREAM_BROKEN;
>> + }
>> + return cds->flags & CDS_F_STREAM_BROKEN ? -EINVAL : len;
>> +}
>> +
>> +static int ccw_dstream_rw_noflags(CcwDataStream *cds, void *buff, int len,
>> + CcwDataStreamOp op)
>> +{
>> + int ret;
>> +
>> + ret = cds_check_len(cds, len);
>> + if (ret <= 0) {
>> + return ret;
>> + }
>> + if (op == CDS_OP_A) {
>> + goto incr;
>> + }
>> + ret = address_space_rw(&address_space_memory, cds->cda,
>> + MEMTXATTRS_UNSPECIFIED, buff, len, op);
>> + if (ret != MEMTX_OK) {
>> + cds->flags |= CDS_F_STREAM_BROKEN;
>
> Do we want to distinguish between different reasons for the stream
> being broken? I.e, is there a case where we want to signal different
> errors back to the caller?
>
Hm, after I've done the error handling it seems that basically
everything is to be handled with a program check. The stream
records the place where the problem was encountered, so for debug
we would not have to search for long.
There seems to be no need to distinguish.
>> + return -EINVAL;
>> + }
>> +incr:
>> + cds->at_byte += len;
>> + cds->cda += len;
>> + return 0;
>> +}
>> +
>> +void ccw_dstream_init(CcwDataStream *cds, CCW1 const *ccw, ORB const *orb)
>> +{
>> + /*
>> + * We don't support MIDA (an optional facility) yet and we
>> + * catch this earlier. Just for expressing the precondition.
>> + */
>> + assert(!(orb->ctrl1 & ORB_CTRL1_MASK_MIDAW));
>
> I don't know, this is infrastructure, should it trust its callers? If
> you keep the assert, please make it g_assert().
Why g_assert? I think g_assert comes form a test framework, this is not
test code.
I feel more comfortable having this assert around.
>
>> + cds->flags = (orb->ctrl0 & ORB_CTRL0_MASK_I2K ? CDS_F_I2K : 0) |
>> + (orb->ctrl0 & ORB_CTRL0_MASK_C64 ? CDS_F_C64 : 0) |
>> + (ccw->flags & CCW_FLAG_IDA ? CDS_F_IDA : 0);
>> + cds->count = ccw->count;
>> + cds->cda_orig = ccw->cda;
>> + ccw_dstream_rewind(cds);
>> + if (!(cds->flags & CDS_F_IDA)) {
>> + cds->op_handler = ccw_dstream_rw_noflags;
>> + } else {
>> + assert(false);
>
> Same here.
>
> Or should we make this return an error and have the callers deal with
> that? (I still need to look at the users.)
>
This assert is going away soon (patch 4). I'm not sure doing much more here
is justified.
>> + }
>> +}
>>
>> static int css_interpret_ccw(SubchDev *sch, hwaddr ccw_addr,
>> bool suspend_allowed)
>
next prev parent reply other threads:[~2017-09-06 12:41 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 11:16 [Qemu-devel] [PATCH 0/5] add CCW indirect data access support Halil Pasic
2017-09-05 11:16 ` [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream Halil Pasic
2017-09-06 12:18 ` Cornelia Huck
2017-09-06 12:40 ` Halil Pasic [this message]
2017-09-06 12:51 ` Cornelia Huck
2017-09-11 16:36 ` Halil Pasic
2017-09-13 9:53 ` Cornelia Huck
2017-09-13 11:35 ` Halil Pasic
2017-09-05 11:16 ` [Qemu-devel] [PATCH 2/5] s390x/css: use ccw " Halil Pasic
2017-09-06 12:32 ` Cornelia Huck
2017-09-06 12:42 ` Halil Pasic
2017-09-21 9:33 ` Pierre Morel
2017-09-21 9:36 ` Pierre Morel
2017-09-21 9:45 ` Cornelia Huck
2017-09-05 11:16 ` [Qemu-devel] [PATCH 3/5] virtio-ccw: " Halil Pasic
2017-09-06 12:42 ` Cornelia Huck
2017-09-06 12:49 ` Halil Pasic
2017-09-06 12:54 ` Cornelia Huck
2017-09-11 18:14 ` Halil Pasic
2017-09-13 9:58 ` Cornelia Huck
2017-09-13 11:36 ` Halil Pasic
2017-09-05 11:16 ` [Qemu-devel] [PATCH 4/5] s390x/css: support ccw IDA Halil Pasic
2017-09-06 13:10 ` Cornelia Huck
2017-09-11 18:08 ` Halil Pasic
2017-09-13 9:58 ` Cornelia Huck
2017-09-13 10:31 ` Halil Pasic
2017-09-13 10:50 ` Cornelia Huck
2017-09-05 11:16 ` [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device Halil Pasic
2017-09-06 13:18 ` Cornelia Huck
2017-09-06 14:24 ` Halil Pasic
2017-09-06 15:20 ` Cornelia Huck
2017-09-06 16:16 ` Halil Pasic
2017-09-07 8:06 ` Cornelia Huck
2017-09-07 9:10 ` Janosch Frank
2017-09-07 12:24 ` Cornelia Huck
2017-09-07 7:31 ` Dong Jia Shi
2017-09-07 8:08 ` Cornelia Huck
2017-09-07 10:21 ` Halil Pasic
2017-09-07 10:52 ` Cornelia Huck
2017-09-08 2:01 ` Dong Jia Shi
2017-09-08 10:28 ` Halil Pasic
2017-09-19 6:03 ` Dong Jia Shi
2017-09-21 8:45 ` Dong Jia Shi
2017-09-21 8:54 ` Cornelia Huck
2017-09-26 7:48 ` Dong Jia Shi
2017-09-27 7:11 ` Dong Jia Shi
2017-09-08 10:45 ` [Qemu-devel] [PATCH 0/5] add CCW indirect data access support Halil Pasic
2017-09-08 10:49 ` Cornelia Huck
2017-09-08 11:03 ` Halil Pasic
2017-09-08 11:19 ` Cornelia Huck
2017-09-08 11:43 ` 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=bd30a18f-6d22-e5a7-6e8c-08f628466cc4@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 \
/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).