preparations 4.7.3 and 4.6.6

preparations 4.7.3 and 4.6.6

[Jan Beulich]

All,

with the goal of releasing in about 3 weeks time, please point out
backport candidates you find missing from the respective staging
branches, but which you consider relevant. Please note that 4.6.6
is expected to be the last xenproject.org managed release from
its branch.

Andrew, I think I had seen you offer taking care of backports of
one or both of

5c4f579e0e x86/pv: Fix the handling of `int $x` for vectors which alias exceptions
a0b40c3e08 x86/pagewalk: Fix pagewalk's handling of instruction fetches
(its prereq revert 224acdd04a backports easily to at least 4.8,
but we don't want to apply that alone, obviously)

Was that meant for just 4.8, or also one or both of these older
branches?

Jan


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

Re: preparations 4.7.3 and 4.6.6

[Andrew Cooper]

On 09/06/17 13:07, Jan Beulich wrote:
> All,
>
> with the goal of releasing in about 3 weeks time, please point out
> backport candidates you find missing from the respective staging
> branches, but which you consider relevant. Please note that 4.6.6
> is expected to be the last xenproject.org managed release from
> its branch.
>
> Andrew, I think I had seen you offer taking care of backports of
> one or both of
>
> 5c4f579e0e x86/pv: Fix the handling of `int $x` for vectors which alias exceptions
> a0b40c3e08 x86/pagewalk: Fix pagewalk's handling of instruction fetches
> (its prereq revert 224acdd04a backports easily to at least 4.8,
> but we don't want to apply that alone, obviously)
>
> Was that meant for just 4.8, or also one or both of these older
> branches?

I can arrange the backport of `int $x`.

The prereq revert is fine for backport to 4.7 (which was when the change
was introduced.

The general pagewalk code on the other hand is a different matter. 
There are ~70 prerequisite patches to backport it to 4.8, starting with
the 23 System Segment Emulation changes at the very beginning of the 4.9
dev cycle.

Much as I'd like to see the pagewalk problems fixed in earlier releases,
the risk of doing so is quite high if we fail to disentangle the
prerequisites properly.  OTOH, I do have a comprehensive unit test which
raises confidence in the end result.  Then again, there are still two
outstanding pagewalking bugs I am aware of which are unfixed in staging
(and why this XTF test isn't running in general automation yet).

~Andrew

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

Re: preparations 4.7.3 and 4.6.6

[Jan Beulich]

>>> On 09.06.17 at 14:22, <andrew.cooper3@citrix.com> wrote:
> On 09/06/17 13:07, Jan Beulich wrote:
>> All,
>>
>> with the goal of releasing in about 3 weeks time, please point out
>> backport candidates you find missing from the respective staging
>> branches, but which you consider relevant. Please note that 4.6.6
>> is expected to be the last xenproject.org managed release from
>> its branch.
>>
>> Andrew, I think I had seen you offer taking care of backports of
>> one or both of
>>
>> 5c4f579e0e x86/pv: Fix the handling of `int $x` for vectors which alias 
> exceptions
>> a0b40c3e08 x86/pagewalk: Fix pagewalk's handling of instruction fetches
>> (its prereq revert 224acdd04a backports easily to at least 4.8,
>> but we don't want to apply that alone, obviously)
>>
>> Was that meant for just 4.8, or also one or both of these older
>> branches?
> 
> I can arrange the backport of `int $x`.

Thanks.

> The prereq revert is fine for backport to 4.7 (which was when the change
> was introduced.

You mean - other than I've indicated - without the follow-up
also backported? Rather not I would say ...

> The general pagewalk code on the other hand is a different matter. 
> There are ~70 prerequisite patches to backport it to 4.8, starting with
> the 23 System Segment Emulation changes at the very beginning of the 4.9
> dev cycle.
> 
> Much as I'd like to see the pagewalk problems fixed in earlier releases,
> the risk of doing so is quite high if we fail to disentangle the
> prerequisites properly.  OTOH, I do have a comprehensive unit test which
> raises confidence in the end result.  Then again, there are still two
> outstanding pagewalking bugs I am aware of which are unfixed in staging
> (and why this XTF test isn't running in general automation yet).

No, I certainly don't see us backporting this whole lot. The question
was whether this one change can be sensibly backported on its own.
But I take your reply to mean "rather not".

Jan


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

Re: preparations 4.7.3 and 4.6.6

[Andrew Cooper]

On 09/06/17 13:47, Jan Beulich wrote:
>
>> The prereq revert is fine for backport to 4.7 (which was when the change
>> was introduced.
> You mean - other than I've indicated - without the follow-up
> also backported?

The two patches are logically independent.  They were presented as a
series because I found and fixed them at the same time, but they aren't
functionally related.

~Andrew

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

Re: preparations 4.7.3 and 4.6.6

[Wei Liu]

On Fri, Jun 09, 2017 at 06:07:56AM -0600, Jan Beulich wrote:
> All,
> 
> with the goal of releasing in about 3 weeks time, please point out
> backport candidates you find missing from the respective staging
> branches, but which you consider relevant. Please note that 4.6.6
> is expected to be the last xenproject.org managed release from
> its branch.

I don't think I have any backport to do. Please let me know when I
should tag the tree.

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

Re: preparations 4.7.3 and 4.6.6

[Lars Kurth]

Hi all,
I am not going to be able to do the website work until Monday, as
travelling until late Friday
Lars

On 20/06/2017, 20:51, "Wei Liu" <wei.liu2@citrix.com> wrote:

>On Fri, Jun 09, 2017 at 06:07:56AM -0600, Jan Beulich wrote:
>> All,
>> 
>> with the goal of releasing in about 3 weeks time, please point out
>> backport candidates you find missing from the respective staging
>> branches, but which you consider relevant. Please note that 4.6.6
>> is expected to be the last xenproject.org managed release from
>> its branch.
>
>I don't think I have any backport to do. Please let me know when I
>should tag the tree.

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

[PATCH for-4.8] x86/pv: Fix the handling of `int $x` for vectors which alias exceptions

[Andrew Cooper]

The claim at the top of c/s 2e426d6eecf "x86/traps: Drop use_error_code
parameter from do_{,guest_}trap()" is only actually true for hardware
exceptions.  It is not true for `int $x` instructions (which never push error
code), irrespective of whether the vector aliases an exception or not.

Furthermore, c/s 6480cc6280e "x86/traps: Fix failed ASSERT() in
do_guest_trap()" really should have helped highlight that a regression had
been introduced.

Modify pv_inject_event() to understand event types other than
X86_EVENTTYPE_HW_EXCEPTION, and introduce pv_inject_sw_interrupt() for the
`int $x` handling code.

Add further assertions to pv_inject_event() concerning the type of events
passed in, which in turn requires that do_guest_trap() set its type
appropriately (which is now used exclusively for hardware exceptions).

This is logically a backport of c/s 5c4f579e0ee4f38cad5636bbf8ce700a394338d0
from Xen 4.9, but disentangled from the other injection work.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/x86/traps.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 19ac652..8c992ce 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -625,14 +625,24 @@ void fatal_trap(const struct cpu_user_regs *regs, bool_t show_remote)
           (regs->eflags & X86_EFLAGS_IF) ? "" : ", IN INTERRUPT CONTEXT");
 }
 
-static void do_guest_trap(unsigned int trapnr,
-                          const struct cpu_user_regs *regs)
+static void pv_inject_event(
+    unsigned int trapnr, const struct cpu_user_regs *regs, unsigned int type)
 {
     struct vcpu *v = current;
     struct trap_bounce *tb;
     const struct trap_info *ti;
-    const bool use_error_code =
-        ((trapnr < 32) && (TRAP_HAVE_EC & (1u << trapnr)));
+    bool use_error_code;
+
+    if ( type == X86_EVENTTYPE_HW_EXCEPTION )
+    {
+        ASSERT(trapnr < 32);
+        use_error_code = TRAP_HAVE_EC & (1u << trapnr);
+    }
+    else
+    {
+        ASSERT(type == X86_EVENTTYPE_SW_INTERRUPT);
+        use_error_code = false;
+    }
 
     trace_pv_trap(trapnr, regs->eip, use_error_code, regs->error_code);
 
@@ -658,6 +668,12 @@ static void do_guest_trap(unsigned int trapnr,
                 trapstr(trapnr), trapnr, regs->error_code);
 }
 
+static void do_guest_trap(
+    unsigned int trapnr, const struct cpu_user_regs *regs)
+{
+    pv_inject_event(trapnr, regs, X86_EVENTTYPE_HW_EXCEPTION);
+}
+
 static void instruction_done(
     struct cpu_user_regs *regs, unsigned long eip, unsigned int bpmatch)
 {
@@ -3685,7 +3701,7 @@ void do_general_protection(struct cpu_user_regs *regs)
         if ( permit_softint(TI_GET_DPL(ti), v, regs) )
         {
             regs->eip += 2;
-            do_guest_trap(vector, regs);
+            pv_inject_event(vector, regs, X86_EVENTTYPE_SW_INTERRUPT);
             return;
         }
     }
-- 
2.1.4


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

Re: [PATCH for-4.8] x86/pv: Fix the handling of `int $x` for vectors which alias exceptions

[Jan Beulich]

>>> On 22.06.17 at 21:12, <andrew.cooper3@citrix.com> wrote:
> The claim at the top of c/s 2e426d6eecf "x86/traps: Drop use_error_code
> parameter from do_{,guest_}trap()" is only actually true for hardware
> exceptions.  It is not true for `int $x` instructions (which never push error
> code), irrespective of whether the vector aliases an exception or not.
> 
> Furthermore, c/s 6480cc6280e "x86/traps: Fix failed ASSERT() in
> do_guest_trap()" really should have helped highlight that a regression had
> been introduced.
> 
> Modify pv_inject_event() to understand event types other than
> X86_EVENTTYPE_HW_EXCEPTION, and introduce pv_inject_sw_interrupt() for the
> `int $x` handling code.
> 
> Add further assertions to pv_inject_event() concerning the type of events
> passed in, which in turn requires that do_guest_trap() set its type
> appropriately (which is now used exclusively for hardware exceptions).
> 
> This is logically a backport of c/s 5c4f579e0ee4f38cad5636bbf8ce700a394338d0
> from Xen 4.9, but disentangled from the other injection work.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks, applied.

Jan


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