| Message ID | 20230528164922.20364-1-danielhb413@gmail.com |
|---|---|
| State | New |
| Headers | show |
28.05.2023 19:49, Daniel Henrique Barboza wrote: > > https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20230528 > > ppc patch queue for 2023-05-28: > > This queue includes several assorted fixes for PowerPC SPR > emulation, a change in the default Pegasos2 CPU, the addition > of AIL mode 3 for spapr, a PIC->CPU interrupt fix for prep and > performance enhancements in fpu_helper.c. From the patch description, it looks like the following changes are suitable for -stable: 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs 02/10 target/ppc: Fix width of some 32-bit SPRs 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt Or are these not important for -stable? Or maybe there are other changes which should be picked too? Please add "Cc: qemu-stable@nongnu.org" tag for the future patches which needs to be backported to previous/stable version of qemu. Thanks! /mjt > --------------------------------------------------------------- > Alexander Bulekov (1): > pnv_lpc: disable reentrancy detection for lpc-hc > > BALATON Zoltan (1): > ppc/pegasos2: Change default CPU to 7457 > > Bernhard Beschow (1): > hw/ppc/prep: Fix wiring of PIC -> CPU interrupt > > Nicholas Piggin (5): > target/ppc: Fix width of some 32-bit SPRs > target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward > spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall > target/ppc: Use SMT4 small core chip type in POWER9/10 PVRs > target/ppc: Add POWER9 DD2.2 model > > Richard Henderson (1): > target/ppc: Merge COMPUTE_CLASS and COMPUTE_FPRF > > Richard Purdie (1): > target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs >
On Mon May 29, 2023 at 3:36 AM AEST, Michael Tokarev wrote: > 28.05.2023 19:49, Daniel Henrique Barboza wrote: > > > > https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20230528 > > > > ppc patch queue for 2023-05-28: > > > > This queue includes several assorted fixes for PowerPC SPR > > emulation, a change in the default Pegasos2 CPU, the addition > > of AIL mode 3 for spapr, a PIC->CPU interrupt fix for prep and > > performance enhancements in fpu_helper.c. > > From the patch description, it looks like the following changes > are suitable for -stable: > > 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs > 02/10 target/ppc: Fix width of some 32-bit SPRs > 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward > 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt > > Or are these not important for -stable? Or maybe there are other changes > which should be picked too? They certainly fix some parts of target emulation, but what is the guidance for backporting those type of fixes? Most of the patches I sent including 2,3 were just found from inspection or new test code and not real software failing. Should just simple ones go in? 32-bit SPRs do not fix entirely the behaviour of all SPRs, just one aspect. In another fix I had (that didn't make it in this merge), was a bit more complicated and the first iteration caused a deadlock that didn't show up in basic test like booting Linux. My guess is that fixes that correct an issue with real software running on the target should be ported to stable. Perhaps "obviously correct" small fixes as well. But not sure about larger changes. Thanks, Nick
29.05.2023 05:18, Nicholas Piggin wrote: .. >> 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs >> 02/10 target/ppc: Fix width of some 32-bit SPRs >> 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward >> 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt >> >> Or are these not important for -stable? Or maybe there are other changes >> which should be picked too? > > They certainly fix some parts of target emulation, but what is the > guidance for backporting those type of fixes? Most of the patches I sent > including 2,3 were just found from inspection or new test code and not > real software failing. > > Should just simple ones go in? 32-bit SPRs do not fix entirely the > behaviour of all SPRs, just one aspect. In another fix I had (that > didn't make it in this merge), was a bit more complicated and the > first iteration caused a deadlock that didn't show up in basic test > like booting Linux. > > My guess is that fixes that correct an issue with real software running > on the target should be ported to stable. Perhaps "obviously correct" > small fixes as well. But not sure about larger changes. This is exactly why I asked, - because I don't clearly understand how important these to have in -stable. And also to remind that -stable exist, just in case.. ;) So be it, no actual issue so not applying to -stable. Thank you for the clarification! /mjt
On Mon May 29, 2023 at 4:01 PM AEST, Michael Tokarev wrote: > 29.05.2023 05:18, Nicholas Piggin wrote: > .. > > >> 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs > >> 02/10 target/ppc: Fix width of some 32-bit SPRs > >> 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward > >> 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt > >> > >> Or are these not important for -stable? Or maybe there are other changes > >> which should be picked too? > > > > They certainly fix some parts of target emulation, but what is the > > guidance for backporting those type of fixes? Most of the patches I sent > > including 2,3 were just found from inspection or new test code and not > > real software failing. > > > > Should just simple ones go in? 32-bit SPRs do not fix entirely the > > behaviour of all SPRs, just one aspect. In another fix I had (that > > didn't make it in this merge), was a bit more complicated and the > > first iteration caused a deadlock that didn't show up in basic test > > like booting Linux. > > > > My guess is that fixes that correct an issue with real software running > > on the target should be ported to stable. Perhaps "obviously correct" > > small fixes as well. But not sure about larger changes. > > This is exactly why I asked, - because I don't clearly understand how > important these to have in -stable. And also to remind that -stable > exist, just in case.. ;) Ah okay, makes sense. I was just clarifying myself since I wasn't too sure. > So be it, no actual issue so not applying to -stable. I will think about it and try to keep -stable in mind. Of my patches there are one or two coming up that could probably go in there, if not these ones. Thanks, Nick
On Mon, 2023-05-29 at 16:30 +1000, Nicholas Piggin wrote: > On Mon May 29, 2023 at 4:01 PM AEST, Michael Tokarev wrote: > > 29.05.2023 05:18, Nicholas Piggin wrote: > > .. > > > > > > 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs > > > > 02/10 target/ppc: Fix width of some 32-bit SPRs > > > > 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward > > > > 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt > > > > > > > > Or are these not important for -stable? Or maybe there are other changes > > > > which should be picked too? > > > > > > They certainly fix some parts of target emulation, but what is the > > > guidance for backporting those type of fixes? Most of the patches I sent > > > including 2,3 were just found from inspection or new test code and not > > > real software failing. > > > > > > Should just simple ones go in? 32-bit SPRs do not fix entirely the > > > behaviour of all SPRs, just one aspect. In another fix I had (that > > > didn't make it in this merge), was a bit more complicated and the > > > first iteration caused a deadlock that didn't show up in basic test > > > like booting Linux. > > > > > > My guess is that fixes that correct an issue with real software running > > > on the target should be ported to stable. Perhaps "obviously correct" > > > small fixes as well. But not sure about larger changes. > > > > This is exactly why I asked, - because I don't clearly understand how > > important these to have in -stable. And also to remind that -stable > > exist, just in case.. ;) > > Ah okay, makes sense. I was just clarifying myself since I wasn't > too sure. > > > So be it, no actual issue so not applying to -stable. > > I will think about it and try to keep -stable in mind. Of my patches > there are one or two coming up that could probably go in there, if > not these ones. 1/10 from me (fallback to MFSS) did fix software failures for Yocto Project so might be a good candidate for stable. We're carrying that patch against the last release for now. Cheers, Richard
On 5/28/23 14:36, Michael Tokarev wrote: > 28.05.2023 19:49, Daniel Henrique Barboza wrote: >> >> https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20230528 >> >> ppc patch queue for 2023-05-28: >> >> This queue includes several assorted fixes for PowerPC SPR >> emulation, a change in the default Pegasos2 CPU, the addition >> of AIL mode 3 for spapr, a PIC->CPU interrupt fix for prep and >> performance enhancements in fpu_helper.c. > > From the patch description, it looks like the following changes > are suitable for -stable: > > 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs > 02/10 target/ppc: Fix width of some 32-bit SPRs > 03/10 target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward > 05/10 hw/ppc/prep: Fix wiring of PIC -> CPU interrupt > > Or are these not important for -stable? Or maybe there are other changes > which should be picked too? Patch 1 and perhaps 5 is stable material, and by "stable material" I'm interpreting as "bug fixes for issues that were detected in the field by users and predates the current release" Let me know if this is the right approach or not. > > Please add "Cc: qemu-stable@nongnu.org" tag for the future patches which > needs to be backported to previous/stable version of qemu. I'll keep that in mind next time. Thanks, Daniel > > Thanks! > > /mjt >> --------------------------------------------------------------- >> Alexander Bulekov (1): >> pnv_lpc: disable reentrancy detection for lpc-hc >> >> BALATON Zoltan (1): >> ppc/pegasos2: Change default CPU to 7457 >> >> Bernhard Beschow (1): >> hw/ppc/prep: Fix wiring of PIC -> CPU interrupt >> >> Nicholas Piggin (5): >> target/ppc: Fix width of some 32-bit SPRs >> target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward >> spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall >> target/ppc: Use SMT4 small core chip type in POWER9/10 PVRs >> target/ppc: Add POWER9 DD2.2 model >> >> Richard Henderson (1): >> target/ppc: Merge COMPUTE_CLASS and COMPUTE_FPRF >> >> Richard Purdie (1): >> target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs >> >
29.05.2023 09:30, Nicholas Piggin wrote: > On Mon May 29, 2023 at 4:01 PM AEST, Michael Tokarev wrote: .. >>> They certainly fix some parts of target emulation, but what is the >>> guidance for backporting those type of fixes? Most of the patches I sent >>> including 2,3 were just found from inspection or new test code and not >>> real software failing. >>> >>> Should just simple ones go in? 32-bit SPRs do not fix entirely the >>> behaviour of all SPRs, just one aspect. In another fix I had (that >>> didn't make it in this merge), was a bit more complicated and the >>> first iteration caused a deadlock that didn't show up in basic test >>> like booting Linux. >>> >>> My guess is that fixes that correct an issue with real software running >>> on the target should be ported to stable. Perhaps "obviously correct" >>> small fixes as well. But not sure about larger changes. >> >> This is exactly why I asked, - because I don't clearly understand how >> important these to have in -stable. And also to remind that -stable >> exist, just in case.. ;) > > Ah okay, makes sense. I was just clarifying myself since I wasn't > too sure. We do not have strict rules for stuff which should go to -stable. In the wiki - https://www.qemu.org/docs/master/devel/stable-process.html - it is stated as vague as If you think the patch would be important for users of the current release (or for a distribution picking fixes), it is usually a good candidate for stable. so things are decided on a case-by-case basis. Sometimes even spelling fixes gets picked up, sometimes much larger and invasive changes has to be picked to fix a real bug. Once again, there's no strict rules. Myself, I haven't been in this process before, but I see it from a downstream PoV, as I maintain qemu in debian for quite some years. A bug might not be reported by actual users, but if it has good potential for breaking something, - *maybe* like in this case when qemu behaves differently than an actual HW (once again, I don't know what the impact of *these* fixes, or lack thereof, are), - and at the same time the fix is small, self-contained and "obviously correct" (in other words, has low potential of breaking something else), - I tend to pick it up, to bring behavior to match the specs like in this case. We had this numerous times: something is broken, but apparently no one uses that. And out of the sudden people start hitting it in real life, like even qemu itself which uses debian-provided packages in its own CI. Just to discover this bug is known for a long time and is fixed in master long ago too. Sure thing there might be changes which fix more serious issues, but which are based on some subsystem rewrite, - with these, it's more difficult to decide what to do - to keep bug or to risk breaking other stuff. I omitted a few fixes for 7.2 due to this very situation: when the infrastructure used in new code did not exist in 7.2 and quite a lot of other changes needs to be back-ported. There's always a tradeoff: the "importance" of the bug and the amount of stuff it requires to back-port. Unimportant fixes (eg, a missing free() in error path in init function) which require other code changes are obviously not for -stable. On the other end, small but important changes (eg a fix for a crash/deadlock which many users are hitting) is obviously a good fit for -stable. And anything in-between is, sure thing, grey, with all its shades. This is why we're more dependent on the subsystem maintainers or authors of the particular changes, - since they know much better when any given fix is important or not, know much better about possible impact and so on. Maybe it's just cosmetics which can safely be ignored, or maybe it's a big thing which is worth to backport other stuff for it to work. It is also much easier to think about this when you have the context which you just fixed, still in your mind. And this is why I'm asking. Thank you! /mjt
On 5/28/23 09:49, Daniel Henrique Barboza wrote: > The following changes since commit ac84b57b4d74606f7f83667a0606deef32b2049d: > > Merge tag 'for-upstream' ofhttps://gitlab.com/bonzini/qemu into staging (2023-05-26 14:40:55 -0700) > > are available in the Git repository at: > > https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20230528 > > for you to fetch changes up to 56b8bfe9bb6b94184b8bbfc4be9196404a81e450: > > ppc/pegasos2: Change default CPU to 7457 (2023-05-28 13:25:45 -0300) > > ---------------------------------------------------------------- > ppc patch queue for 2023-05-28: > > This queue includes several assorted fixes for PowerPC SPR > emulation, a change in the default Pegasos2 CPU, the addition > of AIL mode 3 for spapr, a PIC->CPU interrupt fix for prep and > performance enhancements in fpu_helper.c. Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/8.1 as appropriate. r~
The following changes since commit ac84b57b4d74606f7f83667a0606deef32b2049d: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2023-05-26 14:40:55 -0700) are available in the Git repository at: https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20230528 for you to fetch changes up to 56b8bfe9bb6b94184b8bbfc4be9196404a81e450: ppc/pegasos2: Change default CPU to 7457 (2023-05-28 13:25:45 -0300) ---------------------------------------------------------------- ppc patch queue for 2023-05-28: This queue includes several assorted fixes for PowerPC SPR emulation, a change in the default Pegasos2 CPU, the addition of AIL mode 3 for spapr, a PIC->CPU interrupt fix for prep and performance enhancements in fpu_helper.c. ---------------------------------------------------------------- Alexander Bulekov (1): pnv_lpc: disable reentrancy detection for lpc-hc BALATON Zoltan (1): ppc/pegasos2: Change default CPU to 7457 Bernhard Beschow (1): hw/ppc/prep: Fix wiring of PIC -> CPU interrupt Nicholas Piggin (5): target/ppc: Fix width of some 32-bit SPRs target/ppc: Alignment faults do not set DSISR in ISA v3.0 onward spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall target/ppc: Use SMT4 small core chip type in POWER9/10 PVRs target/ppc: Add POWER9 DD2.2 model Richard Henderson (1): target/ppc: Merge COMPUTE_CLASS and COMPUTE_FPRF Richard Purdie (1): target/ppc: Fix fallback to MFSS for MFFS* instructions on pre 3.0 ISAs hw/ppc/pegasos2.c | 2 +- hw/ppc/pnv.c | 2 +- hw/ppc/pnv_core.c | 2 +- hw/ppc/pnv_lpc.c | 3 ++ hw/ppc/prep.c | 4 +- hw/ppc/spapr.c | 9 ++++- hw/ppc/spapr_caps.c | 37 ++++++++++++++++++ hw/ppc/spapr_cpu_core.c | 1 + hw/ppc/spapr_hcall.c | 24 ++++++------ include/hw/ppc/pnv.h | 2 +- include/hw/ppc/spapr.h | 4 +- target/ppc/cpu-models.c | 4 +- target/ppc/cpu-models.h | 7 ++-- target/ppc/cpu_init.c | 39 +++++++++++++------ target/ppc/excp_helper.c | 17 +++++---- target/ppc/fpu_helper.c | 78 +++++++++++--------------------------- target/ppc/helper_regs.c | 2 +- target/ppc/insn32.decode | 20 ++++++---- target/ppc/kvm.c | 7 ++++ target/ppc/kvm_ppc.h | 6 +++ target/ppc/misc_helper.c | 4 +- target/ppc/power8-pmu.c | 2 +- target/ppc/spr_common.h | 2 +- target/ppc/translate.c | 26 ++++++------- target/ppc/translate/fp-impl.c.inc | 22 ++++++++--- tests/qtest/device-plug-test.c | 4 +- 26 files changed, 201 insertions(+), 129 deletions(-)