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

[Pierre Morel]

On 15/01/2018 09:57, Dong Jia Shi wrote:
> * Cornelia Huck <cohuck@xxxxxxxxxx> [2018-01-11 11:54:22 +0100]:
>
> > On Thu, 11 Jan 2018 04:04:18 +0100
> > Dong Jia Shi <bjsdjshi@xxxxxxxxxxxxxxxxxx> 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: <20170727015418.85407-1-bjsdjshi@xxxxxxxxxxxxxxxxxx>
> > > 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.
Having more accurate information on hardware without virtualization is a
big handicap for migration and hotplug.

Regards,

Pierre


--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany