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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20180116165359.1b829d36.cohuck@redhat.com>
Date:   Tue, 16 Jan 2018 16:53:59 +0100
From:   Cornelia Huck <cohuck@...hat.com>
To:     Dong Jia Shi <bjsdjshi@...ux.vnet.ibm.com>
Cc:     Pierre Morel <pmorel@...ux.vnet.ibm.com>,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, qemu-devel@...gnu.org, qemu-s390x@...gnu.org,
        borntraeger@...ibm.com, pasic@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/3] vfio: ccw: basic channel path event handling

On Tue, 16 Jan 2018 11:16:27 +0800
Dong Jia Shi <bjsdjshi@...ux.vnet.ibm.com> wrote:

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

I consider the ability to grab an updated schib useful not only for
path-related stuff, but for getting the whole content of it updated;
this makes the interface interesting even in the future.

And I think everybody wants more path virtualization, but that's not
going to be easy.

> 
> > 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? :^)
> 

Heh :)

Actually, thinking about migration has been on my to-do list for a
while; unfortunately, it's not alone there. (I fully expect the items
on my to-do list to hold tea parties so they don't get bored.)