Re: [PATCH v4] docs/designs: re-work the xenstore migration document...

[Jürgen Groß <jgross@xxxxxxxx>]

On 28.04.20 16:50, Paul Durrant wrote:
> > -----Original Message-----
> > From: Jürgen Groß <jgross@xxxxxxxx>
> > Sent: 28 April 2020 13:56
> > To: paul@xxxxxxx; 'Julien Grall' <julien@xxxxxxx>; 
> > xen-devel@xxxxxxxxxxxxxxxxxxxx
> > Cc: 'Paul Durrant' <pdurrant@xxxxxxxxxx>; 'Andrew Cooper' 
> > <andrew.cooper3@xxxxxxxxxx>; 'George Dunlap'
> > <george.dunlap@xxxxxxxxxx>; 'Ian Jackson' <ian.jackson@xxxxxxxxxxxxx>; 'Jan 
> > Beulich'
> > <jbeulich@xxxxxxxx>; 'Stefano Stabellini' <sstabellini@xxxxxxxxxx>; 'Wei Liu' 
> > <wl@xxxxxxx>
> > Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
> >
> > On 28.04.20 14:46, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Julien Grall <julien@xxxxxxx>
> > > > Sent: 28 April 2020 11:23
> > > > To: Jürgen Groß <jgross@xxxxxxxx>; Paul Durrant <paul@xxxxxxx>; 
> > > > xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > > Cc: Paul Durrant <pdurrant@xxxxxxxxxx>; Andrew Cooper 
> > > > <andrew.cooper3@xxxxxxxxxx>; George Dunlap
> > > > <george.dunlap@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; Jan Beulich
> > <jbeulich@xxxxxxxx>;
> > > > Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>
> > > > Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
> > > >
> > > > Hi Juergen,
> > > >
> > > > On 28/04/2020 11:10, Jürgen Groß wrote:
> > > > > On 28.04.20 11:05, Julien Grall wrote:
> > > > > > > -where tx_id is the non-zero identifier values of an open transaction.
> > > > > > > +| Field     | Description                                       |
> > > > > > > +|-----------|---------------------------------------------------|
> > > > > > > +| `domid`   | The domain-id that owns the shared page           |
> > > > > > > +|           |                                                   |
> > > > > > > +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
> > > > > > > +|           | it has been subject to an SET_TARGET              |
> > > > > > > +|           | operation [2] or DOMID_INVALID [3] otherwise      |
> > > > > > > +|           |                                                   |
> > > > > > > +| `flags`   | Must be zero                                      |
> > > > > > > +|           |                                                   |
> > > > > > > +| `evtchn`  | The port number of the interdomain channel used   |
> > > > > > > +|           | by `domid` to communicate with xenstored          |
> > > > > > > +|           |                                                   |
> > > > > > > +| `mfn`     | The MFN of the shared page for a live update or   |
> > > > > > > +|           | ~0 (i.e. all bits set) otherwise                  |
> > > > > > > -### Protocol Extension
> > > > > > > +Since the ABI guarantees that entry 1 in `domid`'s grant table will
> > > > > > > always
> > > > > > > +contain the GFN of the shared page, so for a live update `mfn` can
> > > > > > > be used to
> > > > > > > +give confidence that `domid` has not been re-cycled during the update.
> > > > > > I am confused, there is no way a XenStored running in an Arm domain
> > > > > > can map the MFN of the shared page. So how is this going to work out?
> > > > > I guess this will be a MFN for PV guests and a guest PFN else.
> > > > If we use Xen terminology (xen/include/xen/mm.h), this would be a GFN.
> > > TBH I'm not sure a GFN would give much confidence about domain recycling as it 
> > > would likely be the
> > same for many domains, I think. We really need a UUID.
> >
> > No, we need a per-host domain value, which is associated with a domain
> > and which is unique during the life-time of the host.
> >
> > E.g. a global counter, which is incremented at each domain creation and
> > stored in struct domain.
> Can we just drop this and fall back on the fact that libxl now prevents domids 
> from being recycled for 60s?
In any case this discussion does not belong to this patch IMO.


Juergen