Xen 4.2 TODO / Release Plan

Xen 4.2 TODO / Release Plan

[Ian Campbell]

A bit late this week, due to my being on vacation. I'm on vacation
next two Monday as well so it will be late then too.

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
                                                << WE ARE HERE
When It's Ready -- First release candidate
Weekly          -- RCN+1 until release

The updated TODO list follows. Per the release plan a strong case will
now have to be made as to why new items should be added to the list,
especially as a blocker, rather than deferred to 4.3.

If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)

Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.

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:

        * LIBXL_NIC_TYPE enum names are confusing.

        * Interfaces which may need to be async:

            * libxl_domain_suspend. Move xc_domain_save/restore into a
              separate process (IanJ, patches posted).

            * libxl_device_{disk,nic,vkb,add,pci}_add (and
              remove). (Roger, patches posted for disk & nic, vkb
              trivial, not looked at pci yet)

        * use libxl_cpumap for b_info.avail_cpus instead of an int,
          this"allows setting more than 31 CPUS (Yang Z Zhang, patches
          posted)

        * use an enum for VGA interface type (e.g. Cirrus,
          StdVGA). Allows for QXL support (in 4.3). (Zhou Peng,
          patches posted)

    * xl compatibility with xm:

        * [BUG] cannot create an empty CD-ROM drive on HVM guest,
          reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>

        * does not automatically try to select a (set of) node(s) on
          which to create a VM and pin its vcpus there. (Dario
          Faggioli, patches reposted, under review)

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

    * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
      Monné, patches posted)

    * Block script support -- follows on from hotplug script (Roger
      Pau Monné, "just be a matter of removing an "if"")

    * Adjustments needed for qdisk backend to work on non-pvops Linux.
      "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)

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

    * [BUG] Build failure due to gcc -Wswitch on some distros
      vs. LIBXL_DOMAIN_TYPE. (Dario Faggioli, DONE)

hypervisor, nice to have:

    * PoD performance improvements (George Dunlap, patches posted)

tools, nice to have:

    * xl compatibility with xm:

        * Accept "xl cr /dev/null param=value" to provide all config
          on the command line (W. Michael Petullo, patch posted)

    * libxl: Add API to retrieve domain console tty (Bamvor Jian
      Zhang, DONE)

    * libxl stable API

        * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
          Interface needs an overhaul, related to
          locking/serialization over domain create. IanJ to add note
          about this interface being substandard but otherwise defer
          to 4.3.

        * Interfaces which may need to be async:

            * libxl_cdrom_insert. Should be easy once
              disk_{add,remove} done. This is basically a helper
              function and its functionality can be implemented in
              terms of the libxl_disk_* interfaces. If this is not
              done in time we should document as a substandard
              interface which is subject to change post 4.2.

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

    * qemu-upstream for NetBSD (Roger)

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




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

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> tools, blockers:
> 
>     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)

Patch was posted and is in upstream qemu, just needs pulling back
into our two clones.

Jan

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > tools, blockers:
> > 
> >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> 
> Patch was posted and is in upstream qemu, just needs pulling back
> into our two clones.

Thanks. CCing Stefano to be sure he knows that...

Ian.

Re: Xen 4.2 TODO / Release Plan

[Stefano Stabellini]

On Tue, 12 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > tools, blockers:
> > > 
> > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > 
> > Patch was posted and is in upstream qemu, just needs pulling back
> > into our two clones.
> 
> Thanks. CCing Stefano to be sure he knows that...

qemu-upstream-unstable has been updated, Ian is responsible for
qemu-xen-unstable.

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> On Tue, 12 Jun 2012, Ian Campbell wrote:
> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > tools, blockers:
> > > > 
> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > > 
> > > Patch was posted and is in upstream qemu, just needs pulling back
> > > into our two clones.
> > 
> > Thanks. CCing Stefano to be sure he knows that...
> 
> qemu-upstream-unstable has been updated, Ian is responsible for
> qemu-xen-unstable.

I was about to ping Ian J about this, because there seems to be breakage
which would be fixed by this (Olaf: "grant table errors with
qemu-xen-traditional" today) but it looks like these patches weren't
actually submitted against the traditional tree? Or at least I can't
find any such thing.

Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
as is to the trad tree? Has any one tried running it? Is this what Olaf
tested in the thread referenced above?

That thread also references
<4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
should be applied to the trad tree too. Has anyone tested that combo?

I can see how Ian missed this -- it very much looked like those two
patches were for qemu-upstream only to me (from the subject, cc line etc
etc).

Ian.

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 20.06.12 at 17:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
>> On Tue, 12 Jun 2012, Ian Campbell wrote:
>> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
>> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > > tools, blockers:
>> > > > 
>> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan 
> Beulich)
>> > > 
>> > > Patch was posted and is in upstream qemu, just needs pulling back
>> > > into our two clones.
>> > 
>> > Thanks. CCing Stefano to be sure he knows that...
>> 
>> qemu-upstream-unstable has been updated, Ian is responsible for
>> qemu-xen-unstable.
> 
> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.
> 
> Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
> as is to the trad tree? Has any one tried running it? Is this what Olaf
> tested in the thread referenced above?

Apparently yes, except that the change did get applied to the
wrong function (and hence didn't work).

> That thread also references
> <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> should be applied to the trad tree too. Has anyone tested that combo?
> 
> I can see how Ian missed this -- it very much looked like those two
> patches were for qemu-upstream only to me (from the subject, cc line etc
> etc).

I didn't think that I needed to formally submit patches that were
requested to be ported over to -traditional when they already
went into upstream qemu. If I'm wrong with this, then please let
me know and I'll submit both patches asap.

Jan

Re: Xen 4.2 TODO / Release Plan

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

Certainly there is nothing automatic (people or computers) that fishes
changes to qemu upstream into -traditional.  If you want something
committed to qemu-xen-traditional you'll have to say so.

Ian.

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 20.06.12 at 17:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
>> I didn't think that I needed to formally submit patches that were
>> requested to be ported over to -traditional when they already
>> went into upstream qemu. If I'm wrong with this, then please let
>> me know and I'll submit both patches asap.
> 
> Certainly there is nothing automatic (people or computers) that fishes
> changes to qemu upstream into -traditional.  If you want something
> committed to qemu-xen-traditional you'll have to say so.

I'm not talking about anything automatic here. The need for
pulling the change over was pointed out a number of times by
both Stefano and me.

Anyway - do you need a formal patch submission, or can you
just pull out the one important and possibly one secondary
commits?

Jan

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Wed, 2012-06-20 at 16:40 +0100, Jan Beulich wrote:
> > That thread also references
> > <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> > should be applied to the trad tree too. Has anyone tested that combo?
> > 
> > I can see how Ian missed this -- it very much looked like those two
> > patches were for qemu-upstream only to me (from the subject, cc line etc
> > etc).
> 
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

This is really for Ian J to say but IMHO the two code bases have
diverged enough that blindly pulling from upstream -> traditional is not
a good idea, so at the least the change needs to be tested in that
context.

Even if we were happy to just pull things in then the mail needs to note
somewhere which tree(s) the patch should be applied to. 

Ian.

Re: Xen 4.2 TODO / Release Plan

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> This is really for Ian J to say but IMHO the two code bases have
> diverged enough that blindly pulling from upstream -> traditional is not
> a good idea, so at the least the change needs to be tested in that
> context.

Indeed.  I would like someone to at least have looked at the automatic
merge output from a cherry pick.

Ian.

Re: Xen 4.2 TODO / Release Plan

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> > qemu-upstream-unstable has been updated, Ian is responsible for
> > qemu-xen-unstable.

Sorry, I had this message marked to go back to but...

> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.

...indeed I wasn't sure what it was referring to.

Thanks,
Ian.

Re: Xen 4.2 TODO / Release Plan

[Roger Pau Monne]

Ian Campbell wrote:
> A bit late this week, due to my being on vacation. I'm on vacation
> next two Monday as well so it will be late then too.
>
> 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
>                                                  <<  WE ARE HERE
> When It's Ready -- First release candidate
> Weekly          -- RCN+1 until release
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)
>
> Other than that I think we should consider the freeze to be in full
> effect and the bar to entry to 4.2 to be very high.
>
> 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:
>
>          * LIBXL_NIC_TYPE enum names are confusing.
>
>          * Interfaces which may need to be async:
>
>              * libxl_domain_suspend. Move xc_domain_save/restore into a
>                separate process (IanJ, patches posted).
>
>              * libxl_device_{disk,nic,vkb,add,pci}_add (and
>                remove). (Roger, patches posted for disk&  nic, vkb
>                trivial, not looked at pci yet)
>
>          * use libxl_cpumap for b_info.avail_cpus instead of an int,
>            this"allows setting more than 31 CPUS (Yang Z Zhang, patches
>            posted)
>
>          * use an enum for VGA interface type (e.g. Cirrus,
>            StdVGA). Allows for QXL support (in 4.3). (Zhou Peng,
>            patches posted)
>
>      * xl compatibility with xm:
>
>          * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>            reported by Fabio Fantoni in<4F9672DD.2080902@tiscali.it>
>
>          * does not automatically try to select a (set of) node(s) on
>            which to create a VM and pin its vcpus there. (Dario
>            Faggioli, patches reposted, under review)
>
>      * More formally deprecate xm/xend. Manpage patches already in
>        tree. Needs release noting and communication around -rc1 to
>        remind people to test xl.
>
>      * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
>        Monné, patches posted)

