[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v4] docs/designs: re-work the xenstore migration document...
> -----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. > > > >> > >> [...] > >> > >>> -START_DOMAIN_TRANSACTION <domid>|<transid>| > >>> + 0 1 2 3 octet > >>> ++-------+-------+-------+-------+ > >>> +| conn-id | > >>> ++-------------------------------+ > >>> +| tx-id | > >>> ++---------------+---------------+ > >>> +| path-len | value-len | > >>> ++---------------+---------------+ > >>> +| access | perm-count | > >>> ++---------------+---------------+ > >>> +| perm1 | > >>> ++-------------------------------+ > >>> +... > >>> ++-------------------------------+ > >>> +| permN | > >>> ++---------------+---------------+ > >>> +| path > >>> +... > >>> +| value > >>> +... > >>> +``` > >>> + > >>> + > >>> +| Field | Description | > >>> +|--------------|------------------------------------------------| > >>> +| `conn-id` | If this value is non-zero then this record | > >>> +| | related to a pending transaction | > >> > >> If conn-id is 0, how do you know the owner of the node? > > > > The first permission entry's domid is the owner. > > I think this should be spell out in the specification. > In xenstore.txt, there is a reference to https://wiki.xen.org/wiki/XenBus This explains things reasonably well; I'll reference it here and add some words too. Paul
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |