On 17.07.2019 01:51, Andrew Cooper wrote: > On 15/07/2019 19:57, Foerster, Leonard wrote: >> * dom0less: bootstrap domains without the involvement of dom0 >> -> this might come in handy to at least setup and continue dom0 >> on target xen >> -> If we have this this might also enable us to de-serialize >> the state for >> other guest-domains in xen and not have to wait for >> dom0 to do this > > Reconstruction of dom0 is something which Xen will definitely need to > do. With the memory still in place, its just a fairly small of register > state which needs restoring. > > That said, reconstruction of the typerefs will be an issue. Walking > over a fully populated L4 tree can (in theory) take minutes, and its not > safe to just start executing without reconstruction. > > Depending on how bad it is in practice, one option might be to do a > demand validate of %rip and %rsp, along with a hybrid shadow mode which > turns faults into typerefs, which would allow the gross cost of > revalidation to be amortised while the vcpus were executing. We would > definitely want some kind of logic to aggressively typeref outstanding > pagetables so the shadow mode could be turned off.
Neither walking the page table trees nor and on-demand re-creation can possibly work, as pointed out during (partly informal) discussion: At the very least the allocated and pinned states of pages can only be transferred. Hence we seem to have come to agreement that struct page_info instances have to be transformed (in place if possible, i.e. when the sizes match, otherwise by copying). >> -> We might have to go and re-inject certain interrupts > > What hardware are you targeting here? IvyBridge and later has a posted > interrupt descriptor which can accumulate pending interrupts (at least > manually), and newer versions (Broadwell?) can accumulate interrupts > directly from hardware. For HVM/PVH perhaps that's good enough. What about PV though? >> A key cornerstone for Live-update is guest transparent live migration >> -> This means we are using a well defined ABI for saving/restoring >> domain state >> -> We do only rely on domain state and no internal xen state > > Absolutely. One issue I discussed with David a while ago is that even > across an upgrade of Xen, the format of the EPT/NPT pagetables might > change, at least in terms of the layout of software bits. (Especially > for EPT where we slowly lose software bits to new hardware features we > wish to use.) Right, and therefore a similar transformation like for struct page_info may be unavoidable here too. Re-using large data structures (or arrays thereof) may also turn out useful in terms of latency until the new Xen actually becomes ready to resume. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