Another round posted (v6), waiting for review.

>
>      * Block script support -- follows on from hotplug script (Roger
>        Pau Monné, "just be a matter of removing an "if"")
>
>      * Adjustments needed for qdisk backend to work on non-pvops Linux.
>        "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
>
>      * Confirm that migration from Xen 4.1 ->  4.2 works...
>
>      * [BUG] Build failure due to gcc -Wswitch on some distros
>        vs. LIBXL_DOMAIN_TYPE. (Dario Faggioli, DONE)
>
> hypervisor, nice to have:
>
>      * PoD performance improvements (George Dunlap, patches posted)
>
> tools, nice to have:
>
>      * xl compatibility with xm:
>
>          * Accept "xl cr /dev/null param=value" to provide all config
>            on the command line (W. Michael Petullo, patch posted)
>
>      * libxl: Add API to retrieve domain console tty (Bamvor Jian
>        Zhang, DONE)
>
>      * libxl stable API
>
>          * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>            Interface needs an overhaul, related to
>            locking/serialization over domain create. IanJ to add note
>            about this interface being substandard but otherwise defer
>            to 4.3.
>
>          * Interfaces which may need to be async:
>
>              * libxl_cdrom_insert. Should be easy once
>                disk_{add,remove} done. This is basically a helper
>                function and its functionality can be implemented in
>                terms of the libxl_disk_* interfaces. If this is not
>                done in time we should document as a substandard
>                interface which is subject to change post 4.2.
>
>      * 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)
>
>      * qemu-upstream for NetBSD (Roger)

Patch committed to netbsd kernel, awaiting approval.

>
>      * [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
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: Xen 4.2 TODO / Release Plan

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]

On Tue, 2012-06-12 at 14:00 +0100, Ian Campbell wrote: 
> * xl compatibility with xm:
> 
>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
> 
>         * does not automatically try to select a (set of) node(s) on
>           which to create a VM and pin its vcpus there. (Dario
>           Faggioli, patches reposted, under review)
> 
v2 posted last Friday.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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

Keir released 4.2.0 rc3 on Thursday. Please test.

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@mariner.uk.xensource.com>

    * [BUG] 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 Dunlap is performing initial
      investigations.

    * Disable generation id from xl. Microsoft changed the
      specification of this value between W8 beta and RC and we now
      implement the old spec. Disable for 4.2 and revist implementing
      hte new spec for 4.3. (Paul Durrant)

hypervisor, nice to have:

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

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

        * the parameter io and irq in domU config files are not
          evaluated by xl.  So it is not possible to passthrough a
          parallel port for my printer to domU when I start the domU
          with xl command. (reported by Dieter Bloms,
          <20120814100704.GA19704@bloms.de>)

    * 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
      (Done)

    * [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@SHSMSX102.ccr.corp.intel.com>)

    * address PoD problems with early host side accesses to guest
      address space (Jan Beulich, DONE)

    * fix ipxe build problems with gcc 4.7 (fedora 17).
      The following files fail to build:
        - ipxe/src/drivers/bus/isa.c
        - ipxe/src/drivers/net/myri10ge.c
        - ipxe/src/drivers/infiniband/qib7322.c
      Patches have been posted to ipxe-devel mailinglist, so we need
      to update our ipxe version or grab the patches. (DONE, Keir)

    * "xl list -l" does not produce proper json. Should be possible to
      make it into an array. Reported by Bastian Blank,
      <20120814121741.GA10214@wavehammer.waldi.eu.org>. (Ian Campbell, DONE)

    * "xl cpupool-create" segfault on incorrect input. Reported by
      George Dunlap,
      <CAFLBxZaEci0mOcDCgFX9zk=wh3z4Nf1LD5E5Fcy7Y3=ioDAM=g@mail.gmail.com>
      (Ian Campbell, patch posted)



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

Re: Xen 4.2 TODO / Release Plan

[George Dunlap]

On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, nice to have:
>
>     * [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)

I probably won't get a chance to work on this until I get back
mid-september, so this shouldn't be a blocker.

 -George

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Fri, 2012-08-31 at 18:26 +0100, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, nice to have:
> >
> >     * [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)
> 
> I probably won't get a chance to work on this until I get back
> mid-september, so this shouldn't be a blocker.

No problem. Since we hope to do the final RC this week that effectively
means its pushed out to 4.3 so I'll mark it as such.

Ian.

Re: Xen 4.2 TODO / Release Plan

[George Dunlap]

On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     * [BUG] 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 Dunlap is performing initial
>       investigations.

So it's hard to get directly comparable results, but I think that
early indications are that the biggest chunk of this is due to the
extra syscall overhead for a 64-bit dom0.  Data points are:
1. Ubuntu 12.04, 64-bit, pvops Ubuntu kernel, Xen 4.2-rc2, older AMD
system: qemu uses 50% on an idle system
2. XenServer built with Xen-4.2; (32-bit 2.6.32 dom0), Nehalem system:
<qemu uses 2% on an idle system
3. Debian wheezy with the squeeze 2.6.32 32-bit kernel, older AMD
system: qemu uses 10% on an idle system

Looking at the traces, it seems that on the AMD box there were just a
whole lot more USB-related IO accesses than on the Nehalem system.  #2
had far fewer USB-related accesses than #1, but #3 had about twice as
many as #1.  So it seems likely to be a combination between something
weird that the USB driver in the guest is doing under AMD, and the
extra overhead of a 64-bit kernel.

So I think this is probably OK to take off the blocker list (although
it's probably something we want to look into further).

 -George

Re: Xen 4.2 TODO / Release Plan

[Konrad Rzeszutek Wilk]

On Fri, Aug 31, 2012 at 10:36:47AM -0700, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >     * [BUG] 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 Dunlap is performing initial
> >       investigations.
> 
> So it's hard to get directly comparable results, but I think that
> early indications are that the biggest chunk of this is due to the
> extra syscall overhead for a 64-bit dom0.  Data points are:
> 1. Ubuntu 12.04, 64-bit, pvops Ubuntu kernel, Xen 4.2-rc2, older AMD
> system: qemu uses 50% on an idle system

So what happens if you run with a 32-bit dom0? What is the kernel
version? There were some issues with extra traps being done due to the
cpuidle running (which it should not).

> 2. XenServer built with Xen-4.2; (32-bit 2.6.32 dom0), Nehalem system:
> <qemu uses 2% on an idle system
> 3. Debian wheezy with the squeeze 2.6.32 32-bit kernel, older AMD
> system: qemu uses 10% on an idle system

Can you try booting with 'nohz=off'. What does 'perf top' (you need to
run v3.4 or later) give you?

> 
> Looking at the traces, it seems that on the AMD box there were just a
> whole lot more USB-related IO accesses than on the Nehalem system.  #2
> had far fewer USB-related accesses than #1, but #3 had about twice as
> many as #1.  So it seems likely to be a combination between something
> weird that the USB driver in the guest is doing under AMD, and the
> extra overhead of a 64-bit kernel.
> 
> So I think this is probably OK to take off the blocker list (although
> it's probably something we want to look into further).
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: Xen 4.2 TODO / Release Plan

[Pasi Kärkkäinen]

On Tue, Aug 28, 2012 at 11:06:01AM +0100, Ian Campbell wrote:
> 
>     * 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)
> 

Patch sent to the list.

-- Pasi

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Sun, 2012-09-02 at 05:46 +0100, Pasi Kärkkäinen wrote:
> On Tue, Aug 28, 2012 at 11:06:01AM +0100, Ian Campbell wrote:
> > 
> >     * 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)
> > 
> 
> Patch sent to the list.

