4.2 TODO / Release Status

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

4.2 TODO / Release Status

Ian Campbell-10
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.

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, patches posted)
              * 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
                        <[hidden email]>. Likely need to do the same for xc_domain_restore too. I'm not sure if IanJ is working (or planning to work on) this.
                      * libxl_domain_create_{new,restore} -- IanJ has
                        patches as part of event series.
                      * libxl_domain_core_dump. Can take a dummy ao_how
                        and remain synchronous internally. (IanC, patch
                        posted)
                      * libxl_device_{disk,nic,vkb,add}_add (and
                        remove?). Roger Pau Monné fixes disk as part of
                        hotplug script series and adds infrastructure
                        which should make the others trivial. (Roger
                        investigating)
                      * 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)
                      * libxl_device_pci_{add,remove}. Roger
                        investigating along with other add,remove
                        functions.
                      * libxl_xen_tmem_*. All functions are "fast" and
                        therefore no async needed. Exception is
                        tmem_destroy which Dan Magenheimer says is
                        obsolete and can just be removed. (Ian C, patch
                        to remove tmem_destroy included, DONE)
                      * libxl_fork -- IanJ's event series will remove
                        all users of this.
      * [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. (George Dunlap, in the absence of said onlooker)
      * xl compatibility with xm:
              * [BUG] cannot create an empty CD-ROM driver on HVM guest,
                reported by Fabio Fantoni in
                <[hidden email]>
              * [BUG] does not honour scheduler weight params, reported
                by Dieter Bloms in <[hidden email]>,
                Dieter's patch has been accepted. (DONE, However see
                next bug...)
              * [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". This is an issue with
                Dieter Bloms' patch to honour scheduler params.
              * does not automatically try to select a (set of)  node(s)
                on which to create a VM and pin its vcpus there. (Dario
                Faggioli)
      * 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)
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc) (Stefano S, patches
        posted)
      * file:// backend performance (DONE)
              * qemu-xen-traditional and upstream qemu-xen performance
                has been improved and is now satisfactory. (Hence this
                whole item is DONE)
              * Xen 4.2 will prefer blktap2 if a kernel module is
                available (e.g. older dom0 kernel or DKMS provided
                kernel module) and will fallback to qemu qdisk if no
                blktap2 is available.
              * There will be no userspace "blktap3" for Xen 4.2
      * Improved Hotplug script support (Roger Pau Monné, patches
        posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monné)

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

tools, nice to have:
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                patches sent)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini, qemu patches applied, waiting for libxl etc
                side which has been recently reposted)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, waiting on libxl side of qemu upstream save/restore)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=1 or
                otherwise) (Goncalo Gomes, new version of patch posted
                recently)
              * support for vif "rate" parameter (Mathieu Gagné, all now
                applied, DONE)

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



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Ian Campbell-10
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
>       * [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. (George Dunlap, in the absence of said onlooker)

I just tried this and it appeared to work, has it been sneakily fixed?



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

George Dunlap-4
On 08/05/12 11:32, Ian Campbell wrote:
> On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
>>        * [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. (George Dunlap, in the absence of said onlooker)
> I just tried this and it appeared to work, has it been sneakily fixed?
Seems to work for me too -- I do vaguely recall someone (perhaps
Goncalo?) volunteering to fix it.  At any rate, I'm happy taking it off
the list.  Thanks for checking.

  -George


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Ian Campbell-10
In reply to this post by Ian Campbell-10
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:

> 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

I think the critical path here is the libxl stable API stuff.

Of these I think the elements are IanJ's series to handle fork etc and
various other bits, followed by Roger's hotplug stuff (which depends on
IanJ's stuff).

I'm bit unsure which bits of the following list are done, in-progress
(part of a posted or unposted series) or yet to be started. Could you
guys have a quick look through and let me know?

Also, is it worth trying to find some other heads to take over some of
the smaller side, non-dependent issues to clear your path (IanJ in
particular)?
 

> 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, patches posted)
>               * 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
>                         <[hidden email]>. Likely need to do the same for xc_domain_restore too. I'm not sure if IanJ is working (or planning to work on) this.
>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series.
>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally. (IanC, patch
>                         posted)
>                       * libxl_device_{disk,nic,vkb,add}_add (and
>                         remove?). Roger Pau Monné fixes disk as part of
>                         hotplug script series and adds infrastructure
>                         which should make the others trivial. (Roger
>                         investigating)
>                       * 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)
>                       * libxl_device_pci_{add,remove}. Roger
>                         investigating along with other add,remove
>                         functions.
>                       * libxl_xen_tmem_*. All functions are "fast" and
>                         therefore no async needed. Exception is
>                         tmem_destroy which Dan Magenheimer says is
>                         obsolete and can just be removed. (Ian C, patch
>                         to remove tmem_destroy included, DONE)
>                       * libxl_fork -- IanJ's event series will remove
>                         all users of this.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Ian Campbell-10
In reply to this post by George Dunlap-4
On Tue, 2012-05-08 at 11:39 +0100, George Dunlap wrote:

