On Tue, Jan 28, 2020 at 03:47:02PM +0000, Durrant, Paul wrote: [...] > > > > +memory pages which are shared between the two domains, but this channel > > of > > > +communication is generally established using xenstore (the store > > protocol > > > +itself being an exception to this for obvious chicken-and-egg reasons). > > > + > > > +Typical protocol establishment is based on use of two separate xenstore > > > +*areas*. If we consider PV drivers for the *netif* protocol (i.e. class > > vif) > > > +and assume the guest has domid X, the service domain has domid Y, and > > the vif > > > +has index Z then the frontend area will reside under the parent node: > > > > The term "parent" shows up first time in this document. What does it > > mean in Xen's context? > > >
> I'd hope it's well known that xenstore is hierarchical. I can add a > short explanation if you think it’s needed. I think it is just me -- I have recently been reading Hyper-V's TLFS for far too long, which says "parent partition" everywhere. It would be good if you say "parent xenstore node" or something, but that's not a must for me. Your clarification here is good enough for me. [...] > > > +objects at the receiving end. Others, such as grant table state, could > > > +potentially harmlessly form part of a normal migration stream. > > > + > > > +* * * > > > +[1] PV drivers are deemed to be installed if the HVM parameter > > > +*HVM_PARAM_CALLBACK_IRQ* has been set to a non-zero value. > > > > I think this is just an approximation, but it should be good enough in > > practice. > > > > This is just description of the test as it stands. Personally I don't > like it because I think the callback via should be killed with fire, > but alas it is ABI. However other mechanisms for guests to get events > notifications in HVM guests have existed for a while so I wouldn't > actually view it as a reliable test. E.g. I can happily avoid > registering the callback via in the Windows PV drivers without loss of > functionality. A more sophisticated test would be to actually watch xenstore to see if there is ever any interaction between frontend or backend? That would require more code for sure... On a related note, the hypervisor callback mechanism has infected other type-1 hypervisors (Hyper-V, ACRN) so it is too late to change anything now... Wei. > > Paul > > > > + > > > +[2] See > > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/x > > enbus.h > > > + > > > +[3] See > > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxc- > > migration-stream.pandoc > > > + > > > +[4] See > > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl- > > migration-stream.pandoc > > > + > > > +[5] See > > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt > > > + > > > +[6] `xen-blkback` and `xen-netback` have already been modified in Linux > > to do > > > +this. > > > + > > > +[7] See https://lists.xenproject.org/archives/html/xen-devel/2020- > > 01/msg00632.html > > > + > > > -- > > > 2.20.1 > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
