* Cornelia Huck <coh...@redhat.com> [2017-08-01 09:24:20 +0200]: > On Tue, 1 Aug 2017 10:29:10 +0800 > Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: > > > * Cornelia Huck <coh...@redhat.com> [2017-07-31 13:13:02 +0200]: > > > > > On Mon, 31 Jul 2017 11:51:37 +0800 > > > Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: > > > > > When defining a vfio-ccw device, since the real subchannel implicitly > > > > indicates the chps it bound to, we grasp the CHPIDs from sysfs (or, with > > > > my current work, we could even retrieve these information from a new > > > > added MMIO region). In this case, defining some channel path devices > > > > separately does not make sense to me. > > > > > > We might want to pass only a subset of the channel paths to guest. This > > > can only work if we can define individual chp objects. > > Why would we want this? > > For example, if you know that a reconfiguration is coming on soon, you > can just exclude the paths that will go away anyway and the guest will > never know about them. Or for preferred pathing, although that one > fortunately seems to have died out. > > Not very strong reasons to spend time on this, though. Got it.
> > > > > We can add, for example, a "chpids" parameter for the "vfio-ccw" device > > to limit its chpids to a subset that we want it to have? E.g.: > > > > For this mdev: > > MDEV Subchan. PIM PAM POM CHPIDs > > ------------------------------------------------------------------------------ > > 6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920 0.0.013f f0 f0 ff 42434445 > > 00000000 > > > > We could use this command line: > > -device > > vfio-ccw,sysfsdev=$MDEV_CCW013f,devno=0.0.1234,chpids=4245000000000000 > > ^^^^ > > Yes, that would work, should we want that. We can probably do without for now. > Let's deffer this too! -- Dong Jia Shi
