From: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] s390x/css: fix bits must be zero check for TIC
Date: Thu, 27 Jul 2017 08:41:26 +0800 [thread overview]
Message-ID: <20170727004126.GS7483@bjsdjshi@linux.vnet.ibm.com> (raw)
In-Reply-To: <cf37838e-d92e-408e-2cc1-662ad5c89b29@linux.vnet.ibm.com>
* Halil Pasic <pasic@linux.vnet.ibm.com> [2017-07-26 13:38:33 +0200]:
>
>
> On 07/26/2017 05:01 AM, Dong Jia Shi wrote:
> > Hello Halil,
> >
> > * Halil Pasic <pasic@linux.vnet.ibm.com> [2017-07-26 00:44:42 +0200]:
> >
> >> According to the PoP bit positions 0-3 and 8-32 of the format-1 CCW must
> >> contain zeros. Bits 0-3 are already covered by cmd_code validity
> >> checking, and bit 32 is covered by the CCW address checking.
> >>
> >> Bits 8-31 correspond to CCW1.flags and CCW1.count. Currently we only
> >> check for the absence of certain flags. Let's fix this.
> >>
> >> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
> >> ---
> >> hw/s390x/css.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> >> index d17e21b7af..1f04ce4a1b 100644
> >> --- a/hw/s390x/css.c
> >> +++ b/hw/s390x/css.c
> >> @@ -884,7 +884,8 @@ static int css_interpret_ccw(SubchDev *sch, hwaddr ccw_addr,
> >> ret = -EINVAL;
> >> break;
> >> }
> >> - if (ccw.flags & (CCW_FLAG_CC | CCW_FLAG_DC)) {
> >> + if (ccw.flags || ccw.count) {
> >> + /* We have already sanitized these if fmt 0. */
> > ccw0 does not have the same restrictions as ccw1. We don't sanitize
> > these for ccw0.
> >
>
> Yes you have misunderstood. For fmt 1 these bits have to be zero
> otherwise a program-check condition is to be recognized. Thus we don't
> sanitize for fmt 1.
>
> For fmt 0 these bits are ignored. We sanitize them in
> for some time now by setting them to zero when making a CCW1
> out of an CCW0. If we would recognize a program-check for
> fmt 0 that would be wrong.
Yup, I know this.
>
> The comment tells us why this code is good for CCW0 too,
> and why can we omit sch->ccw_fmt_1 from the conditon.
Ahh, I see the point now. Yes, I misunderstood.
Another point is we have translated ccw0 to ccw1. So here we only focus
on handling ccw1 stuff. Mentioning ccw0 seems a little redundant.
Anyway, I will leave this to you to decide. No problem from my side now.
>
> Regards,
> Halil
>
> > (This comment is still here. Did I misunderstand things? :)
> >
> >> ret = -EINVAL;
> >> break;
> >> }
> >> --
> >> 2.11.2
> >>
> >
> > With the comment removed:
> > Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> >
>
>
--
Dong Jia Shi
next prev parent reply other threads:[~2017-07-27 0:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 22:44 [Qemu-devel] [PATCH 0/2] ccw interpretation AR compliance improvements Halil Pasic
2017-07-25 22:44 ` [Qemu-devel] [PATCH 1/2] s390x/css: check ccw address validity Halil Pasic
2017-07-26 3:31 ` Dong Jia Shi
2017-07-26 12:05 ` Halil Pasic
2017-07-26 16:45 ` Halil Pasic
2017-07-27 1:03 ` Dong Jia Shi
2017-07-25 22:44 ` [Qemu-devel] [PATCH 2/2] s390x/css: fix bits must be zero check for TIC Halil Pasic
2017-07-26 3:01 ` Dong Jia Shi
2017-07-26 11:38 ` Halil Pasic
2017-07-27 0:41 ` Dong Jia Shi [this message]
2017-07-27 8:01 ` Cornelia Huck
2017-07-27 11:18 ` Halil Pasic
2017-07-27 13:40 ` Halil Pasic
2017-07-27 13:45 ` Cornelia Huck
2017-07-27 8:32 ` Cornelia Huck
2017-07-27 8:43 ` Dong Jia Shi
2017-07-27 8:26 ` [Qemu-devel] [PATCH 0/2] ccw interpretation AR compliance improvements Cornelia Huck
2017-07-27 11:34 ` Halil Pasic
2017-07-27 13:18 ` Halil Pasic
2017-07-27 13:40 ` Cornelia Huck
2017-07-27 13:52 ` Halil Pasic
2017-07-27 14:24 ` Cornelia Huck
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=20170727004126.GS7483@bjsdjshi@linux.vnet.ibm.com \
--to=bjsdjshi@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=pasic@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 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.