Xen 4.3 development update CODE FREEZE HAS_BEGUN

Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

This information will be mirrored on the Xen 4.3 Roadmap wiki page:
 http://wiki.xen.org/wiki/Xen_Roadmap/4.3

At this point, code will begin freezing.

This means that every patch will need an exception to be accepted.  The
bar for acceptance will be relatively low this week, but will continue
to raise until the May 6th code freeze.

The key goals we're focusing on now, in order, are as follows:
 1. Have a bug-free 4.3 release
 2. Have an awesome 4.3 release
 3. Have a 4.3 release that happens on schedule (ready by June 15th)

So my goal right now is to ensure, to the best of my ability, that:
 1. No new bugs are introduced that will not be discovered before the
 release
 2. If no code is added, then either:
  - it does case the release to slip
  - if it causes the release to slip, it was worth the cost.

If you are a maintainer or committer, please help me in evaluating new
patches according to these criteria.  (Bug fixes are fine of course.)

If you are submitting patches, please consider these criteria before
submitting; and if you think you want to submit it anyway, consider
making a brief case for acceptance.

The most important thing in making a case is to answer the question,
"If there are bugs in this patch, will they be discovered before the
June 15h release?"  The second most important thing is to consider the
cost/benefit analysis of bugs that are found: what is the risk of
introducing a bug which will delay the release, vs the benefit it will
have in making the release better?

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature freeze: 25 March 2013
* Code freezing point: 15 April 2013 <== We are here
* First RC: 6 May 2013
* Release: 17 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  Each new feature will be
considered on a case-by-case basis; but the general rule will be as
follows:

Last updated: 16 April 2013

= Feature tracking =

Below is a list of features we're tracking for this release. Please
respond to this mail with any updates to the status.

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you're working on you'd like tracked, please
respond, and I will add it to the list.

NB: Several of the items on this list are from external projects:
linux, qemu, and libvirt.  These are not part of the Xen tree, but are
directly related to our users' experience (e.g., work in Linux or
qemu) or to integration with other important projects (e.g., libvirt
bindings).  Since all of these are part of the Xen community work, and
comes from the same pool of labor, it makes sense to track the
progress here, even though they won't explicitly be released as part
of 4.3.

Meanings of prognoses:
- Excellent: It would be very unlikely for this not to be finished in time.
- Good: Everything is on track, and is likely to make it.
- Fair: A pretty good chance of making it, but not as certain
- Poor: Likely not to make it unless intervention is made
- Not for 4.3: Self-explanatory

== Completed ==

* Serial console improvements
  -EHCI debug port

* Default to QEMU upstream (partial)
 - pci pass-thru (external)
 - enable dirtybit tracking during migration (external)
 - xl cd-{insert,eject} (external)

