Re: [Qemu-devel] [PATCH 0/3] Channel Path realted CRW generation

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 27 Jul 2017 03:54:15 +0200
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:

> This series is trying to:
> 1. clear up CRW related code.
> 2. generate the right channel path related CRW at the right time.
> 
> I did this mainly because it's a requirement from my current work, that is I'm
> in preparation of a group of patch for channel path virtualization. I can use
> the inerface that provided by this series later, so as to, for vfio-ccw
> devices, notify the guest with channel path status vary that happens on the
> host side.

Sounds cool.

> 
> During an internal discussion, Halil and Pierre pointed out that for path
> hotplug, generating a CRW seems logical, but how is it covered by the AR is not
> clear - we have problem in understanding some grammar ambiguous paragraphs.
> While certain parts of the AR is not available outside, but I'm still wondering
> if the author ;) could give us some clue... BTW, we know that, in Linux kernel
> we had code that handles un-solicited chp crw, so we tend to believe it's right
> to generate channel path initialized CRW for path hotplug. It's just we can not
> find the reason from the document.

I always found path notifications to be a bit odd. They depend on
various things:
- whether you're running under LPAR or under z/VM
- whether it's a hardware condition (path failure) or something
  triggered by the admin (path vary on/off)
- if it's admin triggered, where it was done (on the SE, by one of
  several mechanisms in CP, via SCLP)

You're bound to get different kinds of notifications: via a CRW with
source channel path, via event information retrievable via CHSC
(indicated by a CRW with source CSS), via a PNO indication, or nothing
at all.

[Reminds me of a case where we got path gone CRWs under LPAR when a
path was deactivated at the SE (which we would notice via PNO anyway),
but no CRW when the path was reactivated - not very useful. When trying
to report this as an issue, we got the answer that we of course need to
use the OS interface to vary off the path beforehand. Silly penguins.]

My recommendation would be to generate a fitting CRW if the wording
allows to do so. I would hope that getting as many useful indications
as possible is most helpful to the OS. (I had added the path-come CRW
handling in Linux back then and afterwards wondered why we did not get
it - I must have interpreted the PoP in the same way as you did.)

I'll double check with how I'd interpret the PoP today.

> 
> Pierre also suggested to add an @erc param for css_generate_chp_crws() in patch3,
> while others have a different opinion. This is for your consideration.
> 
> Best regards!
> 
> Dong Jia Shi (3):
>   s390x/css: use macro for event-information pending error recover code
>   s390x/css: generate solicited crw for rchp completion signaling
>   s390x/css: generate channel path initialized CRW for channel path
>     hotplug
> 
>  hw/s390x/3270-ccw.c       |  3 ++-
>  hw/s390x/css.c            | 66 +++++++++++++++++++++++++++++++++++------------
>  hw/s390x/s390-ccw.c       |  2 +-
>  hw/s390x/virtio-ccw.c     |  3 ++-
>  include/hw/s390x/css.h    | 10 ++++---
>  include/hw/s390x/ioinst.h |  6 +++--
>  6 files changed, 64 insertions(+), 26 deletions(-)
>