Thanks!



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

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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


A handful of issues identified by the test day last week are included,
thanks to all who took part.

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@mariner.uk.xensource.com>

    * [BUG] 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 Dunlap is performing initial
      investigations.

hypervisor, nice to have:

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

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

        * the parameter io and irq in domU config files are not
          evaluated by xl.  So it is not possible to passthrough a
          parallel port for my printer to domU when I start the domU
          with xl command. (reported by Dieter Bloms,
          <20120814100704.GA19704@bloms.de>)

    * 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@SHSMSX102.ccr.corp.intel.com>)

    * address PoD problems with early host side accesses to guest
      address space (Jan Beulich, DONE)

    * fix ipxe build problems with gcc 4.7 (fedora 17).
      The following files fail to build:
        - ipxe/src/drivers/bus/isa.c
        - ipxe/src/drivers/net/myri10ge.c
        - ipxe/src/drivers/infiniband/qib7322.c
      Patches have been posted to ipxe-devel mailinglist, so we need
      to update our ipxe version or grab the patches. (DONE, Keir)

    * "xl list -l" does not produce proper json. Should be possible to
      make it into an array. Reported by Bastian Blank,
      <20120814121741.GA10214@wavehammer.waldi.eu.org>. (Ian Campbell,
      patch posted)

    * "xl cpupool-create" segfault on incorrect input. Reported by
      George Dunlap,
      <CAFLBxZaEci0mOcDCgFX9zk=wh3z4Nf1LD5E5Fcy7Y3=ioDAM=g@mail.gmail.com>
      (Ian Campbell, patch posted)



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

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 20.08.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     * 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)

Patch was posted, but no comments or approval to commit so far.
Also, reportedly the patch only improves the situation, it doesn't
completely eliminate the problem. For the moment I'm out of ideas,
though, and hence would hope some others could help here.

Jan

Re: Xen 4.2 TODO / Release Plan

[Ren, Yongjie]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Monday, August 20, 2012 5:17 PM
> To: xen-devel; xen-users
> Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
> 
>     * [BUG] long stop during the guest boot process with qcow image,
>       reported by Intel:
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> 
After reverting the "O_DIRECT for IDE" patch in qemu-xen tree, it works as fine as that before the bug.
But it still have some stop time (about 8~10s) after loading the Grub for a RHEL6.x guest.
I found even an old CS #23124 (about 1 year ago) also has the same phenomenon.
Currently, RHEL6.2 or RHEL6.3 guest can bootup in 30~40s (for either RAW or QCOW2 image).
And, RHEL5.5 guest (which has no stop time issue) can bootup in 50~60s.

I also commented in the bugzilla. You can also have a look for more details.

Will you want still track or fix this old issue ?  If not, I want to marked it as "fixed and verified".

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

Users list to BCC.

On Tue, 2012-08-21 at 16:14 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > Sent: Monday, August 20, 2012 5:17 PM
> > To: xen-devel; xen-users
> > Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
> > 
> >     * [BUG] long stop during the guest boot process with qcow image,
> >       reported by Intel:
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> > 
> After reverting the "O_DIRECT for IDE" patch in qemu-xen tree, it works as fine as that before the bug.
> But it still have some stop time (about 8~10s) after loading the Grub for a RHEL6.x guest.
> I found even an old CS #23124 (about 1 year ago) also has the same phenomenon.

23124 here is e3d4c34b14a3112481b5e86ff2406cd1bb5e1548 which is some
sort of tools build fix. What is the long hash of the changeset you are
referring to?

> Currently, RHEL6.2 or RHEL6.3 guest can bootup in 30~40s (for either RAW or QCOW2 image).
> And, RHEL5.5 guest (which has no stop time issue) can bootup in 50~60s.
> 
> I also commented in the bugzilla. You can also have a look for more details.
> 
> Will you want still track or fix this old issue ?  If not, I want to marked it as "fixed and verified".

If you think the issue is fixed then I will mark it done on the todo
list.

Ian.

Re: Xen 4.2 TODO / Release Plan

[Ren, Yongjie]

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, August 21, 2012 11:27 PM
> To: Ren, Yongjie
> Cc: xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
> 
> Users list to BCC.
> 
> On Tue, 2012-08-21 at 16:14 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xen.org
> > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > > Sent: Monday, August 20, 2012 5:17 PM
> > > To: xen-devel; xen-users
> > > Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
> > >
> > >     * [BUG] long stop during the guest boot process with qcow
> image,
> > >       reported by Intel:
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> > >
> > After reverting the "O_DIRECT for IDE" patch in qemu-xen tree, it works
> as fine as that before the bug.
> > But it still have some stop time (about 8~10s) after loading the Grub for a
> RHEL6.x guest.
> > I found even an old CS #23124 (about 1 year ago) also has the same
> phenomenon.
> 
> 23124 here is e3d4c34b14a3112481b5e86ff2406cd1bb5e1548 which is
> some
> sort of tools build fix. What is the long hash of the changeset you are
> referring to?
> 
Yes, it's "changeset:  23124:e3d4c34b14a3".
That changeset is picked out randomly just to confirm the stop time (8~10s) should already exist for a long time.

> > Currently, RHEL6.2 or RHEL6.3 guest can bootup in 30~40s (for either
> RAW or QCOW2 image).
> > And, RHEL5.5 guest (which has no stop time issue) can bootup in 50~60s.
> >
> > I also commented in the bugzilla. You can also have a look for more
> details.
> >
> > Will you want still track or fix this old issue ?  If not, I want to marked it
> as "fixed and verified".
> 
> If you think the issue is fixed then I will mark it done on the todo
> list.
> 
I think yes. The regression for long stop time (about 50s) in bootup for qcow2 image has already been fixed.
Now, 30s for a guest booting up is acceptable from my viewpoint.
If the 8~10 stop time really matters, we can setup another thread to discuss it.

Re: Xen 4.2 TODO / Release Plan

[Ben Guthro]

On Mon, Aug 20, 2012 at 5:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>

No significant progress made on this since the last update.
More questions raised than answers found. I'm having trouble making
sense of the current test results.

More debugging is needed. Jan is working on a debug patch to give to me.

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 21.08.12 at 17:39, Ben Guthro <ben@guthro.net> wrote:
> On Mon, Aug 20, 2012 at 5:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>
>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
> 
> No significant progress made on this since the last update.
> More questions raised than answers found. I'm having trouble making
> sense of the current test results.
> 
> More debugging is needed. Jan is working on a debug patch to give to me.

I haven't been able to get to this yesterday and today, and will
be working only half day tomorrow. After that I'll be traveling,
so it may well end up being only after the return from the summit
that I may be able to get you something.

Jan

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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@mariner.uk.xensource.com>

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@SHSMSX102.ccr.corp.intel.com>)

    * [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@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 14.08.12 at 11:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     * 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)

Second draft of a patch posted; no test results so far for first draft.

Jan

Re: Xen 4.2 TODO / Release Plan

[George Dunlap]