* CPUID-based idle (don't rely on ACPI info f/ dom0)

* Persistent grants for blk (external)
 - Linux
 - qemu

* Allow XSM to override IS_PRIV checks in the hypervisor

* Scalability: 16TiB of RAM

* xl QXL Spice support

== Bugs ==

* xl, compat mode, and older kernels
  owner: ?
  Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
  xend do not work when started with xl.  The following work-around seems to
  work:
    xl create -p lightning.cfg
    xenstore-write /local/domain/$(xl domid
lightning)/device/vbd/51713/protocol x86_32-abi
    xl unpause lightning
  This node is normally written by the guest kernel, but for older kernels
  seems not to be.  xend must have a work-around; port this work-around to xl.

* AMD NPT performance regression after c/s 24770:7f79475d3de7
  owner: ?
  Reference: http://marc.info/?l=xen-devel&m=135075376805215

* qemu-upstream: cd-insert and cd-eject not working
  http://marc.info/?l=xen-devel&m=135850249808960

* Install into /usr/local by default
  owner: Ian Campbell

* Revert Jan's debugging patch (commit bd9be94)
  owner: Jan Beulich

* Race condition in claim hypercall
  owner: Ian Jackson, Konrad Wilk

* Remove hardcoded mobprobe's in xencommons
  owner: ?
  status: ?

== Not yet complete ==

* ARM v7 server port
  owner: ijc@citrix
  prognosis: Excellent
  status: ?

* ARM v8 server port (tech preview)
  owner: ijc@citrix
  status: ?
  prognosis: Tech preview only

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: Patches posted
  prognosis: Excellent

* Default to QEMU upstream
 > Add "intel-hda" to xmexample file, since it works with 64-bit Win7/8
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: in progress
   prognosis: ?
   qemu-upstream needs a more fully-featured libc than exists in
   mini-os.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

* Multi-vector PCI MSI (support at least for Dom0)
  owner: jan@suse
  status: Patches posted for Intel; AMD not yet done
  prognosis: Fair

* vTPM updates
  owner: Daniel DeGraaf @ NSA
  status: some patches submitted, more in progress
  prognosis: Good

* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
  owner: George
  status: ?
  prognosis: Poor
  xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
  - port the xm/xend functionality to xl.
  - this PVUSB feature does not require support or emulation from Qemu.
  - upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad's git tree.
  - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers.

* xl USB pass-through for HVM guests using Qemu USB emulation
  owner: George
  status: v4 patch series posted
  prognosis: Fair

* xl: passing more defaults in configuration in xl.conf
  owner: ?
  There are a number of options for which it might be useful to pass a
  default in xl.conf.  For example, if we could have a default
  "backend" parameter for vifs, then it would be easy to switch back
  and forth between a backend in a driver domain and a backend in dom0.

* Rationalized backend scripts
  owner: roger@citrix
  status: libxl hotplug sumbmitted.  Protocol still needs to be finalized.
  prognosis: Good

* Scripts for driver domains (depends on backend scripts)
  owner: roger@citrix
  status:
  prognosis: Fair

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Ian Campbell]

On Tue, 2013-04-16 at 13:22 +0100, George Dunlap wrote:
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.3
> 
> At this point, code will begin freezing.
> 
> This means that every patch will need an exception to be accepted.  The
> bar for acceptance will be relatively low this week, but will continue
> to raise until the May 6th code freeze.
> 
> The key goals we're focusing on now, in order, are as follows:
>  1. Have a bug-free 4.3 release
>  2. Have an awesome 4.3 release
>  3. Have a 4.3 release that happens on schedule (ready by June 15th)
> 
> So my goal right now is to ensure, to the best of my ability, that:
>  1. No new bugs are introduced that will not be discovered before the
>  release
>  2. If no code is added, then either:
           ^new?
>   - it does case the release to slip
             ^not cause ?
 
>   - if it causes the release to slip, it was worth the cost.

[...]

> * Install into /usr/local by default
>   owner: Ian Campbell

Done.

Ian.

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On 16/04/13 13:37, Ian Campbell wrote:
> On Tue, 2013-04-16 at 13:22 +0100, George Dunlap wrote:
>> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>>   http://wiki.xen.org/wiki/Xen_Roadmap/4.3
>>
>> At this point, code will begin freezing.
>>
>> This means that every patch will need an exception to be accepted.  The
>> bar for acceptance will be relatively low this week, but will continue
>> to raise until the May 6th code freeze.
>>
>> The key goals we're focusing on now, in order, are as follows:
>>   1. Have a bug-free 4.3 release
>>   2. Have an awesome 4.3 release
>>   3. Have a 4.3 release that happens on schedule (ready by June 15th)
>>
>> So my goal right now is to ensure, to the best of my ability, that:
>>   1. No new bugs are introduced that will not be discovered before the
>>   release
>>   2. If no code is added, then either:
>             ^new?

Er, not sure how that got past the proofreading... yes, it should say:

2. If new code is added, then either:
  - It does not cause the release to slip
  - If it causes the release to slip, then it was worth the cost.

