4.2 TODO update

4.2 TODO update

[Ian Campbell]

This update covers two weeks since I was away last week.

As usual please ping me with any updates/corrections. There are several
things below which are in need of a volunteer to take care of them...

hypervisor, blockers:
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap, 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:
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                DONE)
              * Safe fork vs. fd handling hooks. This is an API
                addition, so maybe not required fro stable API, bit need
                to have for 4.2? (Ian J, patches posted)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.
      * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
      * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc)
      * file:// backend performance. qemu-xen-tradition's qdisk is quite
        slow & blktap2 not available in upstream kernels. Need to
        consider our options:
              * qemu-xen's qdisk is thought to be well performing but
                qemu-xen is not yet the default. Complexity arising from
                splitting qemu-for-qdisk out from qemu-for-dm and
                running N qemu's.
              * potentially fully userspace blktap could be ready for
                4.2
              * use /dev/loop+blkback. This requires loop driver AIO and
                O_DIRECT patches which are not (AFAIK) yet upstream.
              * Leverage XCP's blktap2 DKMS work.
              * Other ideas?

hypervisor, nice to have:
      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
        it DONE even?)

tools, nice to have:
      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? (Roger Pau Monné, patches posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monné)
      * Configure/control paging via xl/libxl (Olaf Herring, lots of
        discussion around interface)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                patches sent)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini, patches sent, waiting for upstream ack)
      * Nested-virtualisation (currently should be marked experimental,
        likely to release that way? Consider nested-svm separate to
        nested-vmx. Nested-svm is in better shape)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches posted, blocked behind qemu save restore
        patches)
      * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
        (Nobody AFAICT)
      * support for vif "rate" parameter (No one, AFAICT)



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

Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> [...] 
> tools, blockers:
> [...]
>       * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
> [...]
> hypervisor, nice to have:
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
>         it DONE even?)
> 
> tools, nice to have:
> [...]
>       * Configure/control paging via xl/libxl (Olaf Herring, lots of
>         discussion around interface)

Is this a reasonable summary of the state of the paging/sharing &
friends world for 4.2? Is there anything missing?

Ian.

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Olaf Hering]

On Mon, Mar 12, Ian Campbell wrote:

> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > [...] 
> > tools, blockers:
> > [...]
> >       * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
> > [...]
> > hypervisor, nice to have:
> >       * solid implementation of sharing/paging/mem-events (using work
> >         queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
> >         it DONE even?)

The last patch to use a waitqueue in __get_gfn_type_access() from Tim
works.  However, there are a few users who call __get_gfn_type_access
with the domain_lock held. This part needs to be addressed in some way.

> > tools, nice to have:
> > [...]
> >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
> >         discussion around interface)
> 
> Is this a reasonable summary of the state of the paging/sharing &
> friends world for 4.2? Is there anything missing?


There are indeed alot of ideas regarding the interface, and its
currently not clear to me if there is an agreement yet. Was there any
outcome where to proceed?

Olaf

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 13:04 +0000, Olaf Hering wrote:
> On Mon, Mar 12, Ian Campbell wrote:
> 
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > > [...] 
> > > tools, blockers:
> > > [...]
> > >       * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
> > > [...]
> > > hypervisor, nice to have:
> > >       * solid implementation of sharing/paging/mem-events (using work
> > >         queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
> > >         it DONE even?)
> 
> The last patch to use a waitqueue in __get_gfn_type_access() from Tim
> works.  However, there are a few users who call __get_gfn_type_access
> with the domain_lock held.

Thanks. 

>  This part needs to be addressed in some way.

This is happening?

> > > tools, nice to have:
> > > [...]
> > >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
> > >         discussion around interface)
> > 
> > Is this a reasonable summary of the state of the paging/sharing &
> > friends world for 4.2? Is there anything missing?
> 
> 
> There are indeed alot of ideas regarding the interface, and its
> currently not clear to me if there is an agreement yet. Was there any
> outcome where to proceed?

I've mostly swapped it out while I was away so I need to go back to the
thread and figure out where we got to. I don't think we had discussed
the libxl interface, only xl. I think the proposal Andres made sense in
this respect when he described it to me (although I've not read the mail
yet).

Ian.

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Olaf Hering]

On Mon, Mar 12, Ian Campbell wrote:

> On Mon, 2012-03-12 at 13:04 +0000, Olaf Hering wrote:
> > On Mon, Mar 12, Ian Campbell wrote:
> > 
> > > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > > > hypervisor, nice to have:
> > > >       * solid implementation of sharing/paging/mem-events (using work
> > > >         queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
> > > >         it DONE even?)
> > 
> > The last patch to use a waitqueue in __get_gfn_type_access() from Tim
> > works.  However, there are a few users who call __get_gfn_type_access
> > with the domain_lock held.
> 
> Thanks. 
> 
> >  This part needs to be addressed in some way.
> 
> This is happening?

To me its not clear what the domain_lock() protects:

Just a guest: XENMEM_remove_from_physmap should be ok with the gfn_lock
taken in guest_physmap_remove_page(), so the domain_lock() could be
removed there.

I'm not sure about the domain_lock in xenmem_add_to_physmap_once() and
emulate_privileged_op().


> > > > tools, nice to have:
> > > > [...]
> > > >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
> > > >         discussion around interface)
> > > 
> > > Is this a reasonable summary of the state of the paging/sharing &
> > > friends world for 4.2? Is there anything missing?
> > 
> > There are indeed alot of ideas regarding the interface, and its
> > currently not clear to me if there is an agreement yet. Was there any
> > outcome where to proceed?
> 
> I've mostly swapped it out while I was away so I need to go back to the
> thread and figure out where we got to. I don't think we had discussed
> the libxl interface, only xl. I think the proposal Andres made sense in
> this respect when he described it to me (although I've not read the mail
> yet).

So is this something we should work out for the 4.2 release?

If I understand it right, there should be a .cfg option
mem_policy=<string>, where string could be "paging" or "balloon".
In case of balloon the target value would be whats in use now
(memory+maxmem). In case of paging these values could be reused in the
same way, just that maxmem+memory would not create a PoD guest.
If mem_policy= is not given it will default to balloon to retain current
behaviour.


Olaf

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Tue, 2012-03-13 at 10:54 +0000, Olaf Hering wrote:
> On Mon, Mar 12, Ian Campbell wrote:
> > > > > tools, nice to have:
> > > > > [...]
> > > > >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
> > > > >         discussion around interface)
> > > > 
> > > > Is this a reasonable summary of the state of the paging/sharing &
> > > > friends world for 4.2? Is there anything missing?
> > > 
> > > There are indeed alot of ideas regarding the interface, and its
> > > currently not clear to me if there is an agreement yet. Was there any
> > > outcome where to proceed?
> > 
> > I've mostly swapped it out while I was away so I need to go back to the
> > thread and figure out where we got to. I don't think we had discussed
> > the libxl interface, only xl. I think the proposal Andres made sense in
> > this respect when he described it to me (although I've not read the mail
> > yet).
> 
> So is this something we should work out for the 4.2 release?

I think it was on the nice to have list which I think is an accurate
place.

> If I understand it right, there should be a .cfg option
> mem_policy=<string>, where string could be "paging" or "balloon".

The string names the "actor" which will implement the policy (so perhaps
the cfg option name should be "mem_actor="? Seems clumsy). So the
default for xl would be "xl". An existing alternative actor would be
"squeezed" which should cause the system to use XCP's squeezed (this
would require updates to squeezed to actually use these interfaces). You
can imagine that others might want to implement other more complex
actors in the future (e.g. which combine sharing, paging, and tmem in an
interesting way).

The "xl" actor should implement the "paging=auto" balloon, delay, then
page mechanism (or just ballooning for PV guests) we discussed
previously (I think most recent proposal was in
<1330078304.8557.157.camel@zakaz.uk.xensource.com>),
iff /local/domain/X/memory-policy/actor == "xl". We can ignore sharing
with this new scheme and leave it to whomever implements the sharing
memory policy actor.

I expect that the xl daemon would be the entity which actually
implements this actor for the guest which it is monitoring. We should
probably supply a helpful libxl event triggered when the policy
parameters (under /local/domain/X/memory-policy/) change.

I suppose there is also scope for an actor specific arbitrary string,
e.g. mem_policy_args or so.

I think that in the normal case we would not support mixing and matching
actors on a system, so in the case of xl I would expect to normally find
mem_policy in /etc/xen/xl.conf rather than in the guest configuration
file. It is reasonable for an actor implementation to consist either a
per-host daemon (like squeezed) or a per-domain daemon (like xl).

libxl_set_memory_target would be changed to set the
"/local/domain/X/memory-policy/target", this is used by "xl mem-set".

libxl should also expose methods to set the balloon and paging targets,
these would be used by the code in xl which implements the "xl" policy
described above.

