Backport suggestions for Xen 4.4

Backport suggestions for Xen 4.4

[Andrew Cooper]

Hello,

Some further backport suggestions, from the XenServer patch queue.

Xen bugfixes:
* 415738e "x86/traps: make panic and reboot paths safe during early boot"
* d4f88fc "make the main trap handlers safe for use early during Xen boot"
** including "\n" fix for #MC handler from b30d333
* 92009d3 "x86/boot: correct CR4 setup on APs"

I would also consider 07884c9 "x86/amd: protect set_cpuidmask() against
#GP faults" a bugfix, but it depends on e74de9c and 7c6c8cc, the former
of which is far closer to a new feature than a bugfixes. 


Xen non-bugfix suggestions:
* d8af81a "x86/nmi: remove spurious local_irq_enable from
check_nmi_watchdog()"
* f64b190 "x86/nmi: be less verbose when testing the NMI watchdog"
* 11dba84 "x86/traps: do not inline do_trap() into 10 different handlers"
* 3385bf3 "x86: Intel CPU family update"


Toolstack bugfixes:
* 0e94de8 "tools/libxc: Issue individual DPRINTF()s rather than
multiline ones."
* d752158 "tools/pygrub: Fix error handling if no valid partitions are
found"
* 0c12e5b "tools/pygrub: Fix extlinux when /boot is a separate partition
from /"
* 84acc84 "libxc: Protect xc_domain_resume from clobbering domain registers"
* e86539a "libxc: check return values on mmap() and madvise() on
xc_alloc_hypercall_buffer()"
* 66f8c63 "tools/libxc: Annotate xc_osdep_log with __attribute__((format))"
* f1f009a "tools/libxc: Annotate xc_report_error with
__attribute__((format))"
** This patch applies cleanly, but doesn't compile cleanly due to other
xc_report_error() printf mismatches in 4.4.  The issues and fixes are
all obvious.


Toolstack non-bugfix suggestions:
* e927d4b "tools/mfndump: Avoid unintentional NULL dereference"
* 42e896b "tools/xenstore: Fix memory leaks in the client"
* dd7317a "libxl/save-helper: Code motion of logging functions"
* 82774ac "tools/libxl: Improvements to libxl-save-helper when using
valgrind"


Thanks,

~Andrew

Re: Backport suggestions for Xen 4.4

[Jan Beulich]

>>> On 24.06.14 at 12:23, <andrew.cooper3@citrix.com> wrote:
> Some further backport suggestions, from the XenServer patch queue.

Thanks.

> Xen bugfixes:
> * 415738e "x86/traps: make panic and reboot paths safe during early boot"
> * d4f88fc "make the main trap handlers safe for use early during Xen boot"

Honestly I'd rather stay away from backporting these, no matter that
I'm convinced they're working fine.

> ** including "\n" fix for #MC handler from b30d333

Purely cosmetic - we're about to die anyway when this message
gets printed, so it not being printed on its own line is the smallest
of our problems.

> * 92009d3 "x86/boot: correct CR4 setup on APs"

This might be acceptable, but would need validation that it really
addresses in the stable trees what it does in -unstable without the
other early trap handling changes. The one comment it adds to
start_secondary() suggests that this might not be the case.

> I would also consider 07884c9 "x86/amd: protect set_cpuidmask() against
> #GP faults" a bugfix, but it depends on e74de9c and 7c6c8cc, the former
> of which is far closer to a new feature than a bugfixes. 

Right. Plus - as said elsewhere already - no-one is forced to use the
command line options needed to enable masking in the first place.

> Xen non-bugfix suggestions:
> * d8af81a "x86/nmi: remove spurious local_irq_enable from
> check_nmi_watchdog()"

Purely cosmetic.

> * f64b190 "x86/nmi: be less verbose when testing the NMI watchdog"

Hmm, yes, this might be a candidate, at least for 4.4 (under the
slightly relaxed x.y.1 backporting rules).

> * 11dba84 "x86/traps: do not inline do_trap() into 10 different handlers"

Again purely cosmetic - these all aren't trap handlers we expect to
be executed frequently.

> * 3385bf3 "x86: Intel CPU family update"

Again, maybe a candidate for 4.4.

Jan

Re: Backport suggestions for Xen 4.4

[Andrew Cooper]

On 24/06/14 11:38, Jan Beulich wrote:
>>>> On 24.06.14 at 12:23, <andrew.cooper3@citrix.com> wrote:
>> Some further backport suggestions, from the XenServer patch queue.
> Thanks.
>
>> Xen bugfixes:
>> * 415738e "x86/traps: make panic and reboot paths safe during early boot"
>> * d4f88fc "make the main trap handlers safe for use early during Xen boot"
> Honestly I'd rather stay away from backporting these, no matter that
> I'm convinced they're working fine.

There are pre-existing cases where it is possible to crash and attempt
to reboot before sufficiently setting up state for machine_reboot() to
be safe.  In other words, 415738e is genuine bugfix for a real customer
escalation.

>
>> ** including "\n" fix for #MC handler from b30d333
> Purely cosmetic - we're about to die anyway when this message
> gets printed, so it not being printed on its own line is the smallest
> of our problems.
>
>> * 92009d3 "x86/boot: correct CR4 setup on APs"
> This might be acceptable, but would need validation that it really
> addresses in the stable trees what it does in -unstable without the
> other early trap handling changes. The one comment it adds to
> start_secondary() suggests that this might not be the case.

The cr4 problems were completely independent from the early trap
problems, on further consideration this is not quite correct on its own
without the other early trap series (which has been backported into
XenServer)

I can do a backport to 4.4 which resolves the interaction issue with the
early trap series, if that would help.

~Andrew

Re: Backport suggestions for Xen 4.4

[Jan Beulich]

>>> On 24.06.14 at 12:53, <andrew.cooper3@citrix.com> wrote:
> On 24/06/14 11:38, Jan Beulich wrote:
>>>>> On 24.06.14 at 12:23, <andrew.cooper3@citrix.com> wrote:
>>> * 92009d3 "x86/boot: correct CR4 setup on APs"
>> This might be acceptable, but would need validation that it really
>> addresses in the stable trees what it does in -unstable without the
>> other early trap handling changes. The one comment it adds to
>> start_secondary() suggests that this might not be the case.
> 
> The cr4 problems were completely independent from the early trap
> problems, on further consideration this is not quite correct on its own
> without the other early trap series (which has been backported into
> XenServer)
> 
> I can do a backport to 4.4 which resolves the interaction issue with the
> early trap series, if that would help.

Yes, it would help (if you can find the necessary time). But this is not
a promise to take the result... (The other thing causing my hesitance
here is the - iirc - still missing similar adjustment to the S3 resume path.)

Jan