preparations for 4.4.1, 4.3.3, and 4.2.5

preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

All,

with the aim of releasing 4.4.1 no later than 3 months after the original
4.4.0 release, and - in order to consolidate effort as well as to not
exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
out to the relevant maintainers any backport requests you may observe
still missing but required on the respective branches.

Please note that there's no need to nominate

99c03bc6 "Nested VMX: load current_vmcs only when it exists"
a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"

as they're already on my list of backports to be done before the
RC1s for the branches they reasonably apply to.

Please note further that 4.2.5 is expected to be the last xen.org
managed release from the 4.2 branch.

Thanks, Jan

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Andrew Cooper]

On 19/05/14 15:12, Jan Beulich wrote:
> All,
>
> with the aim of releasing 4.4.1 no later than 3 months after the original
> 4.4.0 release, and - in order to consolidate effort as well as to not
> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> out to the relevant maintainers any backport requests you may observe
> still missing but required on the respective branches.
>
> Please note that there's no need to nominate
>
> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
>
> as they're already on my list of backports to be done before the
> RC1s for the branches they reasonably apply to.
>
> Please note further that 4.2.5 is expected to be the last xen.org
> managed release from the 4.2 branch.
>
> Thanks, Jan

>From the current XenServer patchqueue backports section.

Xen side fixes:

6d27a53, c7e35c6, 4c15a82: 3x RTC emulation fixes.  Windows XP/2003 are
still susceptible to falling into infinite loops under Xen 4.3 and 4.4
without these.

Tool side fixes:

c566ab6 "libxl: Fix error path in libxl_device_events_handler"
81b0305 "tools/libxl: Don't read off the end of tinfo[]"
d752158 "tools/pygrub: Fix error handling if no valid partitions are found"

~Andrew

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.4.1, 4.3.3, and 4.2.5"):
> Tool side fixes:
> 
> c566ab6 "libxl: Fix error path in libxl_device_events_handler"
> 81b0305 "tools/libxl: Don't read off the end of tinfo[]"
> d752158 "tools/pygrub: Fix error handling if no valid partitions are found"

Thanks, these all look like good backport candidates and are now on my
list.

Ian.

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Boris Ostrovsky]

On 05/19/2014 10:12 AM, Jan Beulich wrote:
> All,
>
> with the aim of releasing 4.4.1 no later than 3 months after the original
> 4.4.0 release, and - in order to consolidate effort as well as to not
> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> out to the relevant maintainers any backport requests you may observe
> still missing but required on the respective branches.
>
> Please note that there's no need to nominate
>
> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
>
> as they're already on my list of backports to be done before the
> RC1s for the branches they reasonably apply to.
>
> Please note further that 4.2.5 is expected to be the last xen.org
> managed release from the 4.2 branch.
>
> Thanks, Jan


Tools:
2c4f066 libxl: Set guest parameters from config file during a restore

Hypervisor:
88e64cb x86/HVM: use fixed TSC value when saving or restoring domain
b95fd03 x86/svm: enable TSC scaling
82713ec x86: use native RDTSC(P) execution when guest and host 
frequencies are the same


-boris

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

>>> On 19.05.14 at 22:14, <boris.ostrovsky@oracle.com> wrote:
> Hypervisor:
> 88e64cb x86/HVM: use fixed TSC value when saving or restoring domain
> b95fd03 x86/svm: enable TSC scaling
> 82713ec x86: use native RDTSC(P) execution when guest and host 
> frequencies are the same

My understanding was that these are solely about performance,
not correctness. That would make them weak candidates for
4.4.1 (under the slightly relaxed rules we put on x.y.1 releases),
but not any of the older trees. Do you have a different view?

Jan

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Boris Ostrovsky]

On 05/20/2014 08:28 AM, Jan Beulich wrote:
>>>> On 19.05.14 at 22:14, <boris.ostrovsky@oracle.com> wrote:
>> Hypervisor:
>> 88e64cb x86/HVM: use fixed TSC value when saving or restoring domain
>> b95fd03 x86/svm: enable TSC scaling
>> 82713ec x86: use native RDTSC(P) execution when guest and host
>> frequencies are the same
> My understanding was that these are solely about performance,
> not correctness. That would make them weak candidates for
> 4.4.1 (under the slightly relaxed rules we put on x.y.1 releases),
> but not any of the older trees. Do you have a different view?

