| Message ID | 20170908152446.14606-2-pasic@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] s390x/css: drop data-check in interpretation | expand |
On Fri, 8 Sep 2017 17:24:43 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > The architecture says that channel-data check is indicating that > an uncorrected storage (memory) error has been detected in regard > to the data residing in main storage (memory) that is currently > used for an I/O operation. The described detection is done using > the CBC technology. > > The ccw interpretation code is however generating a channel-data check > effectively when the (device specific) ccw_cb returns -EFAULT. In case > of virtio-ccw devices this happens when mapping memory fails, or when a > NULL pointer is encountered. So this behavior is not architecture > conform. > > Furthermore the best fit for these situations (null pointer, mapping a > piece of guest memory fails) from architectural perspective the condition > described as the channel subsystem refers to a location that is not > available, which when encountered shall result in a channel-program > check. > > To fix this, all we have to do is to get rid of the switch case matching > -EFAULT: the default is generating a channel-program check. > > --- > > Was posted as stand alone patch. See: > http://patchwork.ozlabs.org/patch/810995/ > > If you are going to, *please review there*. Countered. *Please review here* (It makes it easier for me.) > > Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Your s-o-b should go before the triple-dash delimiter. I can fix that up. > --- > hw/s390x/css.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/hw/s390x/css.c b/hw/s390x/css.c > index 901dc6a0f3..09f6ba0310 100644 > --- a/hw/s390x/css.c > +++ b/hw/s390x/css.c > @@ -980,15 +980,6 @@ static void sch_handle_start_func_virtual(SubchDev *sch) > SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; > s->cpa = sch->channel_prog + 8; > break; > - case -EFAULT: > - /* memory problem, generate channel data check */ > - s->ctrl &= ~SCSW_ACTL_START_PEND; > - s->cstat = SCSW_CSTAT_DATA_CHECK; > - s->ctrl &= ~SCSW_CTRL_MASK_STCTL; > - s->ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY | > - SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; > - s->cpa = sch->channel_prog + 8; > - break; > case -EBUSY: > /* subchannel busy, generate deferred cc 1 */ > s->flags &= ~SCSW_FLAGS_MASK_CC; Looks reasonable. Queued.
On 09/11/2017 11:33 AM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 17:24:43 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> The architecture says that channel-data check is indicating that >> an uncorrected storage (memory) error has been detected in regard >> to the data residing in main storage (memory) that is currently >> used for an I/O operation. The described detection is done using >> the CBC technology. >> >> The ccw interpretation code is however generating a channel-data check >> effectively when the (device specific) ccw_cb returns -EFAULT. In case >> of virtio-ccw devices this happens when mapping memory fails, or when a >> NULL pointer is encountered. So this behavior is not architecture >> conform. >> >> Furthermore the best fit for these situations (null pointer, mapping a >> piece of guest memory fails) from architectural perspective the condition >> described as the channel subsystem refers to a location that is not >> available, which when encountered shall result in a channel-program >> check. >> >> To fix this, all we have to do is to get rid of the switch case matching >> -EFAULT: the default is generating a channel-program check. >> >> --- >> >> Was posted as stand alone patch. See: >> http://patchwork.ozlabs.org/patch/810995/ >> >> If you are going to, *please review there*. > > Countered. *Please review here* > > (It makes it easier for me.) > >> >> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > > Your s-o-b should go before the triple-dash delimiter. I can fix that > up. Thanks! Btw. the original (there) was correct in this respect. > >> --- >> hw/s390x/css.c | 9 --------- >> 1 file changed, 9 deletions(-) >> >> diff --git a/hw/s390x/css.c b/hw/s390x/css.c >> index 901dc6a0f3..09f6ba0310 100644 >> --- a/hw/s390x/css.c >> +++ b/hw/s390x/css.c >> @@ -980,15 +980,6 @@ static void sch_handle_start_func_virtual(SubchDev *sch) >> SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; >> s->cpa = sch->channel_prog + 8; >> break; >> - case -EFAULT: >> - /* memory problem, generate channel data check */ >> - s->ctrl &= ~SCSW_ACTL_START_PEND; >> - s->cstat = SCSW_CSTAT_DATA_CHECK; >> - s->ctrl &= ~SCSW_CTRL_MASK_STCTL; >> - s->ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY | >> - SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; >> - s->cpa = sch->channel_prog + 8; >> - break; >> case -EBUSY: >> /* subchannel busy, generate deferred cc 1 */ >> s->flags &= ~SCSW_FLAGS_MASK_CC; > > Looks reasonable. Queued. > Thanks! Halil
diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 901dc6a0f3..09f6ba0310 100644 --- a/hw/s390x/css.c +++ b/hw/s390x/css.c @@ -980,15 +980,6 @@ static void sch_handle_start_func_virtual(SubchDev *sch) SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; s->cpa = sch->channel_prog + 8; break; - case -EFAULT: - /* memory problem, generate channel data check */ - s->ctrl &= ~SCSW_ACTL_START_PEND; - s->cstat = SCSW_CSTAT_DATA_CHECK; - s->ctrl &= ~SCSW_CTRL_MASK_STCTL; - s->ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY | - SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND; - s->cpa = sch->channel_prog + 8; - break; case -EBUSY: /* subchannel busy, generate deferred cc 1 */ s->flags &= ~SCSW_FLAGS_MASK_CC;
The architecture says that channel-data check is indicating that an uncorrected storage (memory) error has been detected in regard to the data residing in main storage (memory) that is currently used for an I/O operation. The described detection is done using the CBC technology. The ccw interpretation code is however generating a channel-data check effectively when the (device specific) ccw_cb returns -EFAULT. In case of virtio-ccw devices this happens when mapping memory fails, or when a NULL pointer is encountered. So this behavior is not architecture conform. Furthermore the best fit for these situations (null pointer, mapping a piece of guest memory fails) from architectural perspective the condition described as the channel subsystem refers to a location that is not available, which when encountered shall result in a channel-program check. To fix this, all we have to do is to get rid of the switch case matching -EFAULT: the default is generating a channel-program check. --- Was posted as stand alone patch. See: http://patchwork.ozlabs.org/patch/810995/ If you are going to, *please review there*. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> --- hw/s390x/css.c | 9 --------- 1 file changed, 9 deletions(-)