[lkml]   [2018]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] vfio: ccw: basic channel path event handling
On 15/01/2018 09:57, Dong Jia Shi wrote:
> * Cornelia Huck <> [2018-01-11 11:54:22 +0100]:
>> On Thu, 11 Jan 2018 04:04:18 +0100
>> Dong Jia Shi <> 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: <>
>>> URL:
>>> 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:
> - PNOM
> - CHPIDs
> - 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

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.



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

 \ /
  Last update: 2018-01-15 11:23    [W:0.199 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site