On Tue, Aug 14, 2012 at 10:05 AM, Ian Campbell <Ian.Campbell@citrix.com> 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@mariner.uk.xensource.com>
>
> 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@SHSMSX102.ccr.corp.intel.com>)
>
>     * [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@lists.xen.org
> http://lists.xen.org/xen-devel

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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
                                                << WE ARE HERE
When It's Ready -- First release candidate	<< THIS WEEK
Weekly          -- RCN+1 until release

The updated TODO list follows.

There are lots of things completed this week. Therefore we intend to
release rc1 this week.

The outstanding known issues are relatively minor and will be resolved
after rc1.

hypervisor, blockers:

    * [BUG] EFI binaries installed to /efi instead of under /usr/lib
      after LIB_DIR definition moved to configure script. (Matt
      Wilson, DONE)

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:

        * Interfaces which may need to be async:

            * libxl_device_{disk,nic,vkb,add,pci}_add (and
              remove). (Roger Pau Monné, DONE)

            * libxl_device_pci_add (and remove). (Ian C, patch
              posted)

        * LIBXL_NIC_TYPE enum names are confusing. (Roger, DONE)

    * xl compatibility with xm:

        * [BUG] cannot create an empty CD-ROM drive on HVM guest,
          reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
          (Ian C & Ian J, DONE) 

        * does not automatically try to select a (set of) node(s) on
          which to create a VM and pin its vcpus there. (Dario
          Faggioli, DONE)

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

    * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
      Monné, DONE)

    * Block script support (Ian C, patch sent, resend pending)

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

    * libxl to reject attempts to migrate a domain using upstream
      qemu, due to lack of log dirty support (Ian C, DONE)

    * [BUG] parameter 'maxvcpus' causes hvm guest boots up with wrong
      vcpu number http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1825
      (<E4558C0C96688748837EB1B05BEED75A0FD5574A@SHSMSX102.ccr.corp.intel.com>)
      ("Zhang, Yang Z", DONE)

    * [BUG] libxl__devices_destroy has a race against
      plugging/unplugging devices to the domain which can result in
      over- or under-flowing the aodevs array (Roger Pau Monné, Ian
      Jackson, patches sent)

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)

tools, nice to have:

    * xl compatibility with xm:

        * None

    * libxl stable API

        * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
          Interface needs an overhaul, related to
          locking/serialization over domain create. IanJ to add note
          about this interface being substandard but otherwise defer
          to 4.3.

        * Interfaces which may need to be async:

            * libxl_cdrom_insert. (IanC, DONE)

    * 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@SHSMSX102.ccr.corp.intel.com>)



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

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Mon, 2012-07-30 at 09:30 +0100, Ian Campbell wrote:
>     * vMCE save/restore changes, to simplify migration 4.2->4.3 with
>      new vMCE in 4.3. (Jinsong Liu, Jan Beulich)

Where are we with this?

Is it still a viable candidate for 4.2, now that we have reached rc1
(almost 2)?

Re: Xen 4.2 TODO / Release Plan

[Keir Fraser]

On 03/08/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-07-30 at 09:30 +0100, Ian Campbell wrote:
>>     * vMCE save/restore changes, to simplify migration 4.2->4.3 with
>>      new vMCE in 4.3. (Jinsong Liu, Jan Beulich)
> 
> Where are we with this?
> 
> Is it still a viable candidate for 4.2, now that we have reached rc1
> (almost 2)?

Didn't we already take the trivial patch that will ease the transition to
4.3?

 -- Keir

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

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Fri, 2012-08-03 at 11:28 +0100, Keir Fraser wrote:
> On 03/08/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-07-30 at 09:30 +0100, Ian Campbell wrote:
> >>     * vMCE save/restore changes, to simplify migration 4.2->4.3 with
> >>      new vMCE in 4.3. (Jinsong Liu, Jan Beulich)
> > 
> > Where are we with this?
> > 
> > Is it still a viable candidate for 4.2, now that we have reached rc1
> > (almost 2)?
> 
> Didn't we already take the trivial patch that will ease the transition to
> 4.3?

Possibly, in which case I can scratch it off the list.

Ian.

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 03.08.12 at 12:28, Keir Fraser <keir.xen@gmail.com> wrote:
> On 03/08/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
>> On Mon, 2012-07-30 at 09:30 +0100, Ian Campbell wrote:
>>>     * vMCE save/restore changes, to simplify migration 4.2->4.3 with
>>>      new vMCE in 4.3. (Jinsong Liu, Jan Beulich)
>> 
>> Where are we with this?
>> 
>> Is it still a viable candidate for 4.2, now that we have reached rc1
>> (almost 2)?
> 
> Didn't we already take the trivial patch that will ease the transition to
> 4.3?

We took one necessary patch, but I think at least the second
one of the recently posted series would also be needed. And
the really important patch for migration forward compatibility
was patch 5 in that series, yet I wouldn't want to take patches
3 and 4 for 4.2.

In any case, the series is in need of resubmission anyway.
Perhaps (if that's possible, I didn't check in too much detail)
reordering patch 5 could be done at once.

Jan

Re: Xen 4.2 TODO / Release Plan

[Liu, Jinsong]

Jan Beulich wrote:
>>>> On 03.08.12 at 12:28, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 03/08/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>> 
>>> On Mon, 2012-07-30 at 09:30 +0100, Ian Campbell wrote:
>>>>     * vMCE save/restore changes, to simplify migration 4.2->4.3
>>>>      with new vMCE in 4.3. (Jinsong Liu, Jan Beulich)
>>> 
>>> Where are we with this?
>>> 
>>> Is it still a viable candidate for 4.2, now that we have reached rc1
>>> (almost 2)?
>> 
>> Didn't we already take the trivial patch that will ease the
>> transition to 
>> 4.3?
> 
> We took one necessary patch, but I think at least the second
> one of the recently posted series would also be needed. And
> the really important patch for migration forward compatibility
> was patch 5 in that series, yet I wouldn't want to take patches
> 3 and 4 for 4.2.
> 
> In any case, the series is in need of resubmission anyway.
> Perhaps (if that's possible, I didn't check in too much detail)
> reordering patch 5 could be done at once.
> 

Patch 2 has been updated according to Jan's comments.

As for patch 5, it cannot be reordered w/o patch 3 checked in (patch 5 is for save/restore MCi_CTL2, a newly added MSR at patch 3). In fact we could remove patch 5 totally, and don't add MCi_CTL2 (this MSR is nothing to do with vmce logic itself, the only reason why we add it in new vmce is to get perfromance benefit (but very trivial), so it's OK not to add it and remove patch 5). Another benefit of not add MCi_CTL2 is, to avoid difference between Intel and AMD code. Hence I think it's an acceptable approach to keep current vmce (not implement MCi_CTL2). Your opinion?

Thanks,
Jinsong

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 06.08.12 at 19:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> As for patch 5, it cannot be reordered w/o patch 3 checked in (patch 5 is 
> for save/restore MCi_CTL2, a newly added MSR at patch 3). In fact we could 
> remove patch 5 totally, and don't add MCi_CTL2 (this MSR is nothing to do 
> with vmce logic itself, the only reason why we add it in new vmce is to get 
> perfromance benefit (but very trivial), so it's OK not to add it and remove 
> patch 5).

But I thought you were pretty keen on getting in this performance
improvement?

> Another benefit of not add MCi_CTL2 is, to avoid difference between 
> Intel and AMD code. Hence I think it's an acceptable approach to keep current 
> vmce (not implement MCi_CTL2). Your opinion?

Current code already handles MCi_CTL2, but incompletely (always
returning zero for reads, and dropping writes). This is valid because
nothing gets announced that should make a guest think it can
access those MSRs in the first place. I do think, however, that
getting this right (and at once getting the guest side polling
disabled) is beneficial, the question just is whether we want to set
the ground for this now, or deal with it after 4.2 went out.

I'm favoring doing it now, and I don't see the strict relationship
to patch #3 - with what we currently implement it would be
sufficient to save zeros and fail non-zero restores (which ought
to fail earlier already anyway, since the implication of the MSRs
here having non-zero values would be for MCG_CAP to have an
unsupported value to be restored too).

Otoh, restoring from saved state that only includes MCG_CAP (but
no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
to be zero, which would be trivial as that's the startup state, i.e.
the only complication here is the variable size save record), so
pushing this to post-4.2 as well is a reasonable alternative.

Keir, Ian?

Jan

Re: Xen 4.2 TODO / Release Plan

[Keir Fraser]

On 07/08/2012 07:38, "Jan Beulich" <JBeulich@suse.com> wrote:

> Otoh, restoring from saved state that only includes MCG_CAP (but
> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
> to be zero, which would be trivial as that's the startup state, i.e.
> the only complication here is the variable size save record), so
> pushing this to post-4.2 as well is a reasonable alternative.
> 
> Keir, Ian?