No, these are correctness fixes.

The main thing (in this context) about 82713ec is reverting part of 
4aab59a3 which broke migration on SVM (in principle I think you can take 
only the first hunk from it)

88e64cb fixes the fact that TSCs get unsynchronized after migration. And 
it needs some of the interfaces introduced in b95fd03 (which in itself 
is indeed mostly about performance)

-boris

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

>>> On 20.05.14 at 15:31, <boris.ostrovsky@oracle.com> wrote:
> On 05/20/2014 08:28 AM, Jan Beulich wrote:
>>>>> On 19.05.14 at 22:14, <boris.ostrovsky@oracle.com> wrote:
>>> Hypervisor:
>>> 88e64cb x86/HVM: use fixed TSC value when saving or restoring domain
>>> b95fd03 x86/svm: enable TSC scaling
>>> 82713ec x86: use native RDTSC(P) execution when guest and host
>>> frequencies are the same
>> My understanding was that these are solely about performance,
>> not correctness. That would make them weak candidates for
>> 4.4.1 (under the slightly relaxed rules we put on x.y.1 releases),
>> but not any of the older trees. Do you have a different view?
> 
> No, these are correctness fixes.
> 
> The main thing (in this context) about 82713ec is reverting part of 
> 4aab59a3 which broke migration on SVM (in principle I think you can take 
> only the first hunk from it)

I applied this one, ...

> 88e64cb fixes the fact that TSCs get unsynchronized after migration. And 
> it needs some of the interfaces introduced in b95fd03 (which in itself 
> is indeed mostly about performance)

... but didn't take these as being rather large for a problem I don't
recall seeing a report for. If you can see ways to supply a reduced
backport with only the bug fix but not the performance improvement,
feel free to send that for consideration.

Jan

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Daniel Kiper]

On Mon, May 19, 2014 at 03:12:20PM +0100, Jan Beulich wrote:
> All,
>
> with the aim of releasing 4.4.1 no later than 3 months after the original
> 4.4.0 release, and - in order to consolidate effort as well as to not
> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> out to the relevant maintainers any backport requests you may observe
> still missing but required on the respective branches.
>
> Please note that there's no need to nominate
>
> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
>
> as they're already on my list of backports to be done before the
> RC1s for the branches they reasonably apply to.
>
> Please note further that 4.2.5 is expected to be the last xen.org
> managed release from the 4.2 branch.

Could you backport commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
(tools/hotplug: set mtu from bridge for tap interface). Without this
bridge MTU is set to MTU of emulated interface if it is used. This
is very painful if your bridge MTU is != 1500.

Daniel

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

>>> On 21.05.14 at 17:03, <dkiper@net-space.pl> wrote:
> On Mon, May 19, 2014 at 03:12:20PM +0100, Jan Beulich wrote:
>> All,
>>
>> with the aim of releasing 4.4.1 no later than 3 months after the original
>> 4.4.0 release, and - in order to consolidate effort as well as to not
>> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
>> out to the relevant maintainers any backport requests you may observe
>> still missing but required on the respective branches.
>>
>> Please note that there's no need to nominate
>>
>> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
>> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
>>
>> as they're already on my list of backports to be done before the
>> RC1s for the branches they reasonably apply to.
>>
>> Please note further that 4.2.5 is expected to be the last xen.org
>> managed release from the 4.2 branch.
> 
> Could you backport commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> (tools/hotplug: set mtu from bridge for tap interface). Without this
> bridge MTU is set to MTU of emulated interface if it is used. This
> is very painful if your bridge MTU is != 1500.

As with any tools backports, you should direct this at Ian J (now
Cc-ed).

Jan

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Daniel Kiper]

On Wed, May 21, 2014 at 04:12:54PM +0100, Jan Beulich wrote:
> >>> On 21.05.14 at 17:03, <dkiper@net-space.pl> wrote:
> > On Mon, May 19, 2014 at 03:12:20PM +0100, Jan Beulich wrote:
> >> All,
> >>
> >> with the aim of releasing 4.4.1 no later than 3 months after the original
> >> 4.4.0 release, and - in order to consolidate effort as well as to not
> >> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> >> out to the relevant maintainers any backport requests you may observe
> >> still missing but required on the respective branches.
> >>
> >> Please note that there's no need to nominate
> >>
> >> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> >> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
> >>
> >> as they're already on my list of backports to be done before the
> >> RC1s for the branches they reasonably apply to.
> >>
> >> Please note further that 4.2.5 is expected to be the last xen.org
> >> managed release from the 4.2 branch.
> >
> > Could you backport commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > (tools/hotplug: set mtu from bridge for tap interface). Without this
> > bridge MTU is set to MTU of emulated interface if it is used. This
> > is very painful if your bridge MTU is != 1500.
>
> As with any tools backports, you should direct this at Ian J (now
> Cc-ed).

Ian J, ping?

Daniel

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Daniel Kiper]

On Fri, May 30, 2014 at 02:03:18PM +0200, Daniel Kiper wrote:
> On Wed, May 21, 2014 at 04:12:54PM +0100, Jan Beulich wrote:
> > >>> On 21.05.14 at 17:03, <dkiper@net-space.pl> wrote:
> > > On Mon, May 19, 2014 at 03:12:20PM +0100, Jan Beulich wrote:
> > >> All,
> > >>
> > >> with the aim of releasing 4.4.1 no later than 3 months after the original
> > >> 4.4.0 release, and - in order to consolidate effort as well as to not
> > >> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> > >> out to the relevant maintainers any backport requests you may observe
> > >> still missing but required on the respective branches.
> > >>
> > >> Please note that there's no need to nominate
> > >>
> > >> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> > >> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
> > >>
> > >> as they're already on my list of backports to be done before the
> > >> RC1s for the branches they reasonably apply to.
> > >>
> > >> Please note further that 4.2.5 is expected to be the last xen.org
> > >> managed release from the 4.2 branch.
> > >
> > > Could you backport commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > > (tools/hotplug: set mtu from bridge for tap interface). Without this
> > > bridge MTU is set to MTU of emulated interface if it is used. This
> > > is very painful if your bridge MTU is != 1500.
> >
> > As with any tools backports, you should direct this at Ian J (now
> > Cc-ed).
>
> Ian J, ping?

Timeout... ping?

Daniel

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Daniel Kiper]

On Wed, Jun 11, 2014 at 09:28:32PM +0200, Daniel Kiper wrote:
> On Fri, May 30, 2014 at 02:03:18PM +0200, Daniel Kiper wrote:
> > On Wed, May 21, 2014 at 04:12:54PM +0100, Jan Beulich wrote:
> > > >>> On 21.05.14 at 17:03, <dkiper@net-space.pl> wrote:
> > > > On Mon, May 19, 2014 at 03:12:20PM +0100, Jan Beulich wrote:
> > > >> All,
> > > >>
> > > >> with the aim of releasing 4.4.1 no later than 3 months after the original
> > > >> 4.4.0 release, and - in order to consolidate effort as well as to not
> > > >> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> > > >> out to the relevant maintainers any backport requests you may observe
> > > >> still missing but required on the respective branches.
> > > >>
> > > >> Please note that there's no need to nominate
> > > >>
> > > >> 99c03bc6 "Nested VMX: load current_vmcs only when it exists"
> > > >> a0708452 "x86/MCE: bypass uninitialized vcpu in vMCE injection"
> > > >>
> > > >> as they're already on my list of backports to be done before the
> > > >> RC1s for the branches they reasonably apply to.
> > > >>
> > > >> Please note further that 4.2.5 is expected to be the last xen.org
> > > >> managed release from the 4.2 branch.
> > > >
> > > > Could you backport commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > > > (tools/hotplug: set mtu from bridge for tap interface). Without this
> > > > bridge MTU is set to MTU of emulated interface if it is used. This
> > > > is very painful if your bridge MTU is != 1500.
> > >
> > > As with any tools backports, you should direct this at Ian J (now
> > > Cc-ed).
> >
> > Ian J, ping?
>
> Timeout... ping?