> On 08/05/12 11:32, Ian Campbell wrote:
> > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
> >>        * [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. (George Dunlap, in the absence of said onlooker)
> > I just tried this and it appeared to work, has it been sneakily fixed?
> Seems to work for me too -- I do vaguely recall someone (perhaps
> Goncalo?) volunteering to fix it.  At any rate, I'm happy taking it off
> the list.  Thanks for checking.

Great, I'll mark it DONE next week.

Ian.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

sched params spurious error message (Was: Re: 4.2 TODO / Release Status)

Ian Campbell-10
In reply to this post by Ian Campbell-10
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:

>       * xl compatibility with xm:
> [...]
>               * [BUG] does not honour scheduler weight params, reported
>                 by Dieter Bloms in <[hidden email]>,
>                 Dieter's patch has been accepted. (DONE, However see
>                 next bug...)
>               * [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". This is an issue with
>                 Dieter Bloms' patch to honour scheduler params.

Is anyone looking into this?

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Volunteer wanted: xl and empty HVM CD ROM drives (Was: Re: 4.2 TODO / Release Status)

Ian Campbell-10
In reply to this post by Ian Campbell-10
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
> [...]      * xl compatibility with xm:
>               * [BUG] cannot create an empty CD-ROM driver on HVM guest,
>                 reported by Fabio Fantoni in
>                 <[hidden email]>

I don't think anyone is currently working on this. Any volunteers?

I think this should be a relatively easy thing, suitable for a beginner
(e..g someone who is interested in making a start at toolstack hacking.)

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)

Ian Campbell-10
In reply to this post by Ian Campbell-10
Where are we with the following?

I've not seen anything recently about PCI passthrough.

Is it still the case that save/restore is waiting on lib{c,l} patches
and Remus is waiting for those? What's the hold up there?

On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:

> tools, nice to have:
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, qemu patches applied, waiting for libxl etc
>                 side which has been recently reposted)
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, waiting on libxl side of qemu upstream save/restore)
>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, new version of patch posted
>                 recently)
>               * support for vif "rate" parameter (Mathieu Gagné, all now
>                 applied, DONE)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)

Dieter Bloms-2
In reply to this post by Ian Campbell-10
Hi,

On Tue, May 08, Ian Campbell wrote:

