[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 03/18] target/arm: Store FPSR cumulative exception bits in env
From: |
Michael Tokarev |
Subject: |
Re: [PULL 03/18] target/arm: Store FPSR cumulative exception bits in env->vfp.fpsr |
Date: |
Thu, 31 Oct 2024 20:31:51 +0300 |
User-agent: |
Mozilla Thunderbird |
31.10.2024 20:01, Peter Maydell wrote:
On Thu, 31 Oct 2024 at 16:55, Michael Tokarev <mjt@tls.msk.ru> wrote:
29.10.2024 18:10, Peter Maydell wrote:
...
(Note for stable backports: the bug goes back to 4a15527c9fee but
this code was refactored in commits ea8618382aba..a8ab8706d4cc461, so
fixing it in branches without those refactorings will mean either
backporting the refactor or else implementing a conceptually similar
fix for the old code.)
What do you think is the better way here -- pick up the refactoring
changes (to 9.0 and earlier), do a backport of this single fix, or
do nothing? Note for 7.2 branch it probably requires quite a bit
more work.
The bug being fixed here is a bit niche (I don't think many
people build with KVM support only) so I would not worry
about backporting it all the way to 7.2. I'm not sure about
the best approach for 9.0 (which is why I left that note rather
than actively suggestion one or the other) -- it depends whether
you value more "backport the change that's actually been tested
by being in mainline" or "make the minimal set of changes in the
stable branch"...
Aha.
Well.
What I see is that the whole thing - plus one more commit right
before the mentioned refactoring, ea8618382aba, "target/arm: Correct
comments about M-profile FPSCR" - applies cleanly to 9.0 and 8.2.
For 7.2 though, this is definitely too much because there, tcg code
has different rules for the temps, - in particular, it frees all
temps explicitly, so new code wont fit there anyway, resulting in
leaks and requiring major re-review.
Being niche, I'd not bother with that even in 8.2, but the fact
this refactoring applies nicely.. :)
It's probably the first time when the difference between many
changes but tested in master, vs smaller possible change, is quite
significant. I prefer for it to just work ;))
8.2 is in ubuntu noble (LTS), so it might be with us a bit longer
than some other series, but in ubuntu they build with KVM support,
so the bug isn't there.
For 7.2 there's no question anymore.
For 9.0, the next release will be the last one in the series
(unless something changes).
For being really niche, let's pick this single change to 9.1 only,
keeping other series without the fix, for now. Unless there are
other arguments to change this.
I especially thank you for the excellent summary in the patch itself!
/mjt