I think we should leave it and handle the variable-sized save record in 4.3.
Using hvm_load_entry_zeroextend() to read in save records, with zero padding
for older shorter records, should be straightforward enough.

 -- Keir

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/08/2012 07:38, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Otoh, restoring from saved state that only includes MCG_CAP (but
>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>> to be zero, which would be trivial as that's the startup state, i.e.
>> the only complication here is the variable size save record), so
>> pushing this to post-4.2 as well is a reasonable alternative.
>> 
>> Keir, Ian?
> 
> I think we should leave it and handle the variable-sized save record in 4.3.
> Using hvm_load_entry_zeroextend() to read in save records, with zero padding
> for older shorter records, should be straightforward enough.

Okay. So Ian, you could then take the corresponding item
off the list. Or do you do that only once patches make it
through the regression tester?

Jan

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Tue, 2012-08-07 at 09:05 +0100, Jan Beulich wrote:
> >>> On 07.08.12 at 09:50, Keir Fraser <keir.xen@gmail.com> wrote:
> > On 07/08/2012 07:38, "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> Otoh, restoring from saved state that only includes MCG_CAP (but
> >> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
> >> to be zero, which would be trivial as that's the startup state, i.e.
> >> the only complication here is the variable size save record), so
> >> pushing this to post-4.2 as well is a reasonable alternative.
> >> 
> >> Keir, Ian?
> > 
> > I think we should leave it and handle the variable-sized save record in 4.3.
> > Using hvm_load_entry_zeroextend() to read in save records, with zero padding
> > for older shorter records, should be straightforward enough.
> 
> Okay. So Ian, you could then take the corresponding item
> off the list. Or do you do that only once patches make it
> through the regression tester?

I'll mark it as done for 4.2.

> 
> Jan
> 

Re: Xen 4.2 TODO / Release Plan

[Liu, Jinsong]

Jan Beulich wrote:
>>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/08/2012 07:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Otoh, restoring from saved state that only includes MCG_CAP (but
>>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>>> to be zero, which would be trivial as that's the startup state, i.e.
>>> the only complication here is the variable size save record), so
>>> pushing this to post-4.2 as well is a reasonable alternative.
>>> 
>>> Keir, Ian?
>> 
>> I think we should leave it and handle the variable-sized save record
>> in 4.3. Using hvm_load_entry_zeroextend() to read in save records,
>> with zero padding for older shorter records, should be
>> straightforward enough. 
> 
> Okay. So Ian, you could then take the corresponding item
> off the list. Or do you do that only once patches make it
> through the regression tester?
> 

So we will leave it and handle it after 4.2, right?
I will take 1 week vacation start from tomorrow, so Jan, if anythting misunderstanding please let me know asap.

Thanks,
Jinsong

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 07.08.12 at 20:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 07/08/2012 07:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> 
>>>> Otoh, restoring from saved state that only includes MCG_CAP (but
>>>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>>>> to be zero, which would be trivial as that's the startup state, i.e.
>>>> the only complication here is the variable size save record), so
>>>> pushing this to post-4.2 as well is a reasonable alternative.
>>>> 
>>>> Keir, Ian?
>>> 
>>> I think we should leave it and handle the variable-sized save record
>>> in 4.3. Using hvm_load_entry_zeroextend() to read in save records,
>>> with zero padding for older shorter records, should be
>>> straightforward enough. 
>> 
>> Okay. So Ian, you could then take the corresponding item
>> off the list. Or do you do that only once patches make it
>> through the regression tester?
>> 
> 
> So we will leave it and handle it after 4.2, right?

Yes. It would be nice if you could then resubmit the rest of
the series, addressing pending review comments.

Jan

Xen 4.2 TODO / Release Plan

[Ian Campbell]

I missed last week and yesterday because I was travelling, but here is
an update...

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
                                                << WE ARE HERE
When It's Ready -- First release candidate
Weekly          -- RCN+1 until release

The updated TODO list follows.

If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)

Per the release plan a strong case will now have to be made as to why
new items should be added to the list, especially as a blocker, rather
than deferred to 4.3.

hypervisor, blockers:

    * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset
      HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, DONE)

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:

        * Interfaces which may need to be async:

            * libxl_device_{disk,nic,vkb,add,pci}_add (and
              remove). (Roger Pau Monné, all except pci included in
              calling hotplug scripts from xl)

        * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in
          calling hotplug scripts series)

    * xl compatibility with xm:

        * [BUG] cannot create an empty CD-ROM drive on HVM guest,
          reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>

        * does not automatically try to select a (set of) node(s) on
          which to create a VM and pin its vcpus there. (Dario
          Faggioli, first half applied, second half reposted)

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

    * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
      Monné, v9 posted)

    * Block script support -- follows on from hotplug script (Roger
      Pau Monné, "just be a matter of removing an "if"")

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

    * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on
      modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson,
      DONE)

    * libxl to reject attempts to migrate a domain using upstream
      qemu, due to lack of log dirty support (Ian C, patch sent,
      awaiting review)

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)

tools, nice to have:

    * xl compatibility with xm:

        * Accept "xl cr /dev/null param=value" to provide all config
          on the command line (W. Michael Petullo, DONE)

    * libxl stable API

        * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
          Interface needs an overhaul, related to
          locking/serialization over domain create. IanJ to add note
          about this interface being substandard but otherwise defer
          to 4.3.

        * Interfaces which may need to be async:

            * libxl_cdrom_insert. Should be easy once
              disk_{add,remove} done. This is basically a helper
              function and its functionality can be implemented in
              terms of the libxl_disk_* interfaces. If this is not
              done in time we should document as a substandard
              interface which is subject to change post 4.2.

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



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

Re: Xen 4.2 TODO / Release Plan

[Andrew Cooper]

On 17/07/12 17:47, Ian Campbell wrote:
> I missed last week and yesterday because I was travelling, but here is
> an update...
>
> 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
>                                                 << WE ARE HERE
> When It's Ready -- First release candidate
> Weekly          -- RCN+1 until release
>
> The updated TODO list follows.
>
> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)
>
> Per the release plan a strong case will now have to be made as to why
> new items should be added to the list, especially as a blocker, rather
> than deferred to 4.3.
>
> hypervisor, blockers:
>
>     * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset
>       HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, DONE)
>
> 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:
>
>         * Interfaces which may need to be async:
>
>             * libxl_device_{disk,nic,vkb,add,pci}_add (and
>               remove). (Roger Pau Monné, all except pci included in
>               calling hotplug scripts from xl)
>
>         * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in
>           calling hotplug scripts series)
>
>     * xl compatibility with xm:
>
>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
>
>         * does not automatically try to select a (set of) node(s) on
>           which to create a VM and pin its vcpus there. (Dario
>           Faggioli, first half applied, second half reposted)
>
>     * [CHECK] More formally deprecate xm/xend. Manpage patches already
>       in tree. Needs release noting and communication around -rc1 to
>       remind people to test xl.
>
>     * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
>       Monné, v9 posted)
>
>     * Block script support -- follows on from hotplug script (Roger
>       Pau Monné, "just be a matter of removing an "if"")
>
>     * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works.
>
>     * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on
>       modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson,
>       DONE)
>
>     * libxl to reject attempts to migrate a domain using upstream
>       qemu, due to lack of log dirty support (Ian C, patch sent,
>       awaiting review)
>
> 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)

* Complete docs for hypervisor command line options.
I am currently working on this while other things are compiling.

~Andrew

>
> tools, nice to have:
>
>     * xl compatibility with xm:
>
>         * Accept "xl cr /dev/null param=value" to provide all config
>           on the command line (W. Michael Petullo, DONE)
>
>     * libxl stable API
>
>         * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>           Interface needs an overhaul, related to
>           locking/serialization over domain create. IanJ to add note
>           about this interface being substandard but otherwise defer
>           to 4.3.
>
>         * Interfaces which may need to be async:
>
>             * libxl_cdrom_insert. Should be easy once
>               disk_{add,remove} done. This is basically a helper
>               function and its functionality can be implemented in
>               terms of the libxl_disk_* interfaces. If this is not
>               done in time we should document as a substandard
>               interface which is subject to change post 4.2.
>
>     * 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)
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




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

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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
                                                << WE ARE HERE
Mid/Late May    -- First release candidate
Weekly          -- RCN+1 until it is ready

The updated TODO list follows. Per the release plan a strong case will
now have to be made as to why new items should be added to the list,
especially as a blocker, rather than deferred to 4.3.