> On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
> >       * xl compatibility with xm:
> > [...]
> >               * [BUG] does not honour scheduler weight params, reported
> >                 by Dieter Bloms in <[hidden email]>,
> >                 Dieter's patch has been accepted. (DONE, However see
> >                 next bug...)
> >               * [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". This is an issue with
> >                 Dieter Bloms' patch to honour scheduler params.
>
> Is anyone looking into this?

I've made a little patch to set this value to 256 when it wasn't defined
in the configfile, but George Dunlap didn't like it (rightly).
I'm sorry, my skill is not enough to implement a reasonable solution for
this issue :(
Maybe we should revert my patch as long as there isn't a fix.


--
Best regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)

George Dunlap-4
On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms <[hidden email]> wrote:

>> >               * [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". This is an issue with
>> >                 Dieter Bloms' patch to honour scheduler params.
>>
>> Is anyone looking into this?
>
> I've made a little patch to set this value to 256 when it wasn't defined
> in the configfile, but George Dunlap didn't like it (rightly).
> I'm sorry, my skill is not enough to implement a reasonable solution for
> this issue :(
> Maybe we should revert my patch as long as there isn't a fix.

No, I think having the ability to set it is important.  You can mark
this "George will do it if no one else steps up". :-)

Thanks for your help, Dieter.

 -George

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)

Shriram Rajagopalan
In reply to this post by Ian Campbell-10
On 2012-05-08, at 5:52 AM, Ian Campbell <[hidden email]> wrote:

> Where are we with the following?
>
> I've not seen anything recently about PCI passthrough.
>
> Is it still the case that save/restore is waiting on lib{c,l} patches
> and Remus is waiting for those? What's the hold up there?

The last I remember, Stefano reposted the patches for the Nth time
but unfortunately forgot to add the acked-by from someone.

I stopped reposting my patches every time Stefano reposted his,
lest I spam the list.

I am just waiting for his patches to go in before I rebase/repost mine.

Shriram

>
> On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:
>> tools, nice to have:
>>      * Upstream qemu feature patches:
>>              * Upstream qemu PCI passthrough support (Anthony Perard,
>>                patches sent)
>>              * Upstream qemu save restore (Anthony Perard, Stefano
>>                Stabellini, qemu patches applied, waiting for libxl etc
>>                side which has been recently reposted)
>>      * Initial xl support for Remus (memory checkpoint, blackholing)
>>        (Shriram, waiting on libxl side of qemu upstream save/restore)
>>      * xl compatibility with xm:
>>              * xl support for autospawning vncviewer (vncviewer=1 or
>>                otherwise) (Goncalo Gomes, new version of patch posted
>>                recently)
>>              * support for vif "rate" parameter (Mathieu Gagné, all now
>>                applied, DONE)
>>
>> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> [hidden email]
>> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)

Ian Campbell-10
In reply to this post by George Dunlap-4
On Tue, 2012-05-08 at 13:35 +0100, George Dunlap wrote:

> On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms <[hidden email]> wrote:
> >> >               * [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". This is an issue with
> >> >                 Dieter Bloms' patch to honour scheduler params.
> >>
> >> Is anyone looking into this?
> >
> > I've made a little patch to set this value to 256 when it wasn't defined
> > in the configfile, but George Dunlap didn't like it (rightly).
> > I'm sorry, my skill is not enough to implement a reasonable solution for
> > this issue :(
> > Maybe we should revert my patch as long as there isn't a fix.
>
> No, I think having the ability to set it is important.  You can mark
> this "George will do it if no one else steps up". :-)

You've got yerself a deal ;-)

> Thanks for your help, Dieter.

Yes, thanks!

Ian.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Bastian Blank
In reply to this post by Ian Campbell-10
On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote:
> 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.

For the beginning, I have the following points:

* xs.h -> xenstore.h
* Directory usage in libxl
  - dumps in /var/xen: wtf?
  - user data files in /var/lib/xen:
    What are the guarantees given for this files?
  - /var/run/libxl for temporary files

Bastian

--
Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Ian Campbell-10
On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote:
> On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote:
> > 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.
>
> For the beginning, I have the following points:
>
> * xs.h -> xenstore.h

I think there was general agreement that this should be done for 4.2.

> * Directory usage in libxl
>   - dumps in /var/xen: wtf?

This is the same location as xend uses, so in that sense it is
compatible.

However I don't think this is somewhere that xl (nb: this is a property
of xl, not libxl) needs to slavishly follow what xend did.

What would the correct FHS location for these dumps be?

>   - user data files in /var/lib/xen:
>     What are the guarantees given for this files?

