[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. Juergen
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |