1. Patchew
  2. QEMU
  3. View series

[PATCH] tcg/arm: Reduce vector alignment requirement for NEON

Richard Henderson posted 1 patch 2 years, 7 months ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20210912174925.200132-1-richard.henderson@linaro.org
Maintainers: Richard Henderson <richard.henderson@linaro.org>
There is a newer version of this series
tcg/tcg.c                |  8 +++++++-
tcg/arm/tcg-target.c.inc | 13 +++++++++----
2 files changed, 16 insertions(+), 5 deletions(-)
[PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Richard Henderson 2 years, 7 months ago 
With arm32, the ABI gives us 8-byte alignment for the stack.
While it's possible to realign the stack to provide 16-byte alignment,
it's far easier to simply not encode 16-byte alignment in the
VLD1 and VST1 instructions that we emit.

Remove the assertion in temp_allocate_frame, limit natural alignment
to the provided stack alignment, and add a comment.

Reported-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---

I haven't seen the assertion with the various arm kernels that I happen
to have laying about.  I have not taken the time to build the combo
from the bug report:

[    0.000000] Linux version 5.14.0-60.fc36.armv7hl (mockbuild@buildvm-a32-12.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.37-9.fc36) #1 SMP Mon Aug 30 14:08:34 UTC 2021

I thought about parameterizing this patch further, but I can't think of
another ISA that would be affected.  (i686 clumsily changed its abi 20
years ago to avoid faulting on vector spills; other isas so far have
allowed vectors to be unaligned.)


r~
---
 tcg/tcg.c                |  8 +++++++-
 tcg/arm/tcg-target.c.inc | 13 +++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 4142d42d77..ca5bcc4635 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -3060,7 +3060,13 @@ static void temp_allocate_frame(TCGContext *s, TCGTemp *ts)
         g_assert_not_reached();
     }
 
-    assert(align <= TCG_TARGET_STACK_ALIGN);
+    /*
+     * Assume the stack is sufficiently aligned.
+     * This affects e.g. ARM NEON, where we have 8 byte stack alignment
+     * and do not require 16 byte vector alignment.  This seems slightly
+     * easier than fully parameterizing the above switch statement.
+     */
+    align = MIN(TCG_TARGET_STACK_ALIGN, align);
     off = ROUND_UP(s->current_frame_offset, align);
 
     /* If we've exhausted the stack frame, restart with a smaller TB. */
diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index e5b4f86841..8515717435 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -2477,8 +2477,13 @@ static void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg,
         tcg_out_vldst(s, INSN_VLD1 | 0x7d0, arg, arg1, arg2);
         return;
     case TCG_TYPE_V128:
-        /* regs 2; size 8; align 16 */
-        tcg_out_vldst(s, INSN_VLD1 | 0xae0, arg, arg1, arg2);
+        /*
+         * We have only 8-byte alignment for the stack per the ABI.
+         * Rather than dynamically re-align the stack, it's easier
+         * to simply not request alignment beyond that.  So:
+         * regs 2; size 8; align 8
+         */
+        tcg_out_vldst(s, INSN_VLD1 | 0xad0, arg, arg1, arg2);
         return;
     default:
         g_assert_not_reached();
