On Fri, 28 Jul 2017 16:29:14 +0200 Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
> On 07/28/2017 02:58 PM, Cornelia Huck wrote: > > On Fri, 28 Jul 2017 14:32:11 +0200 > > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > > > >> On 07/28/2017 12:11 PM, Cornelia Huck wrote: > >>> On Thu, 27 Jul 2017 18:15:07 +0200 > >>> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > > > >>>> So my intention was to ask: What benefits do we expect from these 'real' > >>>> virtual channel paths? > >>> > >>> Path grouping and friends come to mind. This depends on whether you > >>> want to pass-through channel paths to the guest, of course, but you > >>> really need management to deal with things like reserve/release on ECKD > >>> correctly. > >> > >> Pass-through means dedicated in this case (that is the passed trough paths > >> are not used by the host -- correct me if my understanding is wrong). > > > > There's nothing that speaks against path sharing, I think. > > That is a nice to hear. I could not form an opinion on this > myself yet. Theoretically we speak about shared physical resources here, > and in such situations I'm wary of interference. A quick look into > the AR documents was not conclusive. I'm afraid that much of it will be either underdocumented, confusingly worded, or even druidic knowledge. Experimenting a bit might be helpful. > > I'm still trying to figure out this whole channel path handling, > and frankly you are a big help right now. Thanks. > > > Especially as e.g. SetPGID is "first one gets to set it". > > Hm, I don't understand this. (I've found a description of SETPGID > in "IBM 3880 Storage Control Models ... " but could not get your > point based no that.) The first OS that does SetPGID after a reset (or removal of a PGID), sets it. Subsequent SetPGIDs are rejected if the PGID does not match. (See the SensePGID/SetPGID handling in the Linux common I/O layer - this is needed e.g. for running under z/VM.) > >> > >>> Also failover etc. Preferred channel paths are not relevant > >>> on modern hardware anymore, fortunately (AFAIK). > >>> > >> > >> If I understand you correctly it ain't possible to handle these > >> in the host (and let the guest a simple 'non-real' virtual > >> channel path whose reliability depends on what the host does), > >> or? > > > > It is possible. Mapping to a virtual channel path or not is basically a > > design decision (IIRC, z/VM supports both). > > > > Mapping everything to a virtual chpid basically concentrates all > > path-related handling in the hypervisor. This allows for a dumb guest > > OS, but can make errors really hard to debug from the guest side. > > > > IMHO the same is true for virtio for example (the abstraction > hides the backend and the backing: if there is a problem there it's > hard to debug from the guest side). In a way, yes. But it is way more on the virtual side of things :) > > Because of my lack of understanding, this option appeared simpler to > me: clear ownership, and probably also less places where things can > go wrong. My gut feeling is that exposing channel paths is the easier way in the long run. > > > Exposing real channel paths to the guest means that the guest OS needs > > to be able to deal with path-related things, but OTOH it has more > > control. As I don't think we'll ever want to support a guest OS that > > does not also run under LPAR, I'd prefer that way. > > Nod. And this makes a full circle, namely the question of benefit of > having more control. But since we did one full circle I'm much smarter > now than at the beginning. > > Thank you very much for all the background information and for your > patience. Well, I hope I'm not confusing everyone too much :)