qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tcg/arm: Increase stack alignment for function generation


From: Peter Maydell
Subject: Re: [PATCH] tcg/arm: Increase stack alignment for function generation
Date: Thu, 2 Sep 2021 08:36:56 +0100

On Wed, 1 Sept 2021 at 21:24, Richard W.M. Jones <rjones@redhat.com> wrote:
>
> On Wed, Sep 01, 2021 at 09:17:07PM +0100, Peter Maydell wrote:
> > On Wed, 1 Sept 2021 at 19:51, Richard W.M. Jones <rjones@redhat.com> wrote:
> > >
> > > On Wed, Sep 01, 2021 at 07:41:21PM +0100, Peter Maydell wrote:
> > > > Is the failure case short enough to allow -d ... logging to
> > > > be taken? That's usually the most useful info, but it's so huge
> > > > it's often not feasible.
> > >
> > > I can try -- what exact -d option would be useful?
> >
> > Depends what you're after. Personally I'm fairly sure I know
> > what's going on, I'm just not sure what the right fix is.
>
> Another question: We couldn't reproduce this even with the identical
> ARM guest kernel + initrd + command line using qemu-system-arm
> compiled for x86-64 host.  This was a bit surprising!  Was that bad
> luck or is there some reason why this bug might not be reproducible
> except on armv7 host?  (Both cases use -machine accel=tcg).

That's expected -- this is a bug in the codegen for arm hosts
(specifically 32-bit arm where Neon is available). tcg/i386/
sets TCG_TARGET_STACK_ALIGN to 16, so it won't hit the assert.

Yesterday I wrote:
> The prologue does seem to actively align to the
> specified value, not merely assume-and-preserve that alignment.

but I was misreading the code -- it does just assume-and-preserve.

Do you need an urgent fix/workaround for this? The simplest thing
is to wait for RTH to look at this, which is not likely to be before
the 13th.

Otherwise I think you can work around it with:

--- a/tcg/arm/tcg-target.h
+++ b/tcg/arm/tcg-target.h
@@ -152,7 +152,7 @@ extern bool use_neon_instructions;
 #define TCG_TARGET_HAS_qemu_st8_i32     0

 #define TCG_TARGET_HAS_v64              use_neon_instructions
-#define TCG_TARGET_HAS_v128             use_neon_instructions
+#define TCG_TARGET_HAS_v128             0
 #define TCG_TARGET_HAS_v256             0

 #define TCG_TARGET_HAS_andc_vec         1

though this is just a bodge that (hopefully) turns the use of v128
off entirely.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]