This version passes on FRED, thanks a lot for quickly fixing it.

  Xin

> From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> 
> This is an RFC patchset v5. There are two patches in this series.
> 
> Xin Li reported that the sysret_rip test fails at:
> 
>         assert(ctx->uc_mcontext.gregs[REG_EFL] ==
>                ctx->uc_mcontext.gregs[REG_R11]);
> 
> on the Intel FRED architecture. Let's handle the FRED system scenario too. The
> 'syscall' instruction in a FRED system doesn't set %rcx=%rip and %r11=%rflags.
> 
> Syscall and sysenter in a FRED system are treated equivalently to software
> interrupts, e.g. INT 0x80. They do not modify any registers.
> 
> Link: https://lore.kernel.org/lkml/5d4ad3e3-034f-c7da-d141-
> 9c001c2343af@intel.com
> 
> #### Changelog v5:
> 
>    - Fix do_syscall() return value (Ammar).
> 
> #### Changelog v4:
> 
>    - Fix the assertion condition inside the SIGUSR1 handler (Xin Li).
> 
>    - Explain the purpose of patch #2 in the commit message (HPA).
> 
>    - Update commit message (Ammar).
> 
>    - Repeat test_syscall_rcx_r11_consistent() 32 times to be more sure
>      that the result is really consistent (Ammar).
> 
> #### Changelog v3:
> 
>    - Test that we don't get a mix of REGS_SAVED and REGS_SYSRET,
>      which is a major part of the point (HPA).
> 
> #### Changelog v2:
> 
>    - Use "+r"(rsp) as the right way to avoid redzone problems
>      per Andrew's comment (HPA).
> 
> 
> Co-developed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> ---
> 
> Ammar Faizi (2):
>   selftests/x86: sysret_rip: Handle syscall in a FRED system
>   selftests/x86: sysret_rip: Add more syscall tests with respect to `%rcx` and `%r11`
> 
>  tools/testing/selftests/x86/sysret_rip.c | 146 +++++++++++++++++++++--
>  1 file changed, 137 insertions(+), 9 deletions(-)
> 
> 
> base-commit: e12ad468c22065a2826b2fc4c11d2113a7975301
> --
> Ammar Faizi

On Wed, Jan 25, 2023 at 08:22:48AM +0000, Li, Xin3 wrote:
> This version passes on FRED, thanks a lot for quickly fixing it.

Great!

Can you pick these two patches and include it in the next version of
"x86: enable FRED for x86-64" RFC patchset?

-- 
Ammar Faizi

> > This version passes on FRED, thanks a lot for quickly fixing it.
> 
> Great!
> 
> Can you pick these two patches and include it in the next version of
> "x86: enable FRED for x86-64" RFC patchset?

Would it be better to get this patch set merged first?

Otherwise surely I will include it in the FRED patch set.

  Xin

 

On January 25, 2023 9:07:18 AM PST, "Li, Xin3" <xin3.li@intel.com> wrote:
>> > This version passes on FRED, thanks a lot for quickly fixing it.
>> 
>> Great!
>> 
>> Can you pick these two patches and include it in the next version of
>> "x86: enable FRED for x86-64" RFC patchset?
>
>Would it be better to get this patch set merged first?
>
>Otherwise surely I will include it in the FRED patch set.
>
>  Xin
>
> 
>

If the maintainers are ok with it, it would be better to merge it sooner: once we have agreed on the semantics, which I believe we have, we should be testing those semantics and nothing else.

On Wed, Jan 25, 2023 at 09:24:40AM -0800, H. Peter Anvin wrote:
> On January 25, 2023 9:07:18 AM PST, "Li, Xin3" <xin3.li@intel.com> wrote:
> > Would it be better to get this patch set merged first?
> > 
> > Otherwise surely I will include it in the FRED patch set.
> 
> If the maintainers are ok with it, it would be better to merge it
> sooner: once we have agreed on the semantics, which I believe we
> have, we should be testing those semantics and nothing else.

OK, let's keep this patchset separated from the FRED support
patchset.

In the meantime, let me address the recent HPA's comments.

-- 
Ammar Faizi

> > > Would it be better to get this patch set merged first?
> > >
> > > Otherwise surely I will include it in the FRED patch set.
> >
> > If the maintainers are ok with it, it would be better to merge it
> > sooner: once we have agreed on the semantics, which I believe we have,
> > we should be testing those semantics and nothing else.
> 
> OK, let's keep this patchset separated from the FRED support patchset.

Thanks!

This patch set first makes the R11/RCX semantics clearer, and it BTW fixes
FRED tests.

To me it's more of an improvement to the existing code.

> > > > Would it be better to get this patch set merged first?
> > > >
> > > > Otherwise surely I will include it in the FRED patch set.
> > >
> > > If the maintainers are ok with it, it would be better to merge it
> > > sooner: once we have agreed on the semantics, which I believe we
> > > have, we should be testing those semantics and nothing else.
> >
> > OK, let's keep this patchset separated from the FRED support patchset.
> 
> Thanks!
> 
> This patch set first makes the R11/RCX semantics clearer, and it BTW fixes FRED
> tests.
> 
> To me it's more of an improvement to the existing code.

Hi Faizi,

Any update on this patch set?

Thanks!
Xin

On Wed, Feb 15, 2023 at 07:42:47AM +0000, Li, Xin3 wrote:
> Hi Faizi,
> 
> Any update on this patch set?

No comment from HPA. But after the recent discussion with Andrew, I
think at least it's now clear that we are not going to use "+r"(rsp) to
avoid the red zone problem.

I am on leave today. Will send revision v8 on Monday.

Thanks,

-- 
Ammar Faizi

On February 17, 2023 8:27:40 PM PST, Ammar Faizi <ammarfaizi2@gnuweeb.org> wrote:
>On Wed, Feb 15, 2023 at 07:42:47AM +0000, Li, Xin3 wrote:
>> Hi Faizi,
>> 
>> Any update on this patch set?
>
>No comment from HPA. But after the recent discussion with Andrew, I
>think at least it's now clear that we are not going to use "+r"(rsp) to
>avoid the red zone problem.
>
>I am on leave today. Will send revision v8 on Monday.
>
>Thanks,
>

My apologies, I missed your latest response in the torrent of email. The redzone issue is weird; it ought to be breaking all over the place, not just this.

Let me take a quick look at it...

On Wed, Feb 15, 2023 at 07:42:47AM +0000, Li, Xin3 wrote:
> Hi Faizi,
> 
> Any update on this patch set?

Xin,

Before I send the next version, I need an answer for this one:
https://lore.kernel.org/lkml/Y9LfmQ%2Fr1%2FpEP+uv@biznet-home.integral.gnuweeb.org/

I don't think the redzone problem is handled correctly here. Using
"+r" (rsp) constraint doesn't solve the redzone problem.

HPA, Andrew, anybody?

-- 
Ammar Faizi