>> * Install into /usr/local by default
>>    owner: Ian Campbell

Great, thanks.

  -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:

>
> == Bugs ==
>
> * xl, compat mode, and older kernels
>   owner: ?
>   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>   xend do not work when started with xl.  The following work-around seems to
>   work:
>     xl create -p lightning.cfg
>     xenstore-write /local/domain/$(xl domid
> lightning)/device/vbd/51713/protocol x86_32-abi
>     xl unpause lightning
>   This node is normally written by the guest kernel, but for older kernels
>   seems not to be.  xend must have a work-around; port this work-around to xl.


> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?

We need someone to step up for each of these two.

 -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> == Bugs ==

>
> * qemu-upstream: cd-insert and cd-eject not working
>   http://marc.info/?l=xen-devel&m=135850249808960

Anthony, is this one on your radar?

 -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Jan Beulich]

>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.3 
> 
> At this point, code will begin freezing.
> 
> This means that every patch will need an exception to be accepted.  The
> bar for acceptance will be relatively low this week, but will continue
> to raise until the May 6th code freeze.

So how does this "accepting an exception" look from a formal POV?
Do non-bug-fix patches need an additional ACK from you? Or are
committers expected to use common sense? Or yet something else?

Jan

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On 16/04/13 13:57, Jan Beulich wrote:
>>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>>   http://wiki.xen.org/wiki/Xen_Roadmap/4.3
>>
>> At this point, code will begin freezing.
>>
>> This means that every patch will need an exception to be accepted.  The
>> bar for acceptance will be relatively low this week, but will continue
>> to raise until the May 6th code freeze.
> So how does this "accepting an exception" look from a formal POV?
> Do non-bug-fix patches need an additional ACK from you? Or are
> committers expected to use common sense? Or yet something else?

Well, I have not been elected to any position, nor am I the benevolent 
dictator, so I am not in a position to dictate to committers what to 
commit and what not to commit.

However, I would respectfully request that committers ask for an Ack 
from me, if that is acceptable to everyone.

  -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Jan Beulich]

>>> On 16.04.13 at 15:00, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 16/04/13 13:57, Jan Beulich wrote:
>>>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>>>   http://wiki.xen.org/wiki/Xen_Roadmap/4.3 
>>>
>>> At this point, code will begin freezing.
>>>
>>> This means that every patch will need an exception to be accepted.  The
>>> bar for acceptance will be relatively low this week, but will continue
>>> to raise until the May 6th code freeze.
>> So how does this "accepting an exception" look from a formal POV?
>> Do non-bug-fix patches need an additional ACK from you? Or are
>> committers expected to use common sense? Or yet something else?
> 
> Well, I have not been elected to any position, nor am I the benevolent 
> dictator, so I am not in a position to dictate to committers what to 
> commit and what not to commit.
> 
> However, I would respectfully request that committers ask for an Ack 
> from me, if that is acceptable to everyone.

That's fine with me of course, in the hope that I won't forget
once in a while.

Jan

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Wei Liu]

On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> 
> >
> > == Bugs ==
> >
> > * xl, compat mode, and older kernels
> >   owner: ?
> >   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
> >   xend do not work when started with xl.  The following work-around seems to
> >   work:
> >     xl create -p lightning.cfg
> >     xenstore-write /local/domain/$(xl domid
> > lightning)/device/vbd/51713/protocol x86_32-abi
> >     xl unpause lightning
> >   This node is normally written by the guest kernel, but for older kernels
> >   seems not to be.  xend must have a work-around; port this work-around to xl.
> 

I played with Xend several years ago, I can try to have a look at this.

> 
> > * Remove hardcoded mobprobe's in xencommons
> >   owner: ?
> >   status: ?
> 

Maybe this as well if nobody else steps up.


Wei.

> We need someone to step up for each of these two.

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

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:

