Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Wed, 2020-01-29 at 12:36 +0000, Paul Durrant wrote:
> This email only tracks big items for xen.git tree. Please reply for items
> you would like to see in 4.14 so that people have an idea what
> is going on and prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release about every 8
>  months.
> The critical dates for Xen 4.14 are as follows:
> 
> ---> We are here
> * Last posting date: May 1st, 2020
> * Hard code freeze: May 22nd, 2020
> * Release: June 26th, 2020
> 
> Note that we don't have a freeze exception scheme anymore. All patches
> that wish to go into 4.14 must be posted initially no later than the
> last posting date and finally no later than the hard code freeze.
> All patches posted after that date will be automatically queued into next
> release.
> 
> RCs will be arranged immediately after freeze.
> 
> There is also a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
> 
> Some of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
> 
> There is a version number for patch series associated to each feature.
> Can each owner send an update giving the latest version number if the
> series has been re-posted? Also, can the owners of any completed items
> please respond so that the item can be moved into the 'Completed' section.
> 
> = Projects =
> 
> == Hypervisor == 
> 
> *  Live-Updating Xen
>   -  David Woodhouse

Latest RFC patchset posted is [RFC v2] at
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg01764.html

The tree at 
https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/heads/lu-master
as moved on a little since then, and I'll post [RFC v3] shortly.

So far this is mostly just the basic handover of a stream of migration
data from one Xen to the next, and allowing the new Xen to vmap and
process it early enough, and reserve the pages which already contain
domain data during its "boot".

In our development tree, we have a PV Dom0 surviving the transition.
We're working on turning those hacks into something we can show in
public.

I have updated the wiki page at 
https://wiki.xenproject.org/wiki/Live-Updating_Xen
which includes a reference to the handover protocol documentation.

This also depends on the hypervisor side of non-cooperative live
migration, mentioned below. But as well as that, parts of the memory
management are going to intersect with the secret hiding work that you
*didn't* call out in this email AFAICT.


> *  Non-Cooperative Live Migration
>   -  Paul Durrant
> 
> === x86 === 
> 
> *  Intel Processor Trace virtualization enabling (v1)
>   -  Luwei Kang
> 
> *  Linux stub domains (RFC v2)
>   -  Marek Marczykowski-Górecki
> 
> *  Fixes to #DB injection
>   -  Andrew Cooper
> 
> *  CPUID/MSR Xen/toolstack improvements
>   -  Andrew Cooper
> 
> *  Improvements to domain_crash()
>   -  Andrew Cooper
> 
> *  EIBRS
>   -  Andrew Cooper
> 
> *  Xen ioreq server (v3)
>   -  Roger Pau Monne
> 
> === ARM === 
> 
> == Completed == 
> 
> 
> Paul Durrant

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel