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

[Halil Pasic]

On 07/31/2017 01:13 PM, Cornelia Huck wrote:
> On Mon, 31 Jul 2017 11:51:37 +0800
> Dong Jia Shi <address@hidden> wrote:
> 
>> * Cornelia Huck <address@hidden> [2017-07-27 13:59:10 +0200]:
>>
>>> On Thu, 27 Jul 2017 03:54:18 +0200
>>> Dong Jia Shi <address@hidden> wrote:
[..]
>>
>> After thinking quite a while, if we do want to add a real device object
>> for a channel path, the most intractable problem (but not the only one)
>> for me is to find a good way to map the real path with the virtual one.

Yeah, channel path virtualisation... IMHO our current solution is not
not really solving the problem. Say, do we  care about a design which
could work with live migration (@Dong Jia)?

>> How would we retrieve the information from the real one? We'd need the
>> host kernel to provide totally new interfaces for channel path
>> information synchronization and notification machenism. I don't think in
>> this case sysfs is the choice. Ioctls, vfio MMIO regions and eventfd
>> could be a better choice. I think, this is like we are trying to
>> passthru a channel path. So we'd need to have a new vfio device physical
>> driver (e.g. vfio-chp) to handle this...
> 
> And that would run into the problem of (1) the chp objects not using a
> bus on Linux, and (2) implying dedicating the chpids, which we likely
> do not want.
> 

AFAIU this is about "real-virtual" vs "virutal-virtual". I would really like
to see some design here (@Dong Jia). I'm not sure any more where do we want to 
go.

[..]
>>
>>>
>>> tl;dr: I don't think we want chp crws until after we have a good chp
>>> model.  
>> I have to agree.
> 
> I'm wondering whether we should just defer this to later. We can live
> with no chp crw being created (except for rchp), as due to the crw
> generation being unreliable the guest OS has to handle path changes
> without crws anyway.
> 
> We just need to make sure that pno and friends are appropriately
> reported to the guest.
> 

+1