> In case of balloon the target value would be whats in use now
> (memory+maxmem). In case of paging these values could be reused in the
> same way, just that maxmem+memory would not create a PoD guest.
> If mem_policy= is not given it will default to balloon to retain current
> behaviour.

I think the libxl default should be to immediately set the balloon
target. This would retain the historical behaviour for toolstacks which
don't say differently and would also work as expected for dom0 (which
may not have the necessary /local/domain/X/memory-policy/actor key).

The default set by xl should be "xl" or whatever is provided in the
config.

The other option for the default provided by libxl will be to do nothing
I don't think that is as helpful/useful as a default though.

There should probably be an option to set the actor to "none", meaning
that the toolstack is taking direct responsibility for this domains
memory targets. This would be used when "xl mem-paging-set domain
manual" was called allowing xl to implement the "xl mem-paging-set
domain N" in manual mode as described in
<1330078304.8557.157.camel@zakaz.uk.xensource.com>. Or maybe this
corresponds to using "xl-auto" and "xl-manual" as the policies?

Thoughts?

I suppose I ought to go back to
<1330078304.8557.157.camel@zakaz.uk.xensource.com> and update the
descriptions to account for this "actor" scheme and also flesh out the
underlying libxl interface (which we previously have ignored in that
discussion). Would that be useful?

Ian.

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Olaf Hering]

On Tue, Mar 13, Ian Campbell wrote:

> The string names the "actor" which will implement the policy (so perhaps
> the cfg option name should be "mem_actor="? Seems clumsy). So the
> default for xl would be "xl". An existing alternative actor would be
> "squeezed" which should cause the system to use XCP's squeezed (this
> would require updates to squeezed to actually use these interfaces). You
> can imagine that others might want to implement other more complex
> actors in the future (e.g. which combine sharing, paging, and tmem in an
> interesting way).

Ok, makes sense.

> The "xl" actor should implement the "paging=auto" balloon, delay, then
> page mechanism (or just ballooning for PV guests) we discussed
> previously (I think most recent proposal was in
> <1330078304.8557.157.camel@zakaz.uk.xensource.com>),
> iff /local/domain/X/memory-policy/actor == "xl". We can ignore sharing
> with this new scheme and leave it to whomever implements the sharing
> memory policy actor.

Yes.

> I think that in the normal case we would not support mixing and matching
> actors on a system, so in the case of xl I would expect to normally find
> mem_policy in /etc/xen/xl.conf rather than in the guest configuration
> file. It is reasonable for an actor implementation to consist either a
> per-host daemon (like squeezed) or a per-domain daemon (like xl).

Sounds good.

> libxl should also expose methods to set the balloon and paging targets,
> these would be used by the code in xl which implements the "xl" policy
> described above.

Yes.


> I think the libxl default should be to immediately set the balloon
> target. This would retain the historical behaviour for toolstacks which
> don't say differently and would also work as expected for dom0 (which
> may not have the necessary /local/domain/X/memory-policy/actor key).
> 
> The default set by xl should be "xl" or whatever is provided in the
> config.
> 
> The other option for the default provided by libxl will be to do nothing
> I don't think that is as helpful/useful as a default though.

I think that a default of "none" would change behaviour. So having "xl"
as default which makes the guests behave like before will remove
surprises during upgrade to 4.2.

> There should probably be an option to set the actor to "none", meaning
> that the toolstack is taking direct responsibility for this domains
> memory targets. This would be used when "xl mem-paging-set domain
> manual" was called allowing xl to implement the "xl mem-paging-set
> domain N" in manual mode as described in
> <1330078304.8557.157.camel@zakaz.uk.xensource.com>. Or maybe this
> corresponds to using "xl-auto" and "xl-manual" as the policies?

I'm not sure about the manual mode. If one calls mem-paging-set or
mem-balloon-set to change the target value, why not do it right away?


> Thoughts?

Thanks for the writeup, Ian!

> I suppose I ought to go back to
> <1330078304.8557.157.camel@zakaz.uk.xensource.com> and update the
> descriptions to account for this "actor" scheme and also flesh out the
> underlying libxl interface (which we previously have ignored in that
> discussion). Would that be useful?

Yes, an updated description/proposal is useful IMHO.

Olaf
> 

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Tue, 2012-03-13 at 13:36 +0000, Olaf Hering wrote:
> On Tue, Mar 13, Ian Campbell wrote:

> > I think the libxl default should be to immediately set the balloon
> > target. This would retain the historical behaviour for toolstacks which
> > don't say differently and would also work as expected for dom0 (which
> > may not have the necessary /local/domain/X/memory-policy/actor key).
> > 
> > The default set by xl should be "xl" or whatever is provided in the
> > config.
> > 
> > The other option for the default provided by libxl will be to do nothing
> > I don't think that is as helpful/useful as a default though.
> 
> I think that a default of "none" would change behaviour. So having "xl"
> as default which makes the guests behave like before will remove
> surprises during upgrade to 4.2.

The default for _libxl_ cannot be "xl", since the toolstack may not be
xl.

I think my first proposal for libxl's default makes sense, that is that
libxl should set things directly unless
libxl_domain_set_memory_policy_actor (or whatever the function ends up
being called) has been called.

> > There should probably be an option to set the actor to "none", meaning
> > that the toolstack is taking direct responsibility for this domains
> > memory targets. This would be used when "xl mem-paging-set domain
> > manual" was called allowing xl to implement the "xl mem-paging-set
> > domain N" in manual mode as described in
> > <1330078304.8557.157.camel@zakaz.uk.xensource.com>. Or maybe this
> > corresponds to using "xl-auto" and "xl-manual" as the policies?
> 
> I'm not sure about the manual mode. If one calls mem-paging-set or
> mem-balloon-set to change the target value, why not do it right away?

You would also need to change the actor to something which would not
conflict with such a manual change.

> > Thoughts?
> 
> Thanks for the writeup, Ian!
> 
> > I suppose I ought to go back to
> > <1330078304.8557.157.camel@zakaz.uk.xensource.com> and update the
> > descriptions to account for this "actor" scheme and also flesh out the
> > underlying libxl interface (which we previously have ignored in that
> > discussion). Would that be useful?
> 
> Yes, an updated description/proposal is useful IMHO.

I'll try and get to it in the next couple of days.

Ian.

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Olaf Hering]

On Tue, Mar 13, Ian Campbell wrote:

> The default for _libxl_ cannot be "xl", since the toolstack may not be
> xl.

Oh, yes you are right. I mixed libxl and xl.

> > I'm not sure about the manual mode. If one calls mem-paging-set or
> > mem-balloon-set to change the target value, why not do it right away?
> 
> You would also need to change the actor to something which would not
> conflict with such a manual change.

Yes, that should be done. Good point.


Olaf

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Andres Lagar-Cavilla]

>> There should probably be an option to set the actor to "none", meaning
>> that the toolstack is taking direct responsibility for this domains
>> memory targets. This would be used when "xl mem-paging-set domain
>> manual" was called allowing xl to implement the "xl mem-paging-set
>> domain N" in manual mode as described in
>> <1330078304.8557.157.camel@zakaz.uk.xensource.com>. Or maybe this
>> corresponds to using "xl-auto" and "xl-manual" as the policies?
>
> I'm not sure about the manual mode. If one calls mem-paging-set or
> mem-balloon-set to change the target value, why not do it right away?
>
>
>> Thoughts?
>
> Thanks for the writeup, Ian!

Ditto, thanks for sorting this out
Andres
>
>> I suppose I ought to go back to
>> <1330078304.8557.157.camel@zakaz.uk.xensource.com> and update the
>> descriptions to account for this "actor" scheme and also flesh out the
>> underlying libxl interface (which we previously have ignored in that
>> discussion). Would that be useful?
>
> Yes, an updated description/proposal is useful IMHO.
>
> Olaf
>>
>

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Andres Lagar-Cavilla]

> On Mon, Mar 12, Ian Campbell wrote:
>
>> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> > [...]
>> > tools, blockers:
>> > [...]
>> >       * Correct paging/sharing tools buffer mlocking (Tim, Andres,
>> DONE)
>> > [...]
>> > hypervisor, nice to have:
>> >       * solid implementation of sharing/paging/mem-events (using work
>> >         queues) (Tim Deegan, Olaf Herring et al -- is this happening?
>> is
>> >         it DONE even?)
>
> The last patch to use a waitqueue in __get_gfn_type_access() from Tim
> works.  However, there are a few users who call __get_gfn_type_access
> with the domain_lock held. This part needs to be addressed in some way.

So, Tim posted a 6-patch series
http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html

The first four are fixes that should go in. I acked them pending some
nits. Tim, I can re-package them and submit them myself if that would save
you some time.

