From: Cornelia Huck <cohuck@redhat.com>
To: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Cc: Pierre Morel <pmorel@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
qemu-s390x@nongnu.org, borntraeger@de.ibm.com,
pasic@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/3] vfio: ccw: basic channel path event handling
Date: Tue, 16 Jan 2018 16:53:59 +0100 [thread overview]
Message-ID: <20180116165359.1b829d36.cohuck@redhat.com> (raw)
In-Reply-To: <20180116031627.GE12499@bjsdjshi@linux.vnet.ibm.com>
On Tue, 16 Jan 2018 11:16:27 +0800
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
> * Pierre Morel <pmorel@linux.vnet.ibm.com> [2018-01-15 11:21:47 +0100]:
>
> > 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.
> 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.)
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Cc: Pierre Morel <pmorel@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
qemu-s390x@nongnu.org, borntraeger@de.ibm.com,
pasic@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] vfio: ccw: basic channel path event handling
Date: Tue, 16 Jan 2018 16:53:59 +0100 [thread overview]
Message-ID: <20180116165359.1b829d36.cohuck@redhat.com> (raw)
In-Reply-To: <20180116031627.GE12499@bjsdjshi@linux.vnet.ibm.com>
On Tue, 16 Jan 2018 11:16:27 +0800
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
> * Pierre Morel <pmorel@linux.vnet.ibm.com> [2018-01-15 11:21:47 +0100]:
>
> > 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.
> 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.)
next prev parent reply other threads:[~2018-01-16 15:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 3:04 [RFC PATCH 0/3] vfio: ccw: basic channel path event handling Dong Jia Shi
2018-01-11 3:04 ` [Qemu-devel] " Dong Jia Shi
2018-01-11 3:04 ` [RFC PATCH 1/3] vfio: ccw: introduce schib region Dong Jia Shi
2018-01-11 3:04 ` [Qemu-devel] " Dong Jia Shi
2018-01-11 14:16 ` Cornelia Huck
2018-01-11 14:16 ` [Qemu-devel] " Cornelia Huck
2018-01-15 6:43 ` Dong Jia Shi
2018-01-15 10:24 ` Cornelia Huck
2018-01-15 10:24 ` [Qemu-devel] " Cornelia Huck
2018-01-15 9:50 ` Pierre Morel
2018-01-15 9:50 ` [Qemu-devel] " Pierre Morel
2018-01-15 12:24 ` Cornelia Huck
2018-01-15 12:24 ` [Qemu-devel] " Cornelia Huck
2018-01-16 3:03 ` Dong Jia Shi
2018-01-11 3:04 ` [RFC PATCH 2/3] vfio: ccw: introduce channel path irq Dong Jia Shi
2018-01-11 3:04 ` [Qemu-devel] " Dong Jia Shi
2018-01-11 3:04 ` [RFC PATCH 3/3] vfio: ccw: handle chp event Dong Jia Shi
2018-01-11 3:04 ` [Qemu-devel] " Dong Jia Shi
2018-01-11 10:54 ` [RFC PATCH 0/3] vfio: ccw: basic channel path event handling Cornelia Huck
2018-01-11 10:54 ` [Qemu-devel] " Cornelia Huck
2018-01-15 8:57 ` Dong Jia Shi
2018-01-15 10:21 ` Pierre Morel
2018-01-15 10:21 ` [Qemu-devel] " Pierre Morel
2018-01-16 3:16 ` Dong Jia Shi
2018-01-16 15:53 ` Cornelia Huck [this message]
2018-01-16 15:53 ` Cornelia Huck
2018-01-12 18:10 ` Halil Pasic
2018-01-15 8:59 ` Dong Jia Shi
2018-01-16 15:57 ` Halil Pasic
2018-01-23 6:23 ` Dong Jia Shi
2018-01-25 11:12 ` Cornelia Huck
2018-01-25 12:56 ` Halil Pasic
2018-01-25 12:56 ` Halil Pasic
2018-01-30 3:37 ` Dong Jia Shi
2018-01-30 3:44 ` Dong Jia Shi
2018-01-30 3:44 ` Dong Jia Shi
2018-01-30 5:27 ` [Qemu-devel] " Dong Jia Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180116165359.1b829d36.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.vnet.ibm.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.