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

[Halil Pasic]

On 07/28/2017 02:58 PM, Cornelia Huck wrote:
> 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.

That is a nice to hear. I could not form an opinion on this
myself yet. Theoretically we speak about shared physical resources here,
and in such situations I'm wary of interference. A quick look into
the AR documents was not conclusive.

I'm still trying to figure out this whole channel path handling,
and frankly you are a big help right now.

> Especially as e.g. SetPGID is "first one gets to set it".

Hm, I don't understand this. (I've found a description of SETPGID
in "IBM 3880 Storage Control Models ... " but could not get your
point based no that.)

> 
>>
>> 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.
> 

Nod.

>>
>> 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.
> 

Thanks, based on your input I've found the pub mentioned above.

>>
>>> 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.
> 

IMHO the same is true for virtio for example (the abstraction
hides the backend and the backing: if there is a problem there it's
hard to debug from the guest side).

Because of my lack of understanding, this option appeared simpler to
me: clear ownership, and probably also less places where things can
go wrong.

> 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.

Nod. And this makes a full circle, namely the question of benefit of
having more control. But since we did one full circle I'm much smarter
now than at the beginning.

Thank you very much for all the background information and for your
patience.

Regards,
Halil