But, the core patch in that series, #5, breaks pv-on-hvm windows 7. So I'm
afraid it's a solid nack from my end for the time being. In fact, it would
break not just windows but any other os, should they start invoking XENMEM
hypercalls (and who knows what else is still lurking!) more liberally.

Apart from that I have 4 hypervisor patches that deal with some
correctness corner cases, so I'll float them out there in short order.

There is work going on with AMD to get all these features working on their
processors. Let's hope for a breakthrough, but if it doesn't happen, let's
keep going forward.

I cannot really think of anything else on the hypervisor side.
Andres

>
>> > tools, nice to have:
>> > [...]
>> >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
>> >         discussion around interface)
>>
>> Is this a reasonable summary of the state of the paging/sharing &
>> friends world for 4.2? Is there anything missing?
>
>
> There are indeed alot of ideas regarding the interface, and its
> currently not clear to me if there is an agreement yet. Was there any
> outcome where to proceed?
>
> Olaf
>

Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Tim Deegan]

At 08:05 -0700 on 12 Mar (1331539511), Andres Lagar-Cavilla wrote:
> So, Tim posted a 6-patch series
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html
> 
> The first four are fixes that should go in. I acked them pending some
> nits. Tim, I can re-package them and submit them myself if that would save
> you some time.
> 
> But, the core patch in that series, #5, breaks pv-on-hvm windows 7. So I'm
> afraid it's a solid nack from my end for the time being. In fact, it would
> break not just windows but any other os, should they start invoking XENMEM
> hypercalls (and who knows what else is still lurking!) more liberally.

Agreed.  I'll repost them this week, broken into the preliminary fixes
and the wait-queue change itself (which I think has to wait until after
4.2 now). 

> Apart from that I have 4 hypervisor patches that deal with some
> correctness corner cases, so I'll float them out there in short order.
> 
> There is work going on with AMD to get all these features working on their
> processors. Let's hope for a breakthrough, but if it doesn't happen, let's
> keep going forward.

Yep - Can AMD support go in as a separate "nice to have" on the list?

Tim.

Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> There are several things below which are in need of a volunteer to take care of them...

Specifically:

> tools, blockers:
> [...]
>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>       * Domain 0 block attach & general hotplug when using qdisk backend
>         (need to start qemu as necessary etc)
> tools, nice to have:
> [...]
>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>         (Nobody AFAICT)
>       * support for vif "rate" parameter (No one, AFAICT)

#1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
a newcomer who is interested in getting started with toolstack level
stuff.

#2 is a bit more involved.

Any takers?

Ian.

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Mathieu Gagné]

On 3/12/12 8:22 AM, Ian Campbell wrote:
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> There are several things below which are in need of a volunteer to take care of them...
>
> Specifically:
>
>> tools, nice to have:
>>        * support for vif "rate" parameter (No one, AFAICT)
>

I'm working on a patch to add support for vif rate limiting in libxl.

I don't have much experience with C and my knowledge is limited. 
(although I develop in other languages)

At this moment, I only have a "proof of concept" with a main function so 
I can play and do tests to verify the parsing/results. 
(bytes_per_interval,interval_usecs)

I would have a couple of questions about how to integrate the 
feature/code within libxl/xl.

The rate syntax requires relatively complex parsing which would require 
at least 3 new functions which could all be combined in one if required. 
(parse_vif_rate, parse_vif_rate_bytes_per_sec and 
parse_vif_rate_interval_usecs)

Where should those functions be added? xl_cmdimpl.c?

What should be the names of the new struct members of libxl_device_nic? 
I same some "suggestions" in the previous rejected patch [1]. Are those 
names good? Should they be closer to the concept of "rate" instead of "qos"?

Also, should more information be provided to the user about the rate 
syntax? rate=<rate> isn't that useful.

Thanks!

[1] http://lists.xen.org/archives/html/xen-devel/2011-03/msg01963.html


-- 
Mathieu

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 16:00 +0000, Mathieu Gagné wrote:
> On 3/12/12 8:22 AM, Ian Campbell wrote:
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> There are several things below which are in need of a volunteer to take care of them...
> >
> > Specifically:
> >
> >> tools, nice to have:
> >>        * support for vif "rate" parameter (No one, AFAICT)
> >
> 
> I'm working on a patch to add support for vif rate limiting in libxl.
> 
> I don't have much experience with C and my knowledge is limited. 
> (although I develop in other languages)
> 
> At this moment, I only have a "proof of concept" with a main function so 
> I can play and do tests to verify the parsing/results. 
> (bytes_per_interval,interval_usecs)
> 
> I would have a couple of questions about how to integrate the 
> feature/code within libxl/xl.
> 
> The rate syntax

Are you copying the xm/xend syntax here?

>  requires relatively complex parsing which would require 
> at least 3 new functions which could all be combined in one if required. 
> (parse_vif_rate, parse_vif_rate_bytes_per_sec

Aren't these the same function but with handling for units?

> and parse_vif_rate_interval_usecs)

I think externally a single function to parse a rate and initialise the
relevant fields of libxl_device_nic is the way to go. Perhaps internal
to the implementation of that there might be additional helpers etc.

> Where should those functions be added? xl_cmdimpl.c?

How about libxlu_vif.c (new file, similar to e.g. libxlu_disk.c)? libxlu
is a library of stuff which is part of xl which might be useful to other
toolstacks -- code for parsing vif rate's seems to fall into that
category, much like parsing disk configure strings does.

> What should be the names of the new struct members of libxl_device_nic? 
> I same some "suggestions" in the previous rejected patch [1]. Are those 
> names good? Should they be closer to the concept of "rate" instead of "qos"?

I suppose it depends what their actual semantics are. Something like
max_<unit>_per_<thing> and <thing>_per_second/<thing>_<time-unit> should
be ok I guess?

> Also, should more information be provided to the user about the rate 
> syntax? rate=<rate> isn't that useful.

The new option/syntax should be fully documented in
docs/misc/xl-network-configuration.markdown which is referenced by
docs/man/xl.cfg.pod.5.

> Thanks!

Thanks for doing this -- looking forward to the patches!

Ian.



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

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Lin Ming]

On Mon, Mar 12, 2012 at 8:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> There are several things below which are in need of a volunteer to take care of them...

Hi,

I'm a newcomer.
Could you share more details about the requirements?

>
> Specifically:
>
>> tools, blockers:
>> [...]
>>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)

Are these parameters to be added for some xl subcommand?
What are they used for?

>>       * Domain 0 block attach & general hotplug when using qdisk backend
>>         (need to start qemu as necessary etc)
>> tools, nice to have:
>> [...]
>>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)

Could you tell more detail?

>>         (Nobody AFAICT)
>>       * support for vif "rate" parameter (No one, AFAICT)

It's a kernel module parameter(xen-4.1.2/tools/vnet/vnet-module), right?

>
> #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> a newcomer who is interested in getting started with toolstack level
> stuff.
>
> #2 is a bit more involved.
>
> Any takers?

I'm a new comer and I'd like to get start from here.

Thanks,
Lin Ming

>
> Ian.

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 16:00 +0000, Lin Ming wrote:
> On Mon, Mar 12, 2012 at 8:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> There are several things below which are in need of a volunteer to take care of them...
> 
> Hi,
> 
> I'm a newcomer.
> Could you share more details about the requirements?
> 
> >
> > Specifically:
> >
> >> tools, blockers:
> >> [...]
> >>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
> 
> Are these parameters to be added for some xl subcommand?
> What are they used for?

These should be options which can be specified in the domain
configuration file for HVM guests. They control the offset of the
guest-visible emulated RTC from the host time -- IOW they control the
time which the guest sees.

These options are supported by xm/xend and need to be implemented for xl
in a compatible way. This means exposing suitable fields in the libxl
API (probably as fields in libxl_domain_build_info) and arranging for xl
to parse the configuration file options.

Some amount of reverse engineering of xend will be required to figure
out what the actual meaning of those options in order to implement in a
compatible way but AFAIK rtc_timeoffset is the offset between host time
and guest time. localtime I think means to specify whether the emulted
RTC appears as UTC or is offset by the host.

Having figured out the meaning libxl needs to arrange to call
xc_domain_set_time_offset with the right values.

I think much of the related xend code is in
tools/python/xen/xend/image.py but you might need to grep about a bit.

> >>       * Domain 0 block attach & general hotplug when using qdisk backend
> >>         (need to start qemu as necessary etc)
> >> tools, nice to have:
> >> [...]
> >>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> 
> Could you tell more detail?

xm/xend supports a configuration file option "vncviewer=1" which causes
xend to automatically spawn vncviewer with the correct options (e.g.
port number) when doing "xm create". We would like the same for "xl
create".

As well as a config file option I think a command line option to "xl
create" would also be useful, similar to '-c' which automatically
connects to the virtual serial console. e.g '-V' perhaps.

