Re: [Xen-devel] Xen 4.2 TODO / Release Plan

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Aug 14, 2012 at 10:05 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> tools, blockers:
    * qemu-traditional has 50% cpu utilization on an idle Windows
system if USB is enabled
       Not 100% clear whether this is Xen or qemu.  George is seeing
if any XenServer patches
      address the issue.

>
>     * 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

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