Re: [qemu-s390x] [RFC PATCH 0/3] vfio: ccw: basic channel path event handling

[Dong Jia Shi]

* Pierre Morel <address@hidden> [2018-01-15 11:21:47 +0100]:

> On 15/01/2018 09:57, Dong Jia Shi wrote:
> >* Cornelia Huck <address@hidden> [2018-01-11 11:54:22 +0100]:
> >
> >>On Thu, 11 Jan 2018 04:04:18 +0100
> >>Dong Jia Shi <address@hidden> wrote:
> >>
> >>>Hi Folks,
> >>>
> >>>Background
> >>>==========
> >>>
> >>>Some days ago, we had a discussion on the topic of channel path 
> >>>virtualization.
> >>>Ref:
> >>>Subject: [PATCH 0/3] Channel Path realted CRW generation
> >>>Message-Id: <address@hidden>
> >>>URL: https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg08414.html
> >>>
> >>>Indeed that thread is not short and discussed many aspects in a
> >>>non-concentrated manner. The parts those are most valuable to me are:
> >>>1. a re-modelling for channel path is surely the best offer, but is not
> >>>    possible to have in the near future.
> >>>2. to enhance the path related functionalities, using PNO and PNOM might
> >>>    be something we can do for now. This may be something that I could 
> >>> improve
> >>>    without model related arguments.
> >>>
> >>>So here I have this series targeting to add basic channel path event 
> >>>handling
> >>>for vfio-ccw -- no touch of the channel path modelling in both the kernel 
> >>>and
> >>>the QEMU side, but find a way to sync path status change to guest lazily 
> >>>using
> >>>SCSW_FLAGS_MASK_PNO and pmcw->pnom.  In short, I want to enhance path 
> >>>related
> >>>stuff (to be more specific: sync up path status to the guest) on a best 
> >>>effort
> >>>basis, which means in a way that won't get us invloed to do channel path
> >>>re-modelling.
> >>The guest should also get the updated PIM/PAM/POM, shouldn't it?
> >>
> >Yes. The following values will be updated for the guest:
> >PMCW:
> >   - PIM/PAM/POM
> >   - PNOM
> >   - CHPIDs
> >SCSW
> >   - PNOM bit
> >
> >See vfio_ccw_update_schib in patch #4 of the QEMU series.
> >
> >>>What benifit can we get from this? The administrator of a virtual machine 
> >>>can
> >>>get uptodate (in some extent) status of the current using channel paths, so
> >>>he/she can monitor paths status and get path problem noticed timely (see 
> >>>the
> >>>example below).
> >>>
> >>>I think we can start a new round discussion based on this series. So 
> >>>reviewers
> >>>can give their comments based on some code, and then we can decide if this 
> >>>is
> >>>we want or not.
> >>>
> >>>As flagged with RFC, the intention of this series is to show what I have 
> >>>for
> >>>now, and what could the code look like in general. Thus I can get some 
> >>>early
> >>>feedbacks. I would expect to see opinions on:
> >>>- is the target (mentioned above) of this series welcomed or not.
> >>It certainly makes sense to have a way to get an updated schib.
> >>
> >:)
> 
> I think so too, if the guest's administrator wants to be able to do
> something.
> 
> But I would like to see something about path virtualization.
Me too... As pointed in the discussion thread (URL listed above), this
is something that really hard to have in the near future. The question
is do we want some enhancements like this without channel path
re-modelling, or we want nothing until we have the re-modelling firstly?

> Having more accurate information on hardware without virtualization is a
> big handicap for migration and hotplug.
> 
vfio-ccw does not support migration. What could be the handicap for
that? :^)

-- 
Dong Jia Shi