I guess we would want a libxl interface similar to
libxl_primary_console_exec and xl support to call it when appropriate.
overall it should look a lot like the console spawning stuff.

> >>         (Nobody AFAICT)
> >>       * support for vif "rate" parameter (No one, AFAICT)
> 
> It's a kernel module parameter(xen-4.1.2/tools/vnet/vnet-module), right?

I don't think so, this is network rate limiting as implemented by
netback. Mathieu Gagné is already taking care of this so I won't go into
any further detail (which is lucky, because I'm fuzzy about the details
myself).

> 
> >
> > #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> > a newcomer who is interested in getting started with toolstack level
> > stuff.
> >
> > #2 is a bit more involved.
> >
> > Any takers?
> 
> I'm a new comer and I'd like to get start from here.

Please do let us know if you decide to take on one of the tasks.

Ian.



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

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Lin Ming]

On Tue, Mar 13, 2012 at 12:40 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-03-12 at 16:00 +0000, Lin Ming wrote:
>> On Mon, Mar 12, 2012 at 8:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> >> There are several things below which are in need of a volunteer to take care of them...
>>
>> Hi,
>>
>> I'm a newcomer.
>> Could you share more details about the requirements?
>>
>> >
>> > Specifically:
>> >
>> >> tools, blockers:
>> >> [...]
>> >>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>>
>> Are these parameters to be added for some xl subcommand?
>> What are they used for?
>
> These should be options which can be specified in the domain
> configuration file for HVM guests. They control the offset of the
> guest-visible emulated RTC from the host time -- IOW they control the
> time which the guest sees.
>
> These options are supported by xm/xend and need to be implemented for xl
> in a compatible way. This means exposing suitable fields in the libxl
> API (probably as fields in libxl_domain_build_info) and arranging for xl
> to parse the configuration file options.
>
> Some amount of reverse engineering of xend will be required to figure
> out what the actual meaning of those options in order to implement in a
> compatible way but AFAIK rtc_timeoffset is the offset between host time
> and guest time. localtime I think means to specify whether the emulted
> RTC appears as UTC or is offset by the host.
>
> Having figured out the meaning libxl needs to arrange to call
> xc_domain_set_time_offset with the right values.
>
> I think much of the related xend code is in
> tools/python/xen/xend/image.py but you might need to grep about a bit.
>
>> >>       * Domain 0 block attach & general hotplug when using qdisk backend
>> >>         (need to start qemu as necessary etc)
>> >> tools, nice to have:
>> >> [...]
>> >>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>>
>> Could you tell more detail?
>
> xm/xend supports a configuration file option "vncviewer=1" which causes
> xend to automatically spawn vncviewer with the correct options (e.g.
> port number) when doing "xm create". We would like the same for "xl
> create".
>
> As well as a config file option I think a command line option to "xl
> create" would also be useful, similar to '-c' which automatically
> connects to the virtual serial console. e.g '-V' perhaps.
>
> I guess we would want a libxl interface similar to
> libxl_primary_console_exec and xl support to call it when appropriate.
> overall it should look a lot like the console spawning stuff.
>
>> >>         (Nobody AFAICT)
>> >>       * support for vif "rate" parameter (No one, AFAICT)
>>
>> It's a kernel module parameter(xen-4.1.2/tools/vnet/vnet-module), right?
>
> I don't think so, this is network rate limiting as implemented by
> netback. Mathieu Gagné is already taking care of this so I won't go into
> any further detail (which is lucky, because I'm fuzzy about the details
> myself).
>
>>
>> >
>> > #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
>> > a newcomer who is interested in getting started with toolstack level
>> > stuff.
>> >
>> > #2 is a bit more involved.
>> >
>> > Any takers?
>>
>> I'm a new comer and I'd like to get start from here.
>
> Please do let us know if you decide to take on one of the tasks.

Thanks for the detail explanation.
I take #1.

Do we have a deadline for the patch?
I'll need time to ramp up the code.

Thanks,
Lin Ming

>
> Ian.

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 16:59 +0000, Lin Ming wrote:
> On Tue, Mar 13, 2012 at 12:40 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-03-12 at 16:00 +0000, Lin Ming wrote:
> >> On Mon, Mar 12, 2012 at 8:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> >> There are several things below which are in need of a volunteer to take care of them...
> >>
> >> Hi,
> >>
> >> I'm a newcomer.
> >> Could you share more details about the requirements?
> >>
> >> >
> >> > Specifically:
> >> >
> >> >> tools, blockers:
> >> >> [...]
> >> >>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
> >>
> >> Are these parameters to be added for some xl subcommand?
> >> What are they used for?
> >
> > These should be options which can be specified in the domain
> > configuration file for HVM guests. They control the offset of the
> > guest-visible emulated RTC from the host time -- IOW they control the
> > time which the guest sees.
> >
> > These options are supported by xm/xend and need to be implemented for xl
> > in a compatible way. This means exposing suitable fields in the libxl
> > API (probably as fields in libxl_domain_build_info) and arranging for xl
> > to parse the configuration file options.
> >
> > Some amount of reverse engineering of xend will be required to figure
> > out what the actual meaning of those options in order to implement in a
> > compatible way but AFAIK rtc_timeoffset is the offset between host time
> > and guest time. localtime I think means to specify whether the emulted
> > RTC appears as UTC or is offset by the host.
> >
> > Having figured out the meaning libxl needs to arrange to call
> > xc_domain_set_time_offset with the right values.
> >
> > I think much of the related xend code is in
> > tools/python/xen/xend/image.py but you might need to grep about a bit.
> >
> >> >>       * Domain 0 block attach & general hotplug when using qdisk backend
> >> >>         (need to start qemu as necessary etc)
> >> >> tools, nice to have:
> >> >> [...]
> >> >>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> >>
> >> Could you tell more detail?
> >
> > xm/xend supports a configuration file option "vncviewer=1" which causes
> > xend to automatically spawn vncviewer with the correct options (e.g.
> > port number) when doing "xm create". We would like the same for "xl
> > create".
> >
> > As well as a config file option I think a command line option to "xl
> > create" would also be useful, similar to '-c' which automatically
> > connects to the virtual serial console. e.g '-V' perhaps.
> >
> > I guess we would want a libxl interface similar to
> > libxl_primary_console_exec and xl support to call it when appropriate.
> > overall it should look a lot like the console spawning stuff.
> >
> >> >>         (Nobody AFAICT)
> >> >>       * support for vif "rate" parameter (No one, AFAICT)
> >>
> >> It's a kernel module parameter(xen-4.1.2/tools/vnet/vnet-module), right?
> >
> > I don't think so, this is network rate limiting as implemented by
> > netback. Mathieu Gagné is already taking care of this so I won't go into
> > any further detail (which is lucky, because I'm fuzzy about the details
> > myself).
> >
> >>
> >> >
> >> > #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> >> > a newcomer who is interested in getting started with toolstack level
> >> > stuff.
> >> >
> >> > #2 is a bit more involved.
> >> >
> >> > Any takers?
> >>
> >> I'm a new comer and I'd like to get start from here.
> >
> > Please do let us know if you decide to take on one of the tasks.
> 
> Thanks for the detail explanation.
> I take #1.

Great!

> Do we have a deadline for the patch?

See the "Xen 4.2 release plan" email which I sent to the list this
morning for a broad outline

Since these are in the "nice to have" category and are pretty small and
self contained I think that even if they miss 4.2.0 they can go in to
unstable in the 4.3 dev cycle and be obvious candidates for backporting
to 4.2.1.

Ian.

> I'll need time to ramp up the code.
> 
> Thanks,
> Lin Ming
> 
> >
> > Ian.



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

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Goncalo Gomes]

On Mon, 12 Mar 2012, Ian Campbell wrote:

> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > There are several things below which are in need of a volunteer to take care of them...
> 
> Specifically:
> 
> > tools, blockers:
> > [...]
> >       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
> >       * Domain 0 block attach & general hotplug when using qdisk backend
> >         (need to start qemu as necessary etc)
> > tools, nice to have:
> > [...]
> >       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> >         (Nobody AFAICT)
> >       * support for vif "rate" parameter (No one, AFAICT)
> 
> #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> a newcomer who is interested in getting started with toolstack level
> stuff.
> 
> #2 is a bit more involved.
> 
> Any takers?

I'd be keen to work on 

> >       * Domain 0 block attach & general hotplug when using qdisk backend
> >         (need to start qemu as necessary etc)