A lot of new DONE items. The big remaining items are
the hotplug script series and asynchronisation of migration.

If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)

Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.

hypervisor, blockers:
      * Performance regression due to contention on p2m lock. (Tim,
        Andres, DONE) 
 
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:
              * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
                Interface needs an overhaul, related to
                locking/serialization over domain create (deferred to
                4.3). IanJ to add note about this interface being
                substandard but otherwise defer to 4.3.
              * libxl_*_path. Majority made internal, only configdir and
                lockdir remain public (used by xl). (IanC, to consider
                moving the two reamining into xl instead of libxl)
              * Interfaces which may need to be async:
                      * libxl_domain_suspend. Move
                        xc_domain_save/restore into a separate process
                        (IanJ, RFC posted).
                      * libxl_device_{disk,nic,vkb,add,pci}_add (and
                        remove?). Roger Pau Monné fixes disk as part of
                        hotplug script series and adds infrastructure
                        which should make the others trivial. (Roger,
                        WIP)
                      * libxl_cdrom_insert. Should be easy once
                        disk_{add,remove} done. Nobody is looking at
                        this?
                      * libxl_device_disk_local_{attach,detach}. Become
                        internal as part of Stefano's domain 0 disk
                        attach series (already tracked below, "Domain 0
                        block attach & general hotplug", will remove
                        this entry instance from next weeks list in
                        favour of that one)
      * xl compatibility with xm:
              * [BUG] cannot create an empty CD-ROM driver on HVM guest,
                reported by Fabio Fantoni in
                <4F9672DD.2080902@tiscali.it>
              * does not automatically try to select a (set of) node(s)
                on which to create a VM and pin its vcpus there. (Dario
                Faggioli, patches posted)
              * `cpus=[2,3]` to select specific mapping vcpu0-->pcpu2,
                vcpu1-->pcpu3 as xm does. (Dario Faggioli, patches
                posted and reviewed, will repost)
      * [BUG] Spurious CPU params error message when starting a domain,
        e.g. "Cpu weight out of range, valid values are within range
        from 1 to 65535". ("George will do it if no one else steps up")
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.
      * xl to refuse to run if xend is running, Roger Pau Monné (DONE)
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc) (Stefano S, patches
        posted, needs updates)
      * Improved Hotplug script support (Roger Pau Monné, patches
        posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monné)
      * xs.h -> xenstore.h. Should do this for 4.2 rather than have
        distros carry their own patches. (Ian C, DONE)
      * Adjustments needed for qdisk backend to work on non-pvops Linux.
        (Jan Beulich)

hypervisor, nice to have:
      * PoD performance improvements (George Dunlap)
      * IRQ problem for which debugging code got added by c/s
        24707:96987c324a4f. I have a tentative adjustment to this which
        I would hope to at least eliminate the bad consequences of
        crashing the hypervisor (converting the unsolicited
        PIC-originated IRQ into a spurious one). I'll submit as soon as
        I got to test this a little, particularly also on an old box
        without APIC. (Jan Beulich)

tools, nice to have:
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                awaiting qemy upstream review)
                      * Upstream qemu is frozen for their next release.
                        Unlikely that these will be accepted in the next
                        few weeks. Defered until 4.3 (therefore DONE in
                        this context)
              * Initial xl support for Remus (memory checkpoint,
                blackholing) (Shriram, DONE)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=1 or
                otherwise) (Goncalo Gomes, DONE)
      * Directory usage in libxl (Bastian, as part of Debian packaging).
        Defer to 4.3, therefore DONE in this context.
              * dumps in /var/xen: wtf?
                      * Bastian: "The FHS defines /var/crash for system
                        crash dumps, but it is not used everywhere. So I
                        would use /var/lib/xen/dump or so."
              * user data files in /var/lib/xen:
                      * What are the guarantees given for this files?
                      * Bastian: "I don't think rebooting the control
                        domain without rebooting Xen will work right
                        now. So /var/run is the correct location."
              * /var/run/libxl for temporary files
                      * "$TMPDIR or the fallback /tmp is the correct
                        location."
      * xl commands to help rebind pci devices to pciback.  (George
        Dunlap, DONE)
      * libxl: Add API to retrieve domain console tty (Bamvor Jian
        Zhang, patches posted)



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

Re: Xen 4.2 TODO / Release Plan

[Pasi Kärkkäinen]

On Mon, May 21, 2012 at 12:47:37PM +0100, Ian Campbell wrote:
> 
> tools, nice to have:
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 awaiting qemy upstream review)
>                       * Upstream qemu is frozen for their next release.
>                         Unlikely that these will be accepted in the next
>                         few weeks. Defered until 4.3 (therefore DONE in
>                         this context)
>               * Initial xl support for Remus (memory checkpoint,
>                 blackholing) (Shriram, DONE)
>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, DONE)
>       * Directory usage in libxl (Bastian, as part of Debian packaging).
>         Defer to 4.3, therefore DONE in this context.
>               * dumps in /var/xen: wtf?
>                       * Bastian: "The FHS defines /var/crash for system
>                         crash dumps, but it is not used everywhere. So I
>                         would use /var/lib/xen/dump or so."
>               * user data files in /var/lib/xen:
>                       * What are the guarantees given for this files?
>                       * Bastian: "I don't think rebooting the control
>                         domain without rebooting Xen will work right
>                         now. So /var/run is the correct location."
>               * /var/run/libxl for temporary files
>                       * "$TMPDIR or the fallback /tmp is the correct
>                         location."
>       * xl commands to help rebind pci devices to pciback.  (George
>         Dunlap, DONE)
>       * libxl: Add API to retrieve domain console tty (Bamvor Jian
>         Zhang, patches posted)
> 

	* 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

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Mon, 2012-05-21 at 14:00 +0100, Pasi Kärkkäinen wrote:
> 	* 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).

Would you be able to put that into patch form please?

Ian.


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

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 21.05.12 at 13:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>       * IRQ problem for which debugging code got added by c/s
>         24707:96987c324a4f. I have a tentative adjustment to this which
>         I would hope to at least eliminate the bad consequences of
>         crashing the hypervisor (converting the unsolicited
>         PIC-originated IRQ into a spurious one). I'll submit as soon as
>         I got to test this a little, particularly also on an old box
>         without APIC. (Jan Beulich)

That adjustment is already in (25336:edd7c7ad1ad2). But there's
still the issue of xfree() being called from interrupt context, for
which Andy Cooper had posted a patch, while I later suggested
to address the issue in a more general form. No feedback from
Keir so far, so perhaps I should go ahead and submit the
adjustment in more formal shape.

Jan

Xen 4.2 TODO / Release Plan

[Ian Campbell]

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
                                                << WE ARE HERE
Mid/Late May    -- First release candidate
Weekly          -- RCN+1 until it is ready

The updated TODO list follows. Per the release plan a strong case will
now have to be made as to why new items should be added to the list,
especially as a blocker, rather than deferred to 4.3.

A lot of new DONE and one of the bigger items (IanJ's async
bootloader/create/fork series) is now in. The remaining big items are
the hotplug script series and asynchronisation of migration.

We have made a freeze exception for George's "pciback autobind" patch to
xl, since it is self contained. Likewise Bastian's suggestion to rename
xs.h -> xenstore.h (since the old name is too short and now conflicts
with another project) has been accepted (with compat symlinks) for 4.2
in order to get the transition under way ASAP.

Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.