@@ -2497,8 +2502,8 @@ static void tcg_out_st(TCGContext *s, TCGType type, TCGReg arg,
         tcg_out_vldst(s, INSN_VST1 | 0x7d0, arg, arg1, arg2);
         return;
     case TCG_TYPE_V128:
-        /* regs 2; size 8; align 16 */
-        tcg_out_vldst(s, INSN_VST1 | 0xae0, arg, arg1, arg2);
+        /* See tcg_out_ld re alignment: regs 2; size 8; align 8 */
+        tcg_out_vldst(s, INSN_VST1 | 0xad0, arg, arg1, arg2);
         return;
     default:
         g_assert_not_reached();
-- 
2.25.1
Re: [PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Richard W.M. Jones 2 years, 7 months ago 
On Sun, Sep 12, 2021 at 10:49:25AM -0700, Richard Henderson wrote:
> With arm32, the ABI gives us 8-byte alignment for the stack.
> While it's possible to realign the stack to provide 16-byte alignment,
> it's far easier to simply not encode 16-byte alignment in the
> VLD1 and VST1 instructions that we emit.
> 
> Remove the assertion in temp_allocate_frame, limit natural alignment
> to the provided stack alignment, and add a comment.
> 
> Reported-by: Richard W.M. Jones <rjones@redhat.com>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> 
> I haven't seen the assertion with the various arm kernels that I happen
> to have laying about.  I have not taken the time to build the combo
> from the bug report:
> 
> [    0.000000] Linux version 5.14.0-60.fc36.armv7hl (mockbuild@buildvm-a32-12.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.37-9.fc36) #1 SMP Mon Aug 30 14:08:34 UTC 2021
> 
> I thought about parameterizing this patch further, but I can't think of
> another ISA that would be affected.  (i686 clumsily changed its abi 20
> years ago to avoid faulting on vector spills; other isas so far have
> allowed vectors to be unaligned.)

You should be able to download the Fedora kernel that I am using from
https://koji.fedoraproject.org/koji/packageinfo?packageID=8

I added the patch to Fedora qemu and will do a test build once it
becomes available to build against - currently there's some problem
with new builds not propagating to the new buildroot.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
Re: [PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Richard W.M. Jones 2 years, 7 months ago 
On Sun, Sep 12, 2021 at 10:49:25AM -0700, Richard Henderson wrote:
> With arm32, the ABI gives us 8-byte alignment for the stack.
> While it's possible to realign the stack to provide 16-byte alignment,
> it's far easier to simply not encode 16-byte alignment in the
> VLD1 and VST1 instructions that we emit.
> 
> Remove the assertion in temp_allocate_frame, limit natural alignment
> to the provided stack alignment, and add a comment.
> 
> Reported-by: Richard W.M. Jones <rjones@redhat.com>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> 
> I haven't seen the assertion with the various arm kernels that I happen
> to have laying about.  I have not taken the time to build the combo
> from the bug report:
> 
> [    0.000000] Linux version 5.14.0-60.fc36.armv7hl (mockbuild@buildvm-a32-12.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.37-9.fc36) #1 SMP Mon Aug 30 14:08:34 UTC 2021
> 
> I thought about parameterizing this patch further, but I can't think of
> another ISA that would be affected.  (i686 clumsily changed its abi 20
> years ago to avoid faulting on vector spills; other isas so far have
> allowed vectors to be unaligned.)

Is it possible this change could have caused a more serious
regression?  Now when I try to boot the Fedora kernel using TCG on
armv7hl I can't even get to the point where it detects virtio-scsi
devices.

Full log is here (go down to the bottom and work backwards):

  https://kojipkgs.fedoraproject.org//work/tasks/7337/75597337/build.log

This might have been caused by a coincidental change to the kernel.
The test environment I have makes it extremely difficult to test this
change in isolation.

However I do know that the same error does _not_ occur on x86-64
guest/host with this patch applied.

Rich.

> 
> r~
> ---
>  tcg/tcg.c                |  8 +++++++-
>  tcg/arm/tcg-target.c.inc | 13 +++++++++----
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 4142d42d77..ca5bcc4635 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -3060,7 +3060,13 @@ static void temp_allocate_frame(TCGContext *s, TCGTemp *ts)
>          g_assert_not_reached();
>      }
>  
> -    assert(align <= TCG_TARGET_STACK_ALIGN);
> +    /*
> +     * Assume the stack is sufficiently aligned.
> +     * This affects e.g. ARM NEON, where we have 8 byte stack alignment
> +     * and do not require 16 byte vector alignment.  This seems slightly
> +     * easier than fully parameterizing the above switch statement.
> +     */
> +    align = MIN(TCG_TARGET_STACK_ALIGN, align);
>      off = ROUND_UP(s->current_frame_offset, align);
>  
>      /* If we've exhausted the stack frame, restart with a smaller TB. */
> diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
> index e5b4f86841..8515717435 100644
> --- a/tcg/arm/tcg-target.c.inc
> +++ b/tcg/arm/tcg-target.c.inc
> @@ -2477,8 +2477,13 @@ static void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg,
>          tcg_out_vldst(s, INSN_VLD1 | 0x7d0, arg, arg1, arg2);
>          return;
>      case TCG_TYPE_V128:
> -        /* regs 2; size 8; align 16 */
> -        tcg_out_vldst(s, INSN_VLD1 | 0xae0, arg, arg1, arg2);
> +        /*
> +         * We have only 8-byte alignment for the stack per the ABI.
> +         * Rather than dynamically re-align the stack, it's easier
> +         * to simply not request alignment beyond that.  So:
> +         * regs 2; size 8; align 8
> +         */
> +        tcg_out_vldst(s, INSN_VLD1 | 0xad0, arg, arg1, arg2);
>          return;
>      default:
>          g_assert_not_reached();
> @@ -2497,8 +2502,8 @@ static void tcg_out_st(TCGContext *s, TCGType type, TCGReg arg,
>          tcg_out_vldst(s, INSN_VST1 | 0x7d0, arg, arg1, arg2);
>          return;
>      case TCG_TYPE_V128:
> -        /* regs 2; size 8; align 16 */
> -        tcg_out_vldst(s, INSN_VST1 | 0xae0, arg, arg1, arg2);
> +        /* See tcg_out_ld re alignment: regs 2; size 8; align 8 */
> +        tcg_out_vldst(s, INSN_VST1 | 0xad0, arg, arg1, arg2);
>          return;
>      default:
>          g_assert_not_reached();
> -- 
> 2.25.1

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
Re: [PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Richard Henderson 2 years, 7 months ago 
On 9/13/21 4:07 AM, Richard W.M. Jones wrote:
>> [    0.000000] Linux version 5.14.0-60.fc36.armv7hl (mockbuild@buildvm-a32-12.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.37-9.fc36) #1 SMP Mon Aug 30 14:08:34 UTC 2021
>>
>> I thought about parameterizing this patch further, but I can't think of
>> another ISA that would be affected.  (i686 clumsily changed its abi 20
>> years ago to avoid faulting on vector spills; other isas so far have
>> allowed vectors to be unaligned.)
> 
> Is it possible this change could have caused a more serious
> regression?

I don't think so...

> Now when I try to boot the Fedora kernel using TCG on
> armv7hl I can't even get to the point where it detects virtio-scsi
> devices.
> 
> Full log is here (go down to the bottom and work backwards):
> 
>    https://kojipkgs.fedoraproject.org//work/tasks/7337/75597337/build.log

I downloaded the 5.14.0-60 kernel from above, and I can reproduce the original error, and 
I see that it's fixed afterward.

I'll have a look at this new build log in a moment...


r~
Re: [PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Richard W.M. Jones 2 years, 7 months ago 
On Mon, Sep 13, 2021 at 09:19:22AM -0700, Richard Henderson wrote:
> On 9/13/21 4:07 AM, Richard W.M. Jones wrote:
> >>[    0.000000] Linux version 5.14.0-60.fc36.armv7hl (mockbuild@buildvm-a32-12.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.37-9.fc36) #1 SMP Mon Aug 30 14:08:34 UTC 2021
> >>
> >>I thought about parameterizing this patch further, but I can't think of
> >>another ISA that would be affected.  (i686 clumsily changed its abi 20
> >>years ago to avoid faulting on vector spills; other isas so far have
> >>allowed vectors to be unaligned.)
> >
> >Is it possible this change could have caused a more serious
> >regression?
> 
> I don't think so...
> 
> >Now when I try to boot the Fedora kernel using TCG on
> >armv7hl I can't even get to the point where it detects virtio-scsi
> >devices.
> >
> >Full log is here (go down to the bottom and work backwards):
> >
> >   https://kojipkgs.fedoraproject.org//work/tasks/7337/75597337/build.log
> 
> I downloaded the 5.14.0-60 kernel from above, and I can reproduce
> the original error, and I see that it's fixed afterward.

Thanks for checking that.  I did spend much of today attempting to get
an armv7 guest installed on my RPi so I could reproduce this more
reliably, but eventually gave up because of a variety of other
problems (one apparently in qemu: https://bugzilla.redhat.com/1633328)

> I'll have a look at this new build log in a moment...
> 
> 
> r~

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
Re: [PATCH] tcg/arm: Reduce vector alignment requirement for NEON
Posted by Peter Maydell 2 years, 7 months ago 
On Mon, 13 Sept 2021 at 17:28, Richard W.M. Jones <rjones@redhat.com> wrote:
> Thanks for checking that.  I did spend much of today attempting to get
> an armv7 guest installed on my RPi so I could reproduce this more
> reliably, but eventually gave up because of a variety of other
> problems (one apparently in qemu: https://bugzilla.redhat.com/1633328)

That bug looks like it's the old "if you have an old non-LPAE
guest kernel you need to tell QEMU '-machine highmem=off' now".
So you can either do that, or use an LPAE kernel...

-- PMM

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.