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

[Pierre Morel <pmorel@linux.vnet.ibm.com>]

On 15/01/2018 09:57, Dong Jia Shi wrote:
> * Cornelia Huck <cohuck@redhat.com> [2018-01-11 11:54:22 +0100]:
>
>> On Thu, 11 Jan 2018 04:04:18 +0100
>> Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> 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@linux.vnet.ibm.com>
>>> 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