> * Default to QEMU upstream
>  > Add "intel-hda" to xmexample file, since it works with 64-bit Win7/8
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: in progress
>    prognosis: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    mini-os.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.

Anthony, what's the status on this?

At the moment we default to qemu-upstream if the DM is running in
dom0, and to qemu-traditional if we're running in a stubdom.  What
that means is that if someone installs the "normal" way, and then
decides to upgrade to qemu stub domains, then their qemu version will
downgrade.

Just as a data point: I installed Windows XP on qemu-upstream, and
then switched to qemu-default.  XP booted, but a bunch of the devices,
including the VGA and the ethernet, changed and wanted new driver
installed.  But it didn't have an ethernet driver, so it couldn't
download the drivers from the web.  (Presumably if it had had PV tools
installed it wouldn't have been an issue.)

So not terrible, but not great: I would still really like to get this
in if we can.

Thoughts?
 -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
>> <George.Dunlap@eu.citrix.com> wrote:
>>
>> >
>> > == Bugs ==
>> >
>> > * xl, compat mode, and older kernels
>> >   owner: ?
>> >   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>> >   xend do not work when started with xl.  The following work-around seems to
>> >   work:
>> >     xl create -p lightning.cfg
>> >     xenstore-write /local/domain/$(xl domid
>> > lightning)/device/vbd/51713/protocol x86_32-abi
>> >     xl unpause lightning
>> >   This node is normally written by the guest kernel, but for older kernels
>> >   seems not to be.  xend must have a work-around; port this work-around to xl.
>>
>
> I played with Xend several years ago, I can try to have a look at this.
>
>>
>> > * Remove hardcoded mobprobe's in xencommons
>> >   owner: ?
>> >   status: ?
>>
>
> Maybe this as well if nobody else steps up.

Great, thanks.


 -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Anthony PERARD]

On 16/04/13 16:16, George Dunlap wrote:
> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> 
>> * Default to QEMU upstream
>>  > Add "intel-hda" to xmexample file, since it works with 64-bit Win7/8
>>  - qemu-based stubdom (Linux or BSD libc)
>>    owner: anthony@citrix
>>    status: in progress
>>    prognosis: ?
>>    qemu-upstream needs a more fully-featured libc than exists in
>>    mini-os.  Either work on a minimalist linux-based stubdom with
>>    glibc, or port one of the BSD libcs to minios.
> 
> Anthony, what's the status on this?

I'm close to send patches for it, and it should be sent before the end
of this week.

But it will be more of a tech preview I suppose, as I did not try to
have the vga working, yet.

> At the moment we default to qemu-upstream if the DM is running in
> dom0, and to qemu-traditional if we're running in a stubdom.  What
> that means is that if someone installs the "normal" way, and then
> decides to upgrade to qemu stub domains, then their qemu version will
> downgrade.
> 
> Just as a data point: I installed Windows XP on qemu-upstream, and
> then switched to qemu-default.  XP booted, but a bunch of the devices,
> including the VGA and the ethernet, changed and wanted new driver
> installed.  But it didn't have an ethernet driver, so it couldn't
> download the drivers from the web.  (Presumably if it had had PV tools
> installed it wouldn't have been an issue.)
> 
> So not terrible, but not great: I would still really like to get this
> in if we can.
> 
> Thoughts?


-- 
Anthony PERARD

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Wei Liu]

On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:
> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
> >> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> >> <George.Dunlap@eu.citrix.com> wrote:
> >>
> >> >
> >> > == Bugs ==
> >> >
> >> > * xl, compat mode, and older kernels
> >> >   owner: ?
> >> >   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
> >> >   xend do not work when started with xl.  The following work-around seems to
> >> >   work:
> >> >     xl create -p lightning.cfg
> >> >     xenstore-write /local/domain/$(xl domid
> >> > lightning)/device/vbd/51713/protocol x86_32-abi
> >> >     xl unpause lightning
> >> >   This node is normally written by the guest kernel, but for older kernels
> >> >   seems not to be.  xend must have a work-around; port this work-around to xl.
> >>
> >
> > I played with Xend several years ago, I can try to have a look at this.
> >

