[Xen-devel] Xen 4.2 TODO / Release Plan

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Including xen-users@ as well as xen-devel@ now that we are into the rc
phases. Also see below for a reminder about the Xen Test Day which is
happening right now.

Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html

The time line is as follows:

19 March        -- TODO list locked down
2 April         -- Feature Freeze
30 July         -- First release candidate
Weekly          -- RCN+1 until release          << WE ARE HERE

We released RC2 last week (tag "4.2.0-rc2" in xen-unstable.hg). The
first Xen test day is happening right now on the #xentest channel on
Freenode. The aim of this first test day is to test the xl
toolstack. See for more details http://wiki.xen.org/wiki/Xen_Test_Days

The updated TODO list follows.

hypervisor, blockers:

    * None

tools, blockers:

    * libxl stable API -- we would like 4.2 to define a stable API
      which downstream's can start to rely on not changing. Aspects of
      this are:

        * None known

    * xl compatibility with xm:

        * No known issues

    * [CHECK] More formally deprecate xm/xend. Manpage patches already
      in tree. Needs release noting and communication around -rc1 to
      remind people to test xl.

    * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works.

    * Bump library SONAMES as necessary.
      <20502.39440.969619.824976@xxxxxxxxxxxxxxxxxxxxxxxx>

hypervisor, nice to have:

    * vMCE save/restore changes, to simplify migration 4.2->4.3 with
      new vMCE in 4.3. (Jinsong Liu, Jan Beulich, DONE for 4.2)

    * [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
      stop halfway through searching, causing a guest to crash even if
      there was zeroed memory available.  This is NOT a regression
      from 4.1, and is a very rare case, so probably shouldn't be a
      blocker.  (In fact, I'd be open to the idea that it should wait
      until after the release to get more testing.)
            (George Dunlap)

    * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)

    * address PoD problems with early host side accesses to guest
      address space (draft patch for 4.0.x exists, needs to be ported
      over to -unstable, which I'll expect to get to today, Jan
      Beulich)

    * fix high change rate to CMOS RTC periodic interrupt causing
      guest wall clock time to lag (possible fix outlined, needs to be
      put in patch form and thoroughly reviewed/tested for unwanted
      side effects, Jan Beulich)

tools, nice to have:

    * xl compatibility with xm:

        * None

    * xl.cfg(5) documentation patch for qemu-upstream
      videoram/videomem support:
      http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
      qemu-upstream doesn't support specifying videomem size for the
      HVM guest cirrus/stdvga.  (but this works with
      qemu-xen-traditional). (Pasi KÃrkkÃinen)

    * [BUG] long stop during the guest boot process with qcow image,
      reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821

    * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
      http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

    * Load blktap driver from xencommons initscript if available, thread at:
      <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
      properly in 4.3. (Patch posted, discussion, plan to take simple
      xencommons patch for 4.2 and revist for 4.3. Ping sent)

    * [BUG] xl allows same PCI device to be assigned to multiple
      guests. http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
      (<E4558C0C96688748837EB1B05BEED75A0FD5574A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>)

    * [BUG(?)] If domain 0 attempts to access a guests' memory before
      it is finished being built, and it is being built in PoD mode,
      this may cause the guest to crash.  Again, this is NOT a
      regression from 4.1.  Furthermore, it's only been reported
      (AIUI) by a customer of SuSE; so it shoudn't be a blocker.
      (Again, I'd be open to the idea that it should wait until after
      the release to get more testing.)
          (George Dunlap / Jan Beulich)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel