Re: [Xen-devel] [PATCH v3 1/2] docs/designs: Add a design document for non-cooperative live migration

[Wei Liu <wl@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel