[RFC PATCH 0/3] target/i386: Reorg push/pop within seg_helper.c

Richard Henderson posted 3 patches 5 months, 1 week ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20240617161210.4639-1-richard.henderson@linaro.org
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Eduardo Habkost <eduardo@habkost.net>
target/i386/cpu.h            |  12 +-
target/i386/cpu.c            |  27 +-
target/i386/tcg/seg_helper.c | 469 +++++++++++++++++++----------------
3 files changed, 280 insertions(+), 228 deletions(-)
[RFC PATCH 0/3] target/i386: Reorg push/pop within seg_helper.c
Posted by Richard Henderson 5 months, 1 week ago
Hi Paolo,

Thanks for offering to do the work to fix the memory access issues
identified by Robert.

Here is a code dump from this weekend that I noodled with -- it is
prep work only, not intending to change any semantics, but it may
be helpful in finishing the work.

I considered adding a MemOp member to the structure, which would
allow the push/pop subroutine to choose the correct access width,
which would allow the callers to stop having 3 nearly identical
code paths.  But I didn't quite get that far, and I don't yet
know if that would really work out wrt long-mode.

Anyway, please you what you like, or not.


r~


Richard Henderson (3):
  target/i386: Introduce x86_mmu_index_{kernel_,}pl
  target/i386: Remove SEG_ADDL
  target/i386: Reorg push/pop within seg_helper.c

 target/i386/cpu.h            |  12 +-
 target/i386/cpu.c            |  27 +-
 target/i386/tcg/seg_helper.c | 469 +++++++++++++++++++----------------
 3 files changed, 280 insertions(+), 228 deletions(-)

-- 
2.34.1
Re: [RFC PATCH 0/3] target/i386: Reorg push/pop within seg_helper.c
Posted by Paolo Bonzini 5 months, 1 week ago
On Mon, Jun 17, 2024 at 6:12 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Hi Paolo,
>
> Thanks for offering to do the work to fix the memory access issues
> identified by Robert.
>
> Here is a code dump from this weekend that I noodled with -- it is
> prep work only, not intending to change any semantics, but it may
> be helpful in finishing the work.
>
> I considered adding a MemOp member to the structure, which would
> allow the push/pop subroutine to choose the correct access width,
> which would allow the callers to stop having 3 nearly identical
> code paths.  But I didn't quite get that far, and I don't yet
> know if that would really work out wrt long-mode.

Thanks, I had something working but your patch 3 is definitely
prettier so I'll just rebase on top of these three.

Paolo