Quick question, anyone has kernel image that's needs this workaround?


Wei.

> >>
> >> > * Remove hardcoded mobprobe's in xencommons
> >> >   owner: ?
> >> >   status: ?
> >>
> >
> > Maybe this as well if nobody else steps up.
> 
> Great, thanks.
> 
> 
>  -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On 16/04/13 17:11, Wei Liu wrote:
> On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:
>> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
>>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
>>>> <George.Dunlap@eu.citrix.com> wrote:
>>>>
>>>>> == Bugs ==
>>>>>
>>>>> * xl, compat mode, and older kernels
>>>>>    owner: ?
>>>>>    Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>>>>>    xend do not work when started with xl.  The following work-around seems to
>>>>>    work:
>>>>>      xl create -p lightning.cfg
>>>>>      xenstore-write /local/domain/$(xl domid
>>>>> lightning)/device/vbd/51713/protocol x86_32-abi
>>>>>      xl unpause lightning
>>>>>    This node is normally written by the guest kernel, but for older kernels
>>>>>    seems not to be.  xend must have a work-around; port this work-around to xl.
>>> I played with Xend several years ago, I can try to have a look at this.
>>>
> Quick question, anyone has kernel image that's needs this workaround?

The original thread that started this is here:

http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded

It mentioned using Debian etch's built-in 2.6.16.33-xen kernel.

  -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Stefano Stabellini]

On Tue, 16 Apr 2013, George Dunlap wrote:
> * Rationalized backend scripts
>   owner: roger@citrix
>   status: libxl hotplug sumbmitted.  Protocol still needs to be finalized.
>   prognosis: Good

OK

> * Scripts for driver domains (depends on backend scripts)
>   owner: roger@citrix
>   status:
>   prognosis: Fair

Are there going to make 4.3?

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Roger Pau Monné]

On 18/04/13 13:30, Stefano Stabellini wrote:
> On Tue, 16 Apr 2013, George Dunlap wrote:
>> * Rationalized backend scripts
>>   owner: roger@citrix
>>   status: libxl hotplug sumbmitted.  Protocol still needs to be finalized.
>>   prognosis: Good
> 
> OK
> 
>> * Scripts for driver domains (depends on backend scripts)
>>   owner: roger@citrix
>>   status:
>>   prognosis: Fair
> 
> Are there going to make 4.3?

Regarding "Rationalized backend scripts", or what I usually call new
libxl hotplug interface, I think it could make it to 4.3. Here is a
small list about the pros/cons of taking that from my POV:

Cons:
 - Touches generic device addition/removal code, and domain
creation/destruction.

 - It introduces a new interface that is well defined and that we plan
to support, we have to be sure the interface is right.


Pros:
 - All the code touched is exercised every time a domain/device is
created/destroyed, so the test system should be able to detect any
problems with that easily.

 - Brings new functionality (iSCSI disks), which is not present in
libxl/xl, and should be considered a regression from xm.

 - The new hotplug interface could be released as a tech preview,
guaranteeing us that we could still change it if we feel it doesn't
really suit our needs (I think it's best to have it as a tech preview
rather than not having it at all).

 - The new iSCSI libxl/xl disk functionality could also be considered a
tech preview, again it's best to have it like that rather than not
having it at all, I've heard quite a lot of people asking about iSCSI
support in Xen.

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[George Dunlap]

