Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug

[Cornelia Huck]

On Fri, 28 Jul 2017 14:32:11 +0200
Halil Pasic <address@hidden> wrote:

> On 07/28/2017 12:11 PM, Cornelia Huck wrote:
> > On Thu, 27 Jul 2017 18:15:07 +0200
> > Halil Pasic <address@hidden> wrote:

> >> So my intention was to ask: What benefits do we expect from these 'real'
> >> virtual channel paths?   
> > 
> > Path grouping and friends come to mind. This depends on whether you
> > want to pass-through channel paths to the guest, of course, but you
> > really need management to deal with things like reserve/release on ECKD
> > correctly.  
> 
> Pass-through means dedicated in this case (that is the passed trough paths
> are not used by the host -- correct me if my understanding is wrong).

There's nothing that speaks against path sharing, I think. Especially
as e.g. SetPGID is "first one gets to set it".

> 
> This whole multipath/grouping stuff is currently a gray spot for me. I've
> tired to revisit the corresponding parts of the AR, but there ain't much
> on it in the documents I have.
> 
> Is the protocol for managing multipath equipment (device, maybe also CU)
> dependent? The PoP (and the IO AR) talk about set-multipath-mode type
> of command and similar (disband, resign) but how this type of command
> looks like -- no idea. From the kernel code one can learn more details,
> but that's just an implementation.

Path selection and friends should all be in the base I/O documentation
(maybe something in the common I/O device commands, as well.) Path
grouping is device-specific.

> 
> Can you recommend me a publication where the controls you talk about
> are specified?

For SetPGID etc., I'd recommend the DASD documentation (the one
specifying the channel commands supported). Don't have the publication
number handy, sorry.

> 
> > Also failover etc. Preferred channel paths are not relevant
> > on modern hardware anymore, fortunately (AFAIK).
> >  
> 
> If I understand you correctly it ain't possible to handle these
> in the host (and let the guest a simple 'non-real' virtual
> channel path whose reliability depends on what the host does),
> or?

It is possible. Mapping to a virtual channel path or not is basically a
design decision (IIRC, z/VM supports both).

Mapping everything to a virtual chpid basically concentrates all
path-related handling in the hypervisor. This allows for a dumb guest
OS, but can make errors really hard to debug from the guest side.

Exposing real channel paths to the guest means that the guest OS needs
to be able to deal with path-related things, but OTOH it has more
control. As I don't think we'll ever want to support a guest OS that
does not also run under LPAR, I'd prefer that way.

> 
> Thanks for the explanations!

You're welcome!