Cheers,
Goncalo

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

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 18:18 +0000, Goncalo Gomes wrote:
> On Mon, 12 Mar 2012, Ian Campbell wrote:
> 
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > > There are several things below which are in need of a volunteer to take care of them...
> > 
> > Specifically:
> > 
> > > tools, blockers:
> > > [...]
> > >       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
> > >       * Domain 0 block attach & general hotplug when using qdisk backend
> > >         (need to start qemu as necessary etc)
> > > tools, nice to have:
> > > [...]
> > >       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> > >         (Nobody AFAICT)
> > >       * support for vif "rate" parameter (No one, AFAICT)
> > 
> > #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> > a newcomer who is interested in getting started with toolstack level
> > stuff.
> > 
> > #2 is a bit more involved.
> > 
> > Any takers?
> 
> I'd be keen to work on 
> 
> > >       * Domain 0 block attach & general hotplug when using qdisk backend
> > >         (need to start qemu as necessary etc)

I'm afraid Stefano has picked this one up.

I don't think anyone has picked up:
> * xl support for autospawning vncviewer (vncviewer=1 or otherwise)

I described it in a bit more detail in a mail to Lin Ming earlier in the
thread.

Ian.

Re: Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Goncalo Gomes]

On Tue, 13 Mar 2012, Ian Campbell wrote:

> On Mon, 2012-03-12 at 18:18 +0000, Goncalo Gomes wrote:
>
> I don't think anyone has picked up:
> > * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> 
> I described it in a bit more detail in a mail to Lin Ming earlier in the
> thread.

I've just read the email on it and seeing as there isn't any 
confirmation from Lin Ming, please add my name and I'll be happy to 
take it.

Goncalo
 
> Ian.
> 

Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
[4.2 TODO list]

So the list is getting to be quite manageable. I think it is time we
started discussing plans for a 4.2, timelines etc.

As a starting point for discussion how about the following:

After next week's TODO list update (19 March) I start taking a much
harder line on what goes on the TODO list, especially the blocker list.
A strong case will have to be made for why any particular addition is
critical to Xen 4.2. This means that posting additions this week means
you will have a much greater chance of that item making it onto the list
for 4.2!

We then continue to focus on reducing the TODO list with a view to doing
a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
the "TODO list freeze").

At that point we become strict about not taking new features which are
not already on the TODO list, becoming increasingly strict WRT
nice-to-have vs blocker.

Aim to have -rc0 mid to late April, continuing weekly "Until Its
Ready(tm)", expecting the release itself to land in May or June.

Any thoughts? Too Aggressive? Too Pessimistic?

Ian.

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Keir Fraser]

On 12/03/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> [4.2 TODO list]
> 
> So the list is getting to be quite manageable. I think it is time we
> started discussing plans for a 4.2, timelines etc.
> 
> As a starting point for discussion how about the following:
> 
> After next week's TODO list update (19 March) I start taking a much
> harder line on what goes on the TODO list, especially the blocker list.
> A strong case will have to be made for why any particular addition is
> critical to Xen 4.2. This means that posting additions this week means
> you will have a much greater chance of that item making it onto the list
> for 4.2!
> 
> We then continue to focus on reducing the TODO list with a view to doing
> a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> the "TODO list freeze").
> 
> At that point we become strict about not taking new features which are
> not already on the TODO list, becoming increasingly strict WRT
> nice-to-have vs blocker.
> 
> Aim to have -rc0 mid to late April, continuing weekly "Until Its
> Ready(tm)", expecting the release itself to land in May or June.
> 
> Any thoughts? Too Aggressive? Too Pessimistic?

Sounds about right.

 -- Keir

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

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 13:45 +0000, Keir Fraser wrote:
> On 12/03/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > [4.2 TODO list]
> > 
> > So the list is getting to be quite manageable. I think it is time we
> > started discussing plans for a 4.2, timelines etc.
> > 
> > As a starting point for discussion how about the following:
> > 
> > After next week's TODO list update (19 March) I start taking a much
> > harder line on what goes on the TODO list, especially the blocker list.
> > A strong case will have to be made for why any particular addition is
> > critical to Xen 4.2. This means that posting additions this week means
> > you will have a much greater chance of that item making it onto the list
> > for 4.2!
> > 
> > We then continue to focus on reducing the TODO list with a view to doing
> > a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> > the "TODO list freeze").
> > 
> > At that point we become strict about not taking new features which are
> > not already on the TODO list, becoming increasingly strict WRT
> > nice-to-have vs blocker.
> > 
> > Aim to have -rc0 mid to late April, continuing weekly "Until Its
> > Ready(tm)", expecting the release itself to land in May or June.
> > 
> > Any thoughts? Too Aggressive? Too Pessimistic?
> 
> Sounds about right.

Thanks. So in the absence of any objections lets call this The Plan.

Ian.

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Sander Eikelenboom]

Hello Ian,

Monday, March 12, 2012, 2:37:35 PM, you wrote:

> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> [4.2 TODO list]

> So the list is getting to be quite manageable. I think it is time we
> started discussing plans for a 4.2, timelines etc.

> As a starting point for discussion how about the following:

> After next week's TODO list update (19 March) I start taking a much
> harder line on what goes on the TODO list, especially the blocker list.
> A strong case will have to be made for why any particular addition is
> critical to Xen 4.2. This means that posting additions this week means
> you will have a much greater chance of that item making it onto the list
> for 4.2!

> We then continue to focus on reducing the TODO list with a view to doing
> a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> the "TODO list freeze").

> At that point we become strict about not taking new features which are
> not already on the TODO list, becoming increasingly strict WRT
> nice-to-have vs blocker.

> Aim to have -rc0 mid to late April, continuing weekly "Until Its
> Ready(tm)", expecting the release itself to land in May or June.

> Any thoughts? Too Aggressive? Too Pessimistic?

> Ian.

I think there could be quite some fallout when users start testing the RC's (announce them well on xen-users ?), since there a quite some important changes (xl instead of xm) that don't have had such a wide spread testing yet.
I haven't tested xen-unstable myself since i'm a bit on a time constrain right now and some major changes are still in progress, but i'm planning on switching when the rc's are there.

--
Sander

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 14:12 +0000, Sander Eikelenboom wrote:
> Hello Ian,
> 
> Monday, March 12, 2012, 2:37:35 PM, you wrote:
> 
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > [4.2 TODO list]
> 
> > So the list is getting to be quite manageable. I think it is time we
> > started discussing plans for a 4.2, timelines etc.
> 
> > As a starting point for discussion how about the following:
> 
> > After next week's TODO list update (19 March) I start taking a much
> > harder line on what goes on the TODO list, especially the blocker list.
> > A strong case will have to be made for why any particular addition is
> > critical to Xen 4.2. This means that posting additions this week means
> > you will have a much greater chance of that item making it onto the list
> > for 4.2!
> 
> > We then continue to focus on reducing the TODO list with a view to doing
> > a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> > the "TODO list freeze").
> 
> > At that point we become strict about not taking new features which are
> > not already on the TODO list, becoming increasingly strict WRT
> > nice-to-have vs blocker.
> 
> > Aim to have -rc0 mid to late April, continuing weekly "Until Its
> > Ready(tm)", expecting the release itself to land in May or June.
> 
> > Any thoughts? Too Aggressive? Too Pessimistic?
> 
> > Ian.
> 
> I think there could be quite some fallout when users start testing the
> RC's (announce them well on xen-users ?), since there a quite some
> important changes (xl instead of xm) that don't have had such a wide
> spread testing yet.

Right, I think this is where the "Until Its Ready" bit comes in ;-0

> I haven't tested xen-unstable myself since i'm a bit on a time
> constrain right now and some major changes are still in progress, but
> i'm planning on switching when the rc's are there.

Great!

Ian.

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ross Philipson]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Monday, March 12, 2012 9:38 AM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Xen 4.2 release plan (Was: Re: 4.2 TODO update)
> 
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> [4.2 TODO list]
> 
> So the list is getting to be quite manageable. I think it is time we
> started discussing plans for a 4.2, timelines etc.
> 
> As a starting point for discussion how about the following:
> 
> After next week's TODO list update (19 March) I start taking a much
> harder line on what goes on the TODO list, especially the blocker list.
> A strong case will have to be made for why any particular addition is
> critical to Xen 4.2. This means that posting additions this week means
> you will have a much greater chance of that item making it onto the list
> for 4.2!
> 
> We then continue to focus on reducing the TODO list with a view to doing
> a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> the "TODO list freeze").
> 
> At that point we become strict about not taking new features which are
> not already on the TODO list, becoming increasingly strict WRT nice-to-
> have vs blocker.
> 
> Aim to have -rc0 mid to late April, continuing weekly "Until Its
> Ready(tm)", expecting the release itself to land in May or June.
> 
> Any thoughts? Too Aggressive? Too Pessimistic?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

I am still working on a patch set for the BIOS module pass-through. I did not receive any responses to my RFC so I just started putting it together. I am working at getting the rest of it done today and spending tomorrow testing. Is it going to be too late for this to be considered?

Thanks
Ross

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ian Campbell]

On Tue, 2012-03-13 at 13:43 +0000, Ross Philipson wrote:
[...]
> > We then continue to focus on reducing the TODO list with a view to doing
> > a feature freeze on, lets say, 2 April (3 weeks from today, 2 weeks from
> > the "TODO list freeze").
> > [...]
> 
> I am still working on a patch set for the BIOS module pass-through. I
> did not receive any responses to my RFC so I just started putting it
> together. I am working at getting the rest of it done today and
> spending tomorrow testing. Is it going to be too late for this to be
> considered?

Not at all, my proposed date for a feature freeze was 2 April which is
weeks away.

Ian.

Re: Xen 4.2 release plan (Was: Re: 4.2 TODO update)

[Ross Philipson]

Super thanks. I just wanted to be clear. I should be able to post the series this week (barring any serious hurdles which I do not anticipate).

Ross

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, March 13, 2012 9:54 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Xen 4.2 release plan (Was: Re: 4.2 TODO update)
> 
> On Tue, 2012-03-13 at 13:43 +0000, Ross Philipson wrote:
> [...]
> > > We then continue to focus on reducing the TODO list with a view to
> > > doing a feature freeze on, lets say, 2 April (3 weeks from today, 2
> > > weeks from the "TODO list freeze").
> > > [...]
> >
> > I am still working on a patch set for the BIOS module pass-through. I
> > did not receive any responses to my RFC so I just started putting it
> > together. I am working at getting the rest of it done today and
> > spending tomorrow testing. Is it going to be too late for this to be
> > considered?
> 
> Not at all, my proposed date for a feature freeze was 2 April which is
> weeks away.
> 
> Ian.
> 

Re: 4.2 TODO update

[Ian Campbell]

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> tools, nice to have:
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? (Roger Pau Monné, patches posted)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monné)

Any opinions on whether this, and in particular the block script bits,
should be blockers for 4.2?

I don't use block-script functionality myself so I'm not sure how
critical it is.

I guess there is always the workaround of doing whatever the script
would do outside of xl which is why I think (IIRC) I initially put it
under nice to have.

Opinions?

Ian.


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

Re: 4.2 TODO update

[Jan Beulich]

>>> On 12.03.12 at 14:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> tools, nice to have:
>>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>>         didn't put this under stable API above) but still good to have
>>         for 4.2? (Roger Pau Monné, patches posted)
>>       * Block script support -- follows on from hotplug script (Roger
>>         Pau Monné)
> 
> Any opinions on whether this, and in particular the block script bits,
> should be blockers for 4.2?
> 
> I don't use block-script functionality myself so I'm not sure how
> critical it is.
> 
> I guess there is always the workaround of doing whatever the script
> would do outside of xl which is why I think (IIRC) I initially put it
> under nice to have.
> 
> Opinions?

If it's this feature that you referred to when discussing the "xl
block-attach 0 ..." shortcomings (including the blkback-over-loop
that's currently unavailable with xl), then count this as a "+1"
for this being a blocker - if we want 4.2 to push forward the
deprecation status of xend, then (known) regressions like this
should get eliminated.

Jan

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

Re: 4.2 TODO update

[Ian Campbell]

On Mon, 2012-03-12 at 13:51 +0000, Jan Beulich wrote:
> >>> On 12.03.12 at 14:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> tools, nice to have:
> >>       * Hotplug script stuff -- internal to libxl (I think, therefore I
> >>         didn't put this under stable API above) but still good to have
> >>         for 4.2? (Roger Pau Monné, patches posted)
> >>       * Block script support -- follows on from hotplug script (Roger
> >>         Pau Monné)
> > 
> > Any opinions on whether this, and in particular the block script bits,
> > should be blockers for 4.2?
> > 
> > I don't use block-script functionality myself so I'm not sure how
> > critical it is.
> > 
> > I guess there is always the workaround of doing whatever the script
> > would do outside of xl which is why I think (IIRC) I initially put it
> > under nice to have.
> > 
> > Opinions?
> 
> If it's this feature that you referred to when discussing the "xl
> block-attach 0 ..." shortcomings (including the blkback-over-loop
> that's currently unavailable with xl), then count this as a "+1"
> for this being a blocker - if we want 4.2 to push forward the
> deprecation status of xend, then (known) regressions like this
> should get eliminated.

I actually included the specific use case of block-attach vs qdisk on
the TODO in its own right and separately the handling of file:// too --
it turns out that loopback may not be the best answer (see Joseph
Glanville's posts about loop and AIO/O_DIRECT) so block script may not
actually be all that helpful there.

Ian.


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

Re: 4.2 TODO update

[Roger Pau Monné]

2012/3/12 Ian Campbell <Ian.Campbell@citrix.com>:
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
>> tools, nice to have:
>>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>>         didn't put this under stable API above) but still good to have
>>         for 4.2? (Roger Pau Monné, patches posted)
>>       * Block script support -- follows on from hotplug script (Roger
>>         Pau Monné)
>
> Any opinions on whether this, and in particular the block script bits,
> should be blockers for 4.2?
>
> I don't use block-script functionality myself so I'm not sure how
> critical it is.
>
> I guess there is always the workaround of doing whatever the script
> would do outside of xl which is why I think (IIRC) I initially put it
> under nice to have.
>
> Opinions?

I would really like to be able to send the updated driver-domain
series (using Ian Jackson new event interface), but I'm not sure if I
will be able to do so until the next week, sorry.

> Ian.
>

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

Re: 4.2 TODO update

[Stefano Stabellini]

On Mon, 12 Mar 2012, Ian Campbell wrote:
> This update covers two weeks since I was away last week.
> 
> As usual please ping me with any updates/corrections. There are several
> things below which are in need of a volunteer to take care of them...
> 
> hypervisor, blockers:
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap, 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:
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 DONE)
>               * Safe fork vs. fd handling hooks. This is an API
>                 addition, so maybe not required fro stable API, bit need
>                 to have for 4.2? (Ian J, patches posted)
>       * xl feature parity with xend wrt driver domain support (George
>         Dunlap)
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>       * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>       * Domain 0 block attach & general hotplug when using qdisk backend
>         (need to start qemu as necessary etc)

I should be able to look into this

>       * file:// backend performance. qemu-xen-tradition's qdisk is quite
>         slow & blktap2 not available in upstream kernels. Need to
>         consider our options:
>               * qemu-xen's qdisk is thought to be well performing but
>                 qemu-xen is not yet the default. Complexity arising from
>                 splitting qemu-for-qdisk out from qemu-for-dm and
>                 running N qemu's.
>               * potentially fully userspace blktap could be ready for
>                 4.2
>               * use /dev/loop+blkback. This requires loop driver AIO and
>                 O_DIRECT patches which are not (AFAIK) yet upstream.
>               * Leverage XCP's blktap2 DKMS work.
>               * Other ideas?

Considering how long these patches have been outstanding (years), it
might be wise to design a solution that does not require them.

In particular I think we should either go with userblktap or qdisk.
Qdisk could be a nice fallback, not too hard to code, if we don't
get userblktap in time.

Re: 4.2 TODO update

[Ian Campbell]

On Mon, 2012-03-12 at 16:01 +0000, Stefano Stabellini wrote:
> On Mon, 12 Mar 2012, Ian Campbell wrote:
> >>       * Domain 0 block attach & general hotplug when using qdisk backend
> >         (need to start qemu as necessary etc)
> 
> I should be able to look into this

Thanks!

Ian

Re: 4.2 TODO update

[George Dunlap]

On Mon, Mar 12, 2012 at 12:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> This update covers two weeks since I was away last week.
>
> As usual please ping me with any updates/corrections. There are several
> things below which are in need of a volunteer to take care of them...
>
> hypervisor, blockers:
>      * domctls / sysctls set up to modify scheduler parameters, like
>        the credit1 timeslice and schedule rate. (George Dunlap, DONE)

I recently discovered a set of patches updating the PoD code in the
XenServer patchqueue which I was meant to have upstreamed but never
actually got to.  Can I add this to the "blockers" list?  It involves
changes based on some experimentation; and while I think it may be a
few days worth of work to port (with all the p2m reorganization done
after the 4.1 release), but it should be a relatively known quantity.

>
> 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:
>              * add libxl_defbool and generally try and arrange that
>                memset(foo,0,...) requests the defaults (Ian Campbell,
>                DONE)
>              * Safe fork vs. fd handling hooks. This is an API
>                addition, so maybe not required fro stable API, bit need
>                to have for 4.2? (Ian J, patches posted)
>      * xl feature parity with xend wrt driver domain support (George
>        Dunlap)
>      * More formally deprecate xm/xend. Manpage patches already in
>        tree. Needs release noting and communication around -rc1 to
>        remind people to test xl.
>      * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
>      * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>      * Domain 0 block attach & general hotplug when using qdisk backend
>        (need to start qemu as necessary etc)
>      * file:// backend performance. qemu-xen-tradition's qdisk is quite
>        slow & blktap2 not available in upstream kernels. Need to
>        consider our options:
>              * qemu-xen's qdisk is thought to be well performing but
>                qemu-xen is not yet the default. Complexity arising from
>                splitting qemu-for-qdisk out from qemu-for-dm and
>                running N qemu's.
>              * potentially fully userspace blktap could be ready for
>                4.2
>              * use /dev/loop+blkback. This requires loop driver AIO and
>                O_DIRECT patches which are not (AFAIK) yet upstream.
>              * Leverage XCP's blktap2 DKMS work.
>              * Other ideas?
>
> hypervisor, nice to have:
>      * solid implementation of sharing/paging/mem-events (using work
>        queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
>        it DONE even?)
>
> tools, nice to have:
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? (Roger Pau Monné, patches posted)
>      * Block script support -- follows on from hotplug script (Roger
>        Pau Monné)
>      * Configure/control paging via xl/libxl (Olaf Herring, lots of
>        discussion around interface)
>      * Upstream qemu feature patches:
>              * Upstream qemu PCI passthrough support (Anthony Perard,
>                patches sent)
>              * Upstream qemu save restore (Anthony Perard, Stefano
>                Stabellini, patches sent, waiting for upstream ack)
>      * Nested-virtualisation (currently should be marked experimental,
>        likely to release that way? Consider nested-svm separate to
>        nested-vmx. Nested-svm is in better shape)
>      * Initial xl support for Remus (memory checkpoint, blackholing)
>        (Shriram, patches posted, blocked behind qemu save restore
>        patches)
>      * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>        (Nobody AFAICT)
>      * support for vif "rate" parameter (No one, AFAICT)
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: 4.2 TODO update

[Ian Campbell]

On Mon, 2012-03-12 at 16:36 +0000, George Dunlap wrote:
> On Mon, Mar 12, 2012 at 12:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > This update covers two weeks since I was away last week.
> >
> > As usual please ping me with any updates/corrections. There are several
> > things below which are in need of a volunteer to take care of them...
> >
> > hypervisor, blockers:
> >      * domctls / sysctls set up to modify scheduler parameters, like
> >        the credit1 timeslice and schedule rate. (George Dunlap, DONE)
> 
> I recently discovered a set of patches updating the PoD code in the
> XenServer patchqueue which I was meant to have upstreamed but never
> actually got to.  Can I add this to the "blockers" list?

If we've been living without them are they really blockers? Adding them
to the nice to have list seems like a no brainer but a few words on why
they are blockers could easily upgrade my assessment ;-)

