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

[Dong Jia Shi]

* Halil Pasic <address@hidden> [2017-07-31 14:30:32 +0200]:

> 
> 
> 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.
If we choose to go with Conny's idea, then yes, my prototype is totally
in the wrong direction.

> Say, do we  care about a design which could work with live migration
> (@Dong Jia)?
Channel I/O pass through and live migration don't go together.

I'm afraid, we did not considerate live migration yet. If we can
migrate, that would be great! But we are still struggling in finding a
way out the current swamp...

> 
> >> 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.
If we can find a way to satisfy the requirements that Conny mentioned, I
can prepare a design. Sadly, we are not there yet.

> 
> [..]
> >>
> >>>
> >>> 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 
Ha! This is very very clever!

I will give it a try. If everything go well, I will agree with this
happyly. ;)

-- 
Dong Jia Shi