hypervisor, blockers:
      * Performance regression due to contention on p2m lock. Patches
        posted, reviewed, updated, to go in shortly (Tim, Andres) 
 
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:
              * Safe fork vs. fd handling hooks. Involves API changes
                (Ian J, I think this was actually DONE a while back and
                I missed it)
              * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
                Interface needs an overhaul, related to
                locking/serialization over domain create (deferred to
                4.3). IanJ to add note about this interface being
                substandard but otherwise defer to 4.3.
              * libxl_*_path. Majority made internal, only configdir and
                lockdir remain public (used by xl). Good enough?
              * Interfaces which may need to be async:
                      * libxl_domain_suspend. Probably need to move
                        xc_domain_save into a separate process, as per
                        <20366.40183.410388.447630@mariner.uk.xensource.com>. Likely need to do the same for xc_domain_restore too. (IanJ).
                      * libxl_domain_create_{new,restore} -- IanJ has
                        patches as part of event series, (DONE).
                      * libxl_domain_core_dump. Can take a dummy ao_how
                        and remain synchronous internally. (IanC, DONE)
                      * libxl_device_{disk,nic,vkb,add,pci}_add (and
                        remove?). Roger Pau Monné fixes disk as part of
                        hotplug script series and adds infrastructure
                        which should make the others trivial. (Roger,
                        WIP)
                      * libxl_cdrom_insert. Should be easy once
                        disk_{add,remove} done, IanJ to look at (or
                        doing so?).
                      * libxl_device_disk_local_{attach,detach}. Become
                        internal as part of Stefano's domain 0 disk
                        attach series (patches posted, another round
                        required?)
                      * libxl_fork -- IanJ's event series will remove
                        all users of this. (DONE)
      * [BUG] Manually ballooning dom0.  xl mem-set 0 [foo] fails with
        "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get
        memory info from /local/domain/0/memory/static-max: No such file
        or directory". This might be suitable for an enthusiastic
        on-looker. (Seems to have been fixed, DONE)
      * xl compatibility with xm:
              * [BUG] cannot create an empty CD-ROM driver on HVM guest,
                reported by Fabio Fantoni in
                <4F9672DD.2080902@tiscali.it>
              * [BUG] Spurious CPU params error message when starting a
                domain, e.g. "Cpu weight out of range, valid values are
                within range from 1 to 65535". ("George will do it if no
                one else steps up")
              * does not automatically try to select a (set of) node(s)
                on which to create a VM and pin its vcpus there. (Dario
                Faggioli, patches posted)
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.
      * xl to refuse to run if xend is running, Roger Pau Monné (patch
        posted, needs rebase)
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc) (Stefano S, patches
        posted, needs updates)
      * Improved Hotplug script support (Roger Pau Monné, patches
        posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monné)
      * xs.h -> xenstore.h. Should do this for 4.2 rather than have
        distros carry their own patches. (Ian C, patch posted)

hypervisor, nice to have:
      * PoD performance improvements (George Dunlap)

tools, nice to have:
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                awaiting qemy upstream review)
                      * Upstream qemu is frozen for their next release.
                        Unlikely that these will be accepted in the next
                        few weeks. Given that upstream qemu is not yet
                        the default I think it is acceptable to defer
                        PCI passthrough support to 4.3.
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini, qemu patches applied, libxl patches applied.
                Done)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, was waiting on libxl side of qemu upstream
        save/restore, now unblocked)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=1 or
                otherwise) (Goncalo Gomes, new version of patch posted
                recently)
      * Directory usage in libxl (Bastian, as part of Debian packaging,
        likely to defer to 4.3 unless there is some big problem with
        packaging deviating from upstream)
              * dumps in /var/xen: wtf?
                      * Bastian: "The FHS defines /var/crash for system
                        crash dumps, but it is not used everywhere. So I
                        would use /var/lib/xen/dump or so."
              * user data files in /var/lib/xen:
                      * What are the guarantees given for this files?
                      * Bastian: "I don't think rebooting the control
                        domain without rebooting Xen will work right
                        now. So /var/run is the correct location."
              * /var/run/libxl for temporary files
                      * "$TMPDIR or the fallback /tmp is the correct
                        location."
      * xl commands to help rebind pci devices to pciback. 

[0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html




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

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> tools, blockers:

Adjustments needed for qdisk backend to work on non-pvops Linux.

> hypervisor, nice to have:

IRQ problem for which debugging code got added by c/s
24707:96987c324a4f. I have a tentative adjustment to this which I
would hope to at least eliminate the bad consequences of crashing
the hypervisor (converting the unsolicited PIC-originated IRQ into
a spurious one). I'll submit as soon as I got to test this a little,
particularly also on an old box without APIC.

Jan

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:
> 
> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
> > tools, blockers:
> 
> Adjustments needed for qdisk backend to work on non-pvops Linux.

Can you remind me what those are please. Do they touch libxl or libxc?

Thanks,
Ian.

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:
>> 
>> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com>
>> wrote:
>> > tools, blockers:
>> 
>> Adjustments needed for qdisk backend to work on non-pvops Linux.
> 
> Can you remind me what those are please.

"qemu/xendisk: set maximum number of grants to be used"
(http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html).

Unfortunately I didn't hear back from Olaf regarding the updated
value that the supposed v2 of the patch (see the thread), which
is at least partly due to him having further problems with the qdisk
backend. Olaf - did you ever see gntdev allocation failures again
after switching to the higher value?

> Do they touch libxl or libxc?

The libxc touching one went in already (25330:49ce39c88aee).

Jan

Re: Xen 4.2 TODO / Release Plan

[Olaf Hering]

On Tue, May 29, Jan Beulich wrote:

> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:
> >> 
> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com>
> >> wrote:
> >> > tools, blockers:
> >> 
> >> Adjustments needed for qdisk backend to work on non-pvops Linux.
> > 
> > Can you remind me what those are please.
> 
> "qemu/xendisk: set maximum number of grants to be used"
> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html).
> 
> Unfortunately I didn't hear back from Olaf regarding the updated
> value that the supposed v2 of the patch (see the thread), which
> is at least partly due to him having further problems with the qdisk
> backend. Olaf - did you ever see gntdev allocation failures again
> after switching to the higher value?

I just did a successful installation of sles11sp2 guest on a
xen-unstable host with changeset 25427:ad348c6575b8, and with the change
below, and the second attempt I just started seems get through as well.

I'm sure I used this variant already two weeks ago, and the install
still failed. Perhaps other changes made during the last two weeks make
a difference.

I will also doublecheck how it goes without this change.

Olaf

--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice *
     if (xen_mode != XEN_EMULATE) {
         batch_maps = 1;
     }
+    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
+               2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0)
+        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
+                      strerror(errno));
 }

 static int blk_init(struct XenDevice *xendev)

Re: Xen 4.2 TODO / Release Plan

[Jan Beulich]

>>> On 31.05.12 at 11:24, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, May 29, Jan Beulich wrote:
> 
>> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:
>> >> 
>> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com>
>> >> wrote:
>> >> > tools, blockers:
>> >> 
>> >> Adjustments needed for qdisk backend to work on non-pvops Linux.
>> > 
>> > Can you remind me what those are please.
>> 
>> "qemu/xendisk: set maximum number of grants to be used"
>> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html).
>> 
>> Unfortunately I didn't hear back from Olaf regarding the updated
>> value that the supposed v2 of the patch (see the thread), which
>> is at least partly due to him having further problems with the qdisk
>> backend. Olaf - did you ever see gntdev allocation failures again
>> after switching to the higher value?
> 
> I just did a successful installation of sles11sp2 guest on a
> xen-unstable host with changeset 25427:ad348c6575b8, and with the change
> below, and the second attempt I just started seems get through as well.
> 
> I'm sure I used this variant already two weeks ago, and the install
> still failed. Perhaps other changes made during the last two weeks make
> a difference.

That would be odd.

> I will also doublecheck how it goes without this change.
> 
> Olaf
> 
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice *
>      if (xen_mode != XEN_EMULATE) {
>          batch_maps = 1;
>      }
> +    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
> +               2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0)

The + 1 at the end is certainly not needed anymore after the
doubling.

> +        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
> +                      strerror(errno));
>  }
> 
>  static int blk_init(struct XenDevice *xendev)

So I think I'll re-submit with the doubled values then. That's
in any case better than not setting an upper limit at all on those
older kernels.

Jan

Re: Xen 4.2 TODO / Release Plan

[Stefano Stabellini]