I suppose you are asking for /var/lib vs /var/run (or /run) reasons?

One of the keys by which you lookup this userdata is domid. Which means
that the lifetime of this data is bounded by the life of a domain. Which
means that it need not persist over reboot (which I think argues for
(/var)?/run)

I suppose the other interesting facet is allowable size. The description
of the interface doesn't have anything to say about size. Ian J -- any
thoughts?

>   - /var/run/libxl for temporary files

Are you suggesting that this is being wrongly used by libxl, or that
libxl should use this location for more things than it currently does?
Perhaps some stuff should instead be in /tmp or $TMPDIR?

Other than the xs.h naming issue I don't see anything here which I think
is a blocker for 4.2, I'd say they are mostly "nice to have".

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)

Stefano Stabellini-3
In reply to this post by Ian Campbell-10
On Tue, 8 May 2012, Ian Campbell wrote:
> Where are we with the following?
>
> I've not seen anything recently about PCI passthrough.

The last patch series that was sent is:

http://marc.info/?l=qemu-devel&m=133346733411606&w=2

it is still stuck waiting for reviews. Given that QEMU is in freeze for
the next release release now, I don't think anything is going to happen
in the next few weeks.
I could backport the patch series to the upstream QEMU tree that we use
with xen-unstable, but considering that we are in freeze ourselves and
that upstream QEMU is not used by default with HVM guests we
might as well wait for the beginning of the next release cycle.


> Is it still the case that save/restore is waiting on lib{c,l} patches
> and Remus is waiting for those? What's the hold up there?

The libxl save/restore patches haven't been applied yet.

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)

Ian Campbell-10
On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote:

> On Tue, 8 May 2012, Ian Campbell wrote:
> > Where are we with the following?
> >
> > I've not seen anything recently about PCI passthrough.
>
> The last patch series that was sent is:
>
> http://marc.info/?l=qemu-devel&m=133346733411606&w=2
>
> it is still stuck waiting for reviews. Given that QEMU is in freeze for
> the next release release now, I don't think anything is going to happen
> in the next few weeks.
> I could backport the patch series to the upstream QEMU tree that we use
> with xen-unstable, but considering that we are in freeze ourselves and
> that upstream QEMU is not used by default with HVM guests we
> might as well wait for the beginning of the next release cycle.

Thanks. I will mark these as "deferred to 4.3" and remove from the list.
If they do go into upstream we can revisit whether we backport.

> > Is it still the case that save/restore is waiting on lib{c,l} patches
> > and Remus is waiting for those? What's the hold up there?
>
> The libxl save/restore patches haven't been applied yet.

Ian J -- have you dropped these or are you waiting for something?

Ian.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)

Shriram Rajagopalan
On Tue, May 8, 2012 at 9:59 AM, Ian Campbell <[hidden email]> wrote:
On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote:
> On Tue, 8 May 2012, Ian Campbell wrote:
> > Where are we with the following?
> >
> > I've not seen anything recently about PCI passthrough.
>
> The last patch series that was sent is:
>
> http://marc.info/?l=qemu-devel&m=133346733411606&w=2
>
> it is still stuck waiting for reviews. Given that QEMU is in freeze for
> the next release release now, I don't think anything is going to happen
> in the next few weeks.
> I could backport the patch series to the upstream QEMU tree that we use
> with xen-unstable, but considering that we are in freeze ourselves and
> that upstream QEMU is not used by default with HVM guests we
> might as well wait for the beginning of the next release cycle.

Thanks. I will mark these as "deferred to 4.3" and remove from the list.
If they do go into upstream we can revisit whether we backport.

> > Is it still the case that save/restore is waiting on lib{c,l} patches
> > and Remus is waiting for those? What's the hold up there?
>
> The libxl save/restore patches haven't been applied yet.

