| Message ID | 20230125034958.734527-1-ammarfaizi2@gnuweeb.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | sysret_rip update for the Intel FRED architecture | expand |
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?
> > 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.
> > > 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? 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?
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,
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...