On 18/04/13 15:50, Roger Pau Monne wrote:
> On 18/04/13 13:30, Stefano Stabellini wrote:
>> On Tue, 16 Apr 2013, George Dunlap wrote:
>>> * Rationalized backend scripts
>>>    owner: roger@citrix
>>>    status: libxl hotplug sumbmitted.  Protocol still needs to be finalized.
>>>    prognosis: Good
>> OK
>>
>>> * Scripts for driver domains (depends on backend scripts)
>>>    owner: roger@citrix
>>>    status:
>>>    prognosis: Fair
>> Are there going to make 4.3?
> Regarding "Rationalized backend scripts", or what I usually call new
> libxl hotplug interface, I think it could make it to 4.3. Here is a
> small list about the pros/cons of taking that from my POV:
>
> Cons:
>   - Touches generic device addition/removal code, and domain
> creation/destruction.
>
>   - It introduces a new interface that is well defined and that we plan
> to support, we have to be sure the interface is right.
>
>
> Pros:
>   - All the code touched is exercised every time a domain/device is
> created/destroyed, so the test system should be able to detect any
> problems with that easily.

OK, why don't we check it in, and if it seems to be causing carnage 
we'll revert it.

I'll reply to the series with an ack.

  -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Wei Liu]

On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote:
> On 16/04/13 17:11, Wei Liu wrote:
> > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:
> >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
> >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> >>>> <George.Dunlap@eu.citrix.com> wrote:
> >>>>
> >>>>> == Bugs ==
> >>>>>
> >>>>> * xl, compat mode, and older kernels
> >>>>>    owner: ?
> >>>>>    Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
> >>>>>    xend do not work when started with xl.  The following work-around seems to
> >>>>>    work:
> >>>>>      xl create -p lightning.cfg
> >>>>>      xenstore-write /local/domain/$(xl domid
> >>>>> lightning)/device/vbd/51713/protocol x86_32-abi
> >>>>>      xl unpause lightning
> >>>>>    This node is normally written by the guest kernel, but for older kernels
> >>>>>    seems not to be.  xend must have a work-around; port this work-around to xl.
> >>> I played with Xend several years ago, I can try to have a look at this.
> >>>
> > Quick question, anyone has kernel image that's needs this workaround?
> 
> The original thread that started this is here:
> 
> http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded
> 
> It mentioned using Debian etch's built-in 2.6.16.33-xen kernel.

Now I've identified the problem, should I write a patch for it or should
I wait till 4.4 window is open?


Wei.

> 
>   -George

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Alex Bligh]

--On 18 April 2013 16:50:06 +0200 Roger Pau Monné <roger.pau@citrix.com> 
wrote:

>  - The new iSCSI libxl/xl disk functionality could also be considered a
> tech preview, again it's best to have it like that rather than not
> having it at all, I've heard quite a lot of people asking about iSCSI
> support in Xen.

I don't quite understand this point. We've been happily using iSCSI
support (i.e. dom0 iSCSI block devices) with xen 4.2 for ages,
using libxl. I am 99.9% sure we have this working with xl too for
testing. Why does Xen even care whether /dev/sdc is a SATA disk or
a SCSI disk?

Completely untested, but if upstream QEMU device model is the 4.3
default, upstream QEMU has its own native iscsi client built in.
Won't that 'just work'? (with libxl, perhaps not xl)

-- 
Alex Bligh

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

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Ian Campbell]

On Thu, 2013-04-18 at 19:09 +0100, Wei Liu wrote:
> On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote:
> > On 16/04/13 17:11, Wei Liu wrote:
> > > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:
> > >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
> > >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> > >>>> <George.Dunlap@eu.citrix.com> wrote:
> > >>>>
> > >>>>> == Bugs ==
> > >>>>>
> > >>>>> * xl, compat mode, and older kernels
> > >>>>>    owner: ?
> > >>>>>    Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
> > >>>>>    xend do not work when started with xl.  The following work-around seems to
> > >>>>>    work:
> > >>>>>      xl create -p lightning.cfg
> > >>>>>      xenstore-write /local/domain/$(xl domid
> > >>>>> lightning)/device/vbd/51713/protocol x86_32-abi
> > >>>>>      xl unpause lightning
> > >>>>>    This node is normally written by the guest kernel, but for older kernels
> > >>>>>    seems not to be.  xend must have a work-around; port this work-around to xl.
> > >>> I played with Xend several years ago, I can try to have a look at this.
> > >>>
> > > Quick question, anyone has kernel image that's needs this workaround?
> > 
> > The original thread that started this is here:
> > 
> > http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded
> > 
> > It mentioned using Debian etch's built-in 2.6.16.33-xen kernel.
> 
> Now I've identified the problem, should I write a patch for it or should
> I wait till 4.4 window is open?