Ian, sadly as I can see this patch was not merged at least into 4.3.3.
Could we marge it into 4.3.4 and others maintained stable versions?
This patch fixes an obvious bug.

Daniel

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Olaf Hering]

On Mon, May 19, Jan Beulich wrote:

> with the aim of releasing 4.4.1 no later than 3 months after the original
> 4.4.0 release, and - in order to consolidate effort as well as to not
> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> out to the relevant maintainers any backport requests you may observe
> still missing but required on the respective branches.

9011c26 xend/pvscsi: recognize also SCSI CDROM devices
2256f09 tools/xend: move assert to exception block

Olaf

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Olaf Hering]

On Tue, May 27, Olaf Hering wrote:

> On Mon, May 19, Jan Beulich wrote:
> 
> > with the aim of releasing 4.4.1 no later than 3 months after the original
> > 4.4.0 release, and - in order to consolidate effort as well as to not
> > exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> > out to the relevant maintainers any backport requests you may observe
> > still missing but required on the respective branches.

4.2 lacks this xend patch:

4b5059b xend: Only add cpuid and cpuid_check to sexpr once

Olaf

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

>>> On 27.05.14 at 09:44, <olaf@aepfle.de> wrote:
> On Mon, May 19, Jan Beulich wrote:
> 
>> with the aim of releasing 4.4.1 no later than 3 months after the original
>> 4.4.0 release, and - in order to consolidate effort as well as to not
>> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
>> out to the relevant maintainers any backport requests you may observe
>> still missing but required on the respective branches.
> 
> 9011c26 xend/pvscsi: recognize also SCSI CDROM devices
> 2256f09 tools/xend: move assert to exception block

For both this and ...

> 4.2 lacks this xend patch:
> 
> 4b5059b xend: Only add cpuid and cpuid_check to sexpr once

... this you should have pinged IanJ instead of me. Cc-ing him now.

Also, a little bit of justification - namely for xend patches - might
help in evaluating whether such proposals are acceptable.

Jan

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Roger Pau Monné]

On 19/05/14 16:12, Jan Beulich wrote:
> All,
> 
> with the aim of releasing 4.4.1 no later than 3 months after the original
> 4.4.0 release, and - in order to consolidate effort as well as to not
> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
> out to the relevant maintainers any backport requests you may observe
> still missing but required on the respective branches.

IMHO we should backport commit:

7c48709 x86/PVH: avoid call to handle_mmio

to the stable 4.4 branch in order the prevent PVH guests from crashing Xen.

Roger.

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Roger Pau Monné]

On 25/06/14 12:29, Roger Pau Monné wrote:
> On 19/05/14 16:12, Jan Beulich wrote:
>> All,
>>
>> with the aim of releasing 4.4.1 no later than 3 months after the original
>> 4.4.0 release, and - in order to consolidate effort as well as to not
>> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
>> out to the relevant maintainers any backport requests you may observe
>> still missing but required on the respective branches.
> 
> IMHO we should backport commit:
> 
> 7c48709 x86/PVH: avoid call to handle_mmio
> 
> to the stable 4.4 branch in order the prevent PVH guests from crashing Xen.


Forget about this, it's already done. Sorry for the noise.

Roger.

Re: preparations for 4.4.1, 4.3.3, and 4.2.5

[Jan Beulich]

>>> On 25.06.14 at 12:29, <roger.pau@citrix.com> wrote:
> On 19/05/14 16:12, Jan Beulich wrote:
>> All,
>> 
>> with the aim of releasing 4.4.1 no later than 3 months after the original
>> 4.4.0 release, and - in order to consolidate effort as well as to not
>> exceed the 3 month step by too much - 4.3.3 and 4.2.5, please point
>> out to the relevant maintainers any backport requests you may observe
>> still missing but required on the respective branches.
> 
> IMHO we should backport commit:
> 
> 7c48709 x86/PVH: avoid call to handle_mmio
> 
> to the stable 4.4 branch in order the prevent PVH guests from crashing Xen.

Which I committed to the staging-4.4 branch yesterday.

Jan