On Tue, 16 Jan 2018 11:16:27 +0800 Dong Jia Shi <bjsdjshi@xxxxxxxxxxxxxxxxxx> wrote: > * Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx> [2018-01-15 11:21:47 +0100]: > > > 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. > 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.) -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