Write a patch, we should at least consider it as a bug fix for 4.3.

Ian

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Roger Pau Monné]

On 18/04/13 21:58, Alex Bligh wrote:
> 
> 
> --On 18 April 2013 16:50:06 +0200 Roger Pau Monné <roger.pau@citrix.com> 
> wrote:
> 
>>  - The new iSCSI libxl/xl disk functionality could also be considered a
>> tech preview, again it's best to have it like that rather than not
>> having it at all, I've heard quite a lot of people asking about iSCSI
>> support in Xen.
> 
> I don't quite understand this point. We've been happily using iSCSI
> support (i.e. dom0 iSCSI block devices) with xen 4.2 for ages,
> using libxl. I am 99.9% sure we have this working with xl too for
> testing. Why does Xen even care whether /dev/sdc is a SATA disk or
> a SCSI disk?

Sure, you can attach the iSCSI disk yourself on the Dom0 and pass that
block device to the DomU, or you could even have a hotplug script that
does this automatically.

The nice thing from this implementation (apart from the fact that you
can specify iSCSI targets in the DomU config file, so you don't have to
care about plugging them), is that it allows to offload part of the work
that is usually done in the "add" phase to a new action called
"prepare", that when performing migration is executed before the guest
on the sender side is paused, so the blackout phase during migration is
reduced.

> 
> Completely untested, but if upstream QEMU device model is the 4.3
> default, upstream QEMU has its own native iscsi client built in.
> Won't that 'just work'? (with libxl, perhaps not xl)

Probably, but it will be much slower than blkback.


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

Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN

[Wei Liu]

On Fri, Apr 19, 2013 at 08:50:16AM +0100, Ian Campbell wrote:
> On Thu, 2013-04-18 at 19:09 +0100, Wei Liu wrote:
> > On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote:
> > > On 16/04/13 17:11, Wei Liu wrote:
> > > > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:
> > > >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > > >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:
> > > >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap
> > > >>>> <George.Dunlap@eu.citrix.com> wrote:
> > > >>>>
> > > >>>>> == Bugs ==
> > > >>>>>
> > > >>>>> * xl, compat mode, and older kernels
> > > >>>>>    owner: ?
> > > >>>>>    Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
> > > >>>>>    xend do not work when started with xl.  The following work-around seems to
> > > >>>>>    work:
> > > >>>>>      xl create -p lightning.cfg
> > > >>>>>      xenstore-write /local/domain/$(xl domid
> > > >>>>> lightning)/device/vbd/51713/protocol x86_32-abi
> > > >>>>>      xl unpause lightning
> > > >>>>>    This node is normally written by the guest kernel, but for older kernels
> > > >>>>>    seems not to be.  xend must have a work-around; port this work-around to xl.
> > > >>> I played with Xend several years ago, I can try to have a look at this.
> > > >>>
> > > > Quick question, anyone has kernel image that's needs this workaround?
> > > 
> > > The original thread that started this is here:
> > > 
> > > http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded
> > > 
> > > It mentioned using Debian etch's built-in 2.6.16.33-xen kernel.
> > 
> > Now I've identified the problem, should I write a patch for it or should
> > I wait till 4.4 window is open?
> 
> Write a patch, we should at least consider it as a bug fix for 4.3.
> 

No problem, getting to that.


Wei.

> Ian
>