On Thu, 31 May 2012, Jan Beulich wrote:
> >>> On 31.05.12 at 11:24, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, May 29, Jan Beulich wrote:
> > 
> >> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:
> >> >> 
> >> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com>
> >> >> wrote:
> >> >> > tools, blockers:
> >> >> 
> >> >> Adjustments needed for qdisk backend to work on non-pvops Linux.
> >> > 
> >> > Can you remind me what those are please.
> >> 
> >> "qemu/xendisk: set maximum number of grants to be used"
> >> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html).
> >> 
> >> Unfortunately I didn't hear back from Olaf regarding the updated
> >> value that the supposed v2 of the patch (see the thread), which
> >> is at least partly due to him having further problems with the qdisk
> >> backend. Olaf - did you ever see gntdev allocation failures again
> >> after switching to the higher value?
> > 
> > I just did a successful installation of sles11sp2 guest on a
> > xen-unstable host with changeset 25427:ad348c6575b8, and with the change
> > below, and the second attempt I just started seems get through as well.
> > 
> > I'm sure I used this variant already two weeks ago, and the install
> > still failed. Perhaps other changes made during the last two weeks make
> > a difference.
> 
> That would be odd.
> 
> > I will also doublecheck how it goes without this change.
> > 
> > Olaf
> > 
> > --- a/hw/xen_disk.c
> > +++ b/hw/xen_disk.c
> > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice *
> >      if (xen_mode != XEN_EMULATE) {
> >          batch_maps = 1;
> >      }
> > +    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
> > +               2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0)
> 
> The + 1 at the end is certainly not needed anymore after the
> doubling.
> 
> > +        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
> > +                      strerror(errno));
> >  }
> > 
> >  static int blk_init(struct XenDevice *xendev)
> 
> So I think I'll re-submit with the doubled values then. That's
> in any case better than not setting an upper limit at all on those
> older kernels.
 
At this point I would prefer that you defined a MAX_GRANT_REQS constant
and added a comment to explain what is for, and why it is set to (2 *
max_requests).

Re: Xen 4.2 TODO / Release Plan

[Olaf Hering]

On Thu, May 31, Olaf Hering wrote:

> I just did a successful installation of sles11sp2 guest on a
> xen-unstable host with changeset 25427:ad348c6575b8, and with the change
> below, and the second attempt I just started seems get through as well.
> 
> I'm sure I used this variant already two weeks ago, and the install
> still failed. Perhaps other changes made during the last two weeks make
> a difference.
> 
> I will also doublecheck how it goes without this change.

Without such a change an installation fails already in the disk
partitioning stage with IO errors in the guest.

With v3 of your patch installation works for me.

Olaf

Re: Xen 4.2 TODO / Release Plan

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 538 bytes --]

On Mon, 2012-05-14 at 11:26 +0100, Ian Campbell wrote:
>
>       * xl compatibility with xm:
>
 * `cpus=[2,3]` to select specific mapping vcpu0-->pcpu2, vcpu1-->pcpu3
    as xm does. (Dario Faggioli, patches posted and reviewed, will 
    repost)



Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.2 TODO / Release Plan

[Ian Jackson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4984 bytes --]

Ian Campbell writes ("[Xen-devel] Xen 4.2 TODO / Release Plan"):
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
...
> 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:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, I think this was actually DONE a while back and
>                 I missed it)

This is indeed committed.

>               * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>                 Interface needs an overhaul, related to
>                 locking/serialization over domain create (deferred to
>                 4.3). IanJ to add note about this interface being
>                 substandard but otherwise defer to 4.3.

I have yet to write such a note.

>               * libxl_*_path. Majority made internal, only configdir and
>                 lockdir remain public (used by xl). Good enough?

Yes.  We should perhaps add a note saying that the lockdir path
function should not be used by out-of-tree callers.

>               * Interfaces which may need to be async:
>                       * libxl_domain_suspend. Probably need to move
>                         xc_domain_save into a separate process, as per
>                         <20366.40183.410388.447630@mariner.uk.xensource.com>. Likely need to do the same for xc_domain_restore too. (IanJ).

I am working on this.

>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series, (DONE).

Yes.

>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally. (IanC, DONE)

Yes.

>                       * libxl_device_{disk,nic,vkb,add,pci}_add (and
>                         remove?). Roger Pau Monné fixes disk as part of
>                         hotplug script series and adds infrastructure
>                         which should make the others trivial. (Roger,
>                         WIP)

Right.

>                       * libxl_cdrom_insert. Should be easy once
>                         disk_{add,remove} done, IanJ to look at (or
>                         doing so?).

This isn't on my proximate todo list yet.

>                       * libxl_device_disk_local_{attach,detach}. Become
>                         internal as part of Stefano's domain 0 disk
>                         attach series (patches posted, another round
>                         required?)

I believe I am expecting a revised series from Stefano, yes.

>                       * libxl_fork -- IanJ's event series will remove
>                         all users of this. (DONE)

Yes.

>       * xl compatibility with xm:
>               * [BUG] cannot create an empty CD-ROM driver on HVM guest,
>                 reported by Fabio Fantoni in
>                 <4F9672DD.2080902@tiscali.it>

This needs my attention.

>               * does not automatically try to select a (set of) node(s)
>                 on which to create a VM and pin its vcpus there. (Dario
>                 Faggioli, patches posted)

This is still in progress somehow ?

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

Good.

>       * xl to refuse to run if xend is running, Roger Pau Monné (patch
>         posted, needs rebase)

Committed.

>       * Domain 0 block attach & general hotplug when using qdisk backend
>         (need to start qemu as necessary etc) (Stefano S, patches
>         posted, needs updates)

Is this not the same as the libxl_device_disk_local_{attach,detach}
series you mention above ?

>       * Improved Hotplug script support (Roger Pau Monné, patches
>         posted)

These are currently undergoing review/rework.

>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monné)

Right.

>       * xs.h -> xenstore.h. Should do this for 4.2 rather than have
>         distros carry their own patches. (Ian C, patch posted)

I will be applying this today I hope.

> tools, nice to have:
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, was waiting on libxl side of qemu upstream
>         save/restore, now unblocked)

Yes.

>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, new version of patch posted
>                 recently)

I think we are awaiting a reworked series from Goncalo.

>       * Directory usage in libxl (Bastian, as part of Debian packaging,
>         likely to defer to 4.3 unless there is some big problem with
>         packaging deviating from upstream)

I think this can wait.

Ian.


[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.2 TODO / Release Plan

[Ian Campbell]

On Mon, 2012-05-14 at 16:33 +0100, Ian Jackson wrote:
> >               * libxl_*_path. Majority made internal, only configdir and
> >                 lockdir remain public (used by xl). Good enough?
> 
> Yes.  We should perhaps add a note saying that the lockdir path
> function should not be used by out-of-tree callers.

Or move lockdir into xl, it's only actually used there.

So is config_dir_path now I look at it.

> >                       * libxl_cdrom_insert. Should be easy once
> >                         disk_{add,remove} done, IanJ to look at (or
> >                         doing so?).
> 
> This isn't on my proximate todo list yet.

OK.

> >               * does not automatically try to select a (set of) node(s)
> >                 on which to create a VM and pin its vcpus there. (Dario
> >                 Faggioli, patches posted)
> 
> This is still in progress somehow ?

RFC posted, awaiting another round IIRC.

> >       * Domain 0 block attach & general hotplug when using qdisk backend
> >         (need to start qemu as necessary etc) (Stefano S, patches
> >         posted, needs updates)
> 
> Is this not the same as the libxl_device_disk_local_{attach,detach}
> series you mention above ?

Yes it is.

The first entry was under "make them async if necessary", which noted
that this would be fixed by Stefano's series which was making them
internal, which is this second entry.

> >       * xl compatibility with xm:
> >               * xl support for autospawning vncviewer (vncviewer=1 or
> >                 otherwise) (Goncalo Gomes, new version of patch posted
> >                 recently)
> 
> I think we are awaiting a reworked series from Goncalo.

Yes.

> >       * Directory usage in libxl (Bastian, as part of Debian packaging,
> >         likely to defer to 4.3 unless there is some big problem with
> >         packaging deviating from upstream)
> 
> I think this can wait.

Agreed.

Ian.

Re: Xen 4.2 TODO / Release Plan

[Dario Faggioli]

On Mon, 2012-05-14 at 16:33 +0100, Ian Jackson wrote:
> >       * xl compatibility with xm:
> >               * [BUG] cannot create an empty CD-ROM driver on HVM guest,
> >                 reported by Fabio Fantoni in
> >                 <4F9672DD.2080902@tiscali.it>
> 
> This needs my attention.
> 
> >               * does not automatically try to select a (set of) node(s)
> >                 on which to create a VM and pin its vcpus there. (Dario
> >                 Faggioli, patches posted)
> 
> This is still in progress somehow ?
> 
It definitely is. I've it almost ready but got distracted by some other
stuff in the last days... I'll post something again asap.

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)