Ian.

Re: 4.2 TODO update

[George Dunlap]

On Mon, Mar 12, 2012 at 4:42 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-03-12 at 16:36 +0000, George Dunlap wrote:
>> On Mon, Mar 12, 2012 at 12:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > This update covers two weeks since I was away last week.
>> >
>> > As usual please ping me with any updates/corrections. There are several
>> > things below which are in need of a volunteer to take care of them...
>> >
>> > hypervisor, blockers:
>> >      * domctls / sysctls set up to modify scheduler parameters, like
>> >        the credit1 timeslice and schedule rate. (George Dunlap, DONE)
>>
>> I recently discovered a set of patches updating the PoD code in the
>> XenServer patchqueue which I was meant to have upstreamed but never
>> actually got to.  Can I add this to the "blockers" list?
>
> If we've been living without them are they really blockers? Adding them
> to the nice to have list seems like a no brainer but a few words on why
> they are blockers could easily upgrade my assessment ;-)

As you wish; I think it is the case that at the moment they're just
for performance, and they're just for booting a VM anyway.  But it's
certainly *my* goal to get them out before 4.2. :-)

 -George

Nested SVM (was: Re: 4.2 TODO update)

[Christoph Egger]

On 03/12/12 13:11, Ian Campbell wrote:
>        * Nested-virtualisation (currently should be marked experimental,
>          likely to release that way? Consider nested-svm separate to
>          nested-vmx. Nested-svm is in better shape)

I tested the following scenarios:

- Linux on Xen on Xen
- NetBSD on Xen on Xen
- KVM (+ KVM-guest) on Xen
- KVM (+ KVM-guest) on Xen on Xen (yeah, l3 guest works!)
- Windows 7 (both 32bit and 64bit) on Xen on Xen
- Win7 XP mode on Windows 7 (both 32bit and 64bit) on Xen
- Hyper-V (64bit) on Xen
- VMware ESX (64bit) on Xen

Issues:
- Hyper-V SMP not tested, only UP
- Win7 XP mode often quits with BSOD, but when it boots
   playing Solitair makes fun :-)
- L2 guest screen doesn't refresh in graphical mode
   (VGA text mode works),
   workaround: dis- and re-establish the VNC connection,
   between two VNC reconnects you can work like with your
   monitor powered off

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: Nested SVM (was: Re: 4.2 TODO update)

[Ian Campbell]

On Tue, 2012-03-13 at 11:40 +0000, Christoph Egger wrote:
> On 03/12/12 13:11, Ian Campbell wrote:
> >        * Nested-virtualisation (currently should be marked experimental,
> >          likely to release that way? Consider nested-svm separate to
> >          nested-vmx. Nested-svm is in better shape)
> 
> I tested the following scenarios:
> 
> - Linux on Xen on Xen
> - NetBSD on Xen on Xen
> - KVM (+ KVM-guest) on Xen
> - KVM (+ KVM-guest) on Xen on Xen (yeah, l3 guest works!)
> - Windows 7 (both 32bit and 64bit) on Xen on Xen
> - Win7 XP mode on Windows 7 (both 32bit and 64bit) on Xen
> - Hyper-V (64bit) on Xen
> - VMware ESX (64bit) on Xen

Wow, that's far more combinations than I expected.

I wonder where we can document this, is there a nested-HVM page on the
wiki perhaps?

> Issues:
> - Hyper-V SMP not tested, only UP
> - Win7 XP mode often quits with BSOD, 

Hrm, this one sounds quite important? I expect Win7 XP mode is the
primary real world use case for Nested-HVM?

> but when it boots playing Solitair makes fun :-)

;-)

> - L2 guest screen doesn't refresh in graphical mode
>    (VGA text mode works),
>    workaround: dis- and re-establish the VNC connection,
>    between two VNC reconnects you can work like with your
>    monitor powered off

Uh, that also sounds pretty critical. Does it also effect the Win7 XP
mode usecase?

Between those two issues I think removing the experimental tag sounds
premature?

Ian.

Re: Nested SVM

[Christoph Egger]

On 03/13/12 12:56, Ian Campbell wrote:
> On Tue, 2012-03-13 at 11:40 +0000, Christoph Egger wrote:
>> On 03/12/12 13:11, Ian Campbell wrote:
>>>         * Nested-virtualisation (currently should be marked experimental,
>>>           likely to release that way? Consider nested-svm separate to
>>>           nested-vmx. Nested-svm is in better shape)
>>
>> I tested the following scenarios:
>>
>> - Linux on Xen on Xen
>> - NetBSD on Xen on Xen
>> - KVM (+ KVM-guest) on Xen
>> - KVM (+ KVM-guest) on Xen on Xen (yeah, l3 guest works!)
>> - Windows 7 (both 32bit and 64bit) on Xen on Xen
>> - Win7 XP mode on Windows 7 (both 32bit and 64bit) on Xen
>> - Hyper-V (64bit) on Xen
>> - VMware ESX (64bit) on Xen
>
> Wow, that's far more combinations than I expected.
>
> I wonder where we can document this, is there a nested-HVM page on the
> wiki perhaps?
>
>> Issues:
>> - Hyper-V SMP not tested, only UP
>> - Win7 XP mode often quits with BSOD,
>
> Hrm, this one sounds quite important? I expect Win7 XP mode is the
> primary real world use case for Nested-HVM?

yes, but I have no idea what might be wrong.

>> but when it boots playing Solitair makes fun :-)
>
> ;-)

Playing Solitair gives a good impression on the end-user feeling
in how fast it response. It is also a good test case if interrupts
come in fast enough. If that is not the case a double click is
interpreted as two single clicks.

Playing Solitair in Win7 XP mode runs even faster than in Win7
thus makes more fun to play in Win7 XP mode.

>> - L2 guest screen doesn't refresh in graphical mode
>>     (VGA text mode works),
>>     workaround: dis- and re-establish the VNC connection,
>>     between two VNC reconnects you can work like with your
>>     monitor powered off
>
> Uh, that also sounds pretty critical. Does it also effect the Win7 XP
> mode usecase?

No, because in the Win7 XP mode usecase the graphic output is done by
the L1 guest (Windows 7) and that works. This problem only occurs when
the L2 guest runs in graphic mode.

