Re: [PATCH] x86: refine guest_mode()

2020-05-27 Thread Roger Pau Monné
On Tue, May 26, 2020 at 03:55:39PM +0200, Jan Beulich wrote: > On 26.05.2020 12:56, Roger Pau Monné wrote: > > On Fri, May 22, 2020 at 02:00:22PM +0200, Jan Beulich wrote: > >> On 22.05.2020 12:48, Roger Pau Monné wrote: > >>> On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote: > On 2

Re: [PATCH] x86: refine guest_mode()

2020-05-26 Thread Jan Beulich
On 26.05.2020 12:56, Roger Pau Monné wrote: > On Fri, May 22, 2020 at 02:00:22PM +0200, Jan Beulich wrote: >> On 22.05.2020 12:48, Roger Pau Monné wrote: >>> On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote: On 20.05.2020 17:13, Roger Pau Monné wrote: > OK, so I think I'm starti

Re: [PATCH] x86: refine guest_mode()

2020-05-26 Thread Roger Pau Monné
On Fri, May 22, 2020 at 02:00:22PM +0200, Jan Beulich wrote: > On 22.05.2020 12:48, Roger Pau Monné wrote: > > On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote: > >> On 20.05.2020 17:13, Roger Pau Monné wrote: > >>> OK, so I think I'm starting to understand this all. Sorry it's taken > >

Re: [PATCH] x86: refine guest_mode()

2020-05-22 Thread Jan Beulich
On 22.05.2020 12:48, Roger Pau Monné wrote: > On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote: >> On 20.05.2020 17:13, Roger Pau Monné wrote: >>> OK, so I think I'm starting to understand this all. Sorry it's taken >>> me so long. So it's my understanding that diff != 0 can only happen

Re: [PATCH] x86: refine guest_mode()

2020-05-22 Thread Roger Pau Monné
On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote: > On 20.05.2020 17:13, Roger Pau Monné wrote: > > OK, so I think I'm starting to understand this all. Sorry it's taken > > me so long. So it's my understanding that diff != 0 can only happen in > > Xen context, or when in an IST that has

Re: [PATCH] x86: refine guest_mode()

2020-05-22 Thread Jan Beulich
On 20.05.2020 17:13, Roger Pau Monné wrote: > On Wed, May 20, 2020 at 10:56:26AM +0200, Jan Beulich wrote: >> On 18.05.2020 16:51, Roger Pau Monné wrote: >>> On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote: On 27.04.2020 22:11, Andrew Cooper wrote: > On 27/04/2020 16:15, Jan Be

Re: [PATCH] x86: refine guest_mode()

2020-05-20 Thread Roger Pau Monné
On Wed, May 20, 2020 at 10:56:26AM +0200, Jan Beulich wrote: > On 18.05.2020 16:51, Roger Pau Monné wrote: > > On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote: > >> On 27.04.2020 22:11, Andrew Cooper wrote: > >>> On 27/04/2020 16:15, Jan Beulich wrote: > On 27.04.2020 16:35, Andrew

Re: [PATCH] x86: refine guest_mode()

2020-05-20 Thread Jan Beulich
On 18.05.2020 16:51, Roger Pau Monné wrote: > On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote: >> On 27.04.2020 22:11, Andrew Cooper wrote: >>> On 27/04/2020 16:15, Jan Beulich wrote: On 27.04.2020 16:35, Andrew Cooper wrote: > On 27/04/2020 09:03, Jan Beulich wrote: >> ---

Re: [PATCH] x86: refine guest_mode()

2020-05-18 Thread Roger Pau Monné
On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote: > On 27.04.2020 22:11, Andrew Cooper wrote: > > On 27/04/2020 16:15, Jan Beulich wrote: > >> On 27.04.2020 16:35, Andrew Cooper wrote: > >>> On 27/04/2020 09:03, Jan Beulich wrote: > The 2nd of the assertions as well as the macro's r

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Jan Beulich
On 27.04.2020 22:11, Andrew Cooper wrote: > On 27/04/2020 16:15, Jan Beulich wrote: >> On 27.04.2020 16:35, Andrew Cooper wrote: >>> On 27/04/2020 09:03, Jan Beulich wrote: The 2nd of the assertions as well as the macro's return value have been assuming we're on the primary stack. While f

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Andrew Cooper
On 27/04/2020 16:15, Jan Beulich wrote: > On 27.04.2020 16:35, Andrew Cooper wrote: >> On 27/04/2020 09:03, Jan Beulich wrote: >>> The 2nd of the assertions as well as the macro's return value have been >>> assuming we're on the primary stack. While for most IST exceptions we >>> eventually switch

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Roger Pau Monné
On Mon, Apr 27, 2020 at 04:08:59PM +0200, Jan Beulich wrote: > On 27.04.2020 11:59, Roger Pau Monné wrote: > > On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote: > >> --- a/xen/include/asm-x86/regs.h > >> +++ b/xen/include/asm-x86/regs.h > >> @@ -10,9 +10,10 @@ > >> /* Frame pointer

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Jan Beulich
On 27.04.2020 16:35, Andrew Cooper wrote: > On 27/04/2020 09:03, Jan Beulich wrote: >> The 2nd of the assertions as well as the macro's return value have been >> assuming we're on the primary stack. While for most IST exceptions we >> eventually switch back to the main one, > > "we switch to the m

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Andrew Cooper
On 27/04/2020 09:03, Jan Beulich wrote: > The 2nd of the assertions as well as the macro's return value have been > assuming we're on the primary stack. While for most IST exceptions we > eventually switch back to the main one, "we switch to the main one when interrupting user mode". "eventually"

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Jan Beulich
On 27.04.2020 11:59, Roger Pau Monné wrote: > On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote: >> --- a/xen/include/asm-x86/regs.h >> +++ b/xen/include/asm-x86/regs.h >> @@ -10,9 +10,10 @@ >> /* Frame pointer must point into current CPU stack. */ >> \ >> AS

Re: [PATCH] x86: refine guest_mode()

2020-04-27 Thread Roger Pau Monné
On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote: > The 2nd of the assertions as well as the macro's return value have been > assuming we're on the primary stack. While for most IST exceptions we > eventually switch back to the main one, for #DF we intentionally never > do, and hence a #

[PATCH] x86: refine guest_mode()

2020-04-27 Thread Jan Beulich
The 2nd of the assertions as well as the macro's return value have been assuming we're on the primary stack. While for most IST exceptions we eventually switch back to the main one, for #DF we intentionally never do, and hence a #DF actually triggering on a user mode insn (which then is still a Xen