Ian J -- have you dropped these or are you waiting for something?

 

 
Ian J, also note that the remus libxl patches may not apply cleanly after
applying stefano's patches (even these might require some re-basing),
given that a lot of patches that came in later (the event based stuff, Ian C's refactorings,etc)
went in.
If you could just let me know when they have been committed, I can certainly
rebase mine and post them.
 
thanks
shriram

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Bastian Blank
In reply to this post by Ian Campbell-10
On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote:
> On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote:
> > * Directory usage in libxl
> >   - dumps in /var/xen: wtf?
> However I don't think this is somewhere that xl (nb: this is a property
> of xl, not libxl) needs to slavishly follow what xend did.
> What would the correct FHS location for these dumps be?

Unsure. 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?
> I suppose you are asking for /var/lib vs /var/run (or /run) reasons?

Exactly.

> One of the keys by which you lookup this userdata is domid. Which means
> that the lifetime of this data is bounded by the life of a domain. Which
> means that it need not persist over reboot (which I think argues for
> (/var)?/run)

I don't think rebooting the control domain without rebooting Xen will
work right now. So /var/run is the correct location.

On further thoughts: Why not push them into xenstore?

> >   - /var/run/libxl for temporary files
> Are you suggesting that this is being wrongly used by libxl, or that
> libxl should use this location for more things than it currently does?
> Perhaps some stuff should instead be in /tmp or $TMPDIR?

$TMPDIR or the fallback /tmp is the correct location.

> Other than the xs.h naming issue I don't see anything here which I think
> is a blocker for 4.2, I'd say they are mostly "nice to have".

I'm just collecting changes for the Debian packages.

Bastian

--
There is a multi-legged creature crawling on your shoulder.
                -- Spock, "A Taste of Armageddon", stardate 3193.9

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Olaf Hering-2
In reply to this post by Ian Campbell-10
On Tue, May 08, Ian Campbell wrote:

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

Please consider "tools/configure: add options to pass EXTRA_CFLAGS"
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00537.html

Since qemu-upstream was imported, building tools with RPM_OPT_FLAGS will
not work anymore.

Olaf

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 4.2 TODO / Release Status

Ian Campbell-10
In reply to this post by Bastian Blank
On Tue, 2012-05-08 at 11:11 -0400, Bastian Blank wrote:

> On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote:
> > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote:
> > > * Directory usage in libxl
> > >   - dumps in /var/xen: wtf?
> > However I don't think this is somewhere that xl (nb: this is a property
> > of xl, not libxl) needs to slavishly follow what xend did.
> > What would the correct FHS location for these dumps be?
>
> Unsure. 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.

OK. Do you have that patch to hand?

> > >   - user data files in /var/lib/xen:
> > >     What are the guarantees given for this files?
> > I suppose you are asking for /var/lib vs /var/run (or /run) reasons?
>
> Exactly.

Do you have that patch to hand too?

> > One of the keys by which you lookup this userdata is domid. Which means
> > that the lifetime of this data is bounded by the life of a domain. Which
> > means that it need not persist over reboot (which I think argues for
> > (/var)?/run)
>
> I don't think rebooting the control domain without rebooting Xen will
> work right now. So /var/run is the correct location.

Right. (Can you guess my next question...)

Do you have that patch to hand too?

( ;-) )

> On further thoughts: Why not push them into xenstore?

AIUI the userdata facility is provided specifically for data which is
unsuitable for xenstore, due to size or whatever (XS has various limits,
to avoid abuse, which are relatively low).

> > >   - /var/run/libxl for temporary files
> > Are you suggesting that this is being wrongly used by libxl, or that
> > libxl should use this location for more things than it currently does?
> > Perhaps some stuff should instead be in /tmp or $TMPDIR?
>
> $TMPDIR or the fallback /tmp is the correct location.
>
> > Other than the xs.h naming issue I don't see anything here which I think
> > is a blocker for 4.2, I'd say they are mostly "nice to have".
>
> I'm just collecting changes for the Debian packages.

Sure. I guess you will send out those patches as and when you are happy
with them?

Cheers,
Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xen.org/xen-devel
12