I think, this issue is neither AMD nor Intel specific.
I think, this has something to do with the non-buffered io mode.
IIRC, VGA text mode uses a buffered io mode.

> Between those two issues I think removing the experimental tag sounds
> premature?

Yes.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

libxl stable API (Re: 4.2 TODO update)

[Ian Campbell]

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> [...] 
> 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:

So now would be a good time for potential users of libxl in 4.2 onwards
to do a quick sanity check of the interfaces such that any omissions can
be added to the 4.2 list.

Now is also a good time to decide on the policy and mechanisms which we
will use to make life easy for our downstreams (some of whom I have
CC'd).

The goal and default assumption should obviously be that a downstream
which builds against libxl from 4.2 will continue to build (and work!)
against future versions of libxl without source modification.

In order to help us achieve this we can define some interfaces /
mechanisms now which will make everyone's lives easier in the future. I
propose that downstreams who want to be exposed to a particular API
should be required to #define LIBXL_API_VERSION before including
libxl.h. This will allow libxl.h to introduce the necessary compat/shim
layer. e.g. if they want the 4.2.0 interface they must:
	#define LIBXL_API_VERSION 0x040200

Assuming that 4.3.0 eventually releases with an identical API then users
would be expected to continue to use 0x040200 (i.e. we wouldn't
explicitly duplicate up the #ifdef's for compatible releases) but if in
4.4.0 changes are required then users could either continue to use
0x040200 (and expect libxl.h to provide suitable impedance matching to
make that work) or switch to 0x040400 and make the necessary source
level changes. Lack of LIBXL_API_VERSION would be taken to mean "the
latest". Specifying an unknown LIBXL_API_VERSION would result in #error
(e.g. in the above example 0x040300 and 0x123456 would both be an
error).

We should try especially hard to avoid changing the API during a stable
series, i.e. it should be unusual for the last byte to be non-zero.

If there is broad agreement with this scheme I will write up a patch to
add it to some documentation / header somewhere.

Do we need to define a horizon for how far we are willing to support
this level of compatibility? A new major release seems like the obvious
watershed -- i.e. at Xen 5.0.0 we may decide to drop support for
LIBXL_API_VERSION 0x04xxxx and earlier (although we don't have to).

Much as I hate to admit it I expect there will eventually/inevitably be
changes which cannot be papered over with this scheme. In order to make
it possible for downstreams to support the use of a single code base
across such changes I suggest that we always add a #define
LIBXL_HAVE_foo_interface for any such change.

The assumption should be that the barrier for backporting to a stable
branch will be very high for any change of this type.

Lastly we also to decide what we want to do about ABI (as opposed to
API) compatibility. Obviously if we change the ABI then we should change
the SONAME, but is this something we want to commit to avoiding? i.e.
should it be possible to build a downstream against libxl.so.2.0 (the
current libxl soname) from 4.2 and expect that dropping in libxl.so.2.0
from 4.3 will Just Work against the new hypervisor interfaces? Or do we
expect that 4.3 will provide libxl.so.2.1 and that the same downstream
source can be built twice? (e.g. with the correct one selected via some
plugin mechanism). Obviously avoiding ABI changes is a lot harder and
I'm not sure if that is something we are able to commit to at this stage
(and I'm not sure how good we would be at it even if we did try and make
that commitment).

>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 DONE)
>               * Safe fork vs. fd handling hooks. This is an API
>                 addition, so maybe not required fro stable API, bit need
>                 to have for 4.2? (Ian J, patches posted)

Ian.

libxl stable API (Re: 4.2 TODO update)

[Ian Jackson]

Ian Campbell writes ("[Xen-devel] libxl stable API (Re:  4.2 TODO update)"):
> Lastly we also to decide what we want to do about ABI (as opposed to
> API) compatibility. Obviously if we change the ABI then we should change
> the SONAME, but is this something we want to commit to avoiding? i.e.
> should it be possible to build a downstream against libxl.so.2.0 (the
> current libxl soname) from 4.2 and expect that dropping in libxl.so.2.0
> >from 4.3 will Just Work against the new hypervisor interfaces? Or do we
> expect that 4.3 will provide libxl.so.2.1 and that the same downstream
> source can be built twice? (e.g. with the correct one selected via some
> plugin mechanism). Obviously avoiding ABI changes is a lot harder and
> I'm not sure if that is something we are able to commit to at this stage
> (and I'm not sure how good we would be at it even if we did try and make
> that commitment).

I agree with most of what you say.

I don't think we can commit to not making ABI changes.  It is thus an
unfortunate fact that the whole stack, from libxl caller on down to
the hypervisor, will have to change together when the version of Xen
is updated.

> >               * Safe fork vs. fd handling hooks. This is an API
> >                 addition, so maybe not required fro stable API, bit need
> >                 to have for 4.2? (Ian J, patches posted)

I think this is important to have.  It will imply changes to quite a
few ordinary api functions.

Ian.

Re: libxl stable API (Re: 4.2 TODO update)

[Ian Campbell]

On Wed, 2012-03-14 at 11:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] libxl stable API (Re:  4.2 TODO update)"):
> > Lastly we also to decide what we want to do about ABI (as opposed to
> > API) compatibility. Obviously if we change the ABI then we should change
> > the SONAME, but is this something we want to commit to avoiding? i.e.
> > should it be possible to build a downstream against libxl.so.2.0 (the
> > current libxl soname) from 4.2 and expect that dropping in libxl.so.2.0
> > >from 4.3 will Just Work against the new hypervisor interfaces? Or do we
> > expect that 4.3 will provide libxl.so.2.1 and that the same downstream
> > source can be built twice? (e.g. with the correct one selected via some
> > plugin mechanism). Obviously avoiding ABI changes is a lot harder and
> > I'm not sure if that is something we are able to commit to at this stage
> > (and I'm not sure how good we would be at it even if we did try and make
> > that commitment).
> 
> I agree with most of what you say.

Thanks. I shall add "agree & document compatibility guarantees +
associated technical measures" to the TODO list.

> I don't think we can commit to not making ABI changes.  It is thus an
> unfortunate fact that the whole stack, from libxl caller on down to
> the hypervisor, will have to change together when the version of Xen
> is updated.

Right. We can strive to make this a straight rebuild with no source
changes (somewhat akin to a binNMU in Debian-speak).

> 
> > >               * Safe fork vs. fd handling hooks. This is an API
> > >                 addition, so maybe not required fro stable API, bit need
> > >                 to have for 4.2? (Ian J, patches posted)
> 
> I think this is important to have.  It will imply changes to quite a
> few ordinary api functions.

Thanks, I will update the commentary accordingly in the next iteration.

Ian.

Re: 4.2 TODO update

[Dario Faggioli]

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

On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> This update covers two weeks since I was away last week.
> 
Hi,

I think the below should be considered too, and I'm proposing it as a
(tools) blocker, as I really think it affects API stability.

I can take care of it, provided we have some preliminary
design-discussion. :-D
 
> 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:
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 DONE)
>               * Safe fork vs. fd handling hooks. This is an API
>                 addition, so maybe not required fro stable API, bit need
>                 to have for 4.2? (Ian J, patches posted)
>
  * locking/serialization, e.g., for domain creation. As of now, 
    nothing is provided for this purpose, and downstream toolstacks have
    to put their own mechanisms in place. E.g., xl uses a fcntl() lock  
    around the whole process of domain creation. It should OTOH be 
    libxl job to offer a set of hooks --properly placed within the
    domain creation process-- for the downstreams to fill with the
    proper callbacks. (Dario Faggioli)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


[-- 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: 4.2 TODO update

[Ian Campbell]

On Wed, 2012-03-14 at 16:48 +0000, Dario Faggioli wrote:
> On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> > This update covers two weeks since I was away last week.
> > 
> Hi,
> 
> I think the below should be considered too, and I'm proposing it as a
> (tools) blocker, as I really think it affects API stability.

Sure.

> I can take care of it, provided we have some preliminary
> design-discussion. :-D

A good starting point for discussion would be a proposed patch to
libxl.h with associated inline documentation.

>  
> > 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:
> >               * add libxl_defbool and generally try and arrange that
> >                 memset(foo,0,...) requests the defaults (Ian Campbell,
> >                 DONE)
> >               * Safe fork vs. fd handling hooks. This is an API
> >                 addition, so maybe not required fro stable API, bit need
> >                 to have for 4.2? (Ian J, patches posted)
> >
>   * locking/serialization, e.g., for domain creation. As of now, 
>     nothing is provided for this purpose, and downstream toolstacks have
>     to put their own mechanisms in place. E.g., xl uses a fcntl() lock  
>     around the whole process of domain creation. It should OTOH be 
>     libxl job to offer a set of hooks --properly placed within the
>     domain creation process-- for the downstreams to fill with the
>     proper callbacks. (Dario Faggioli)
> 
> Thanks and Regards,
> Dario
>