Message ID | 20240322085319.1758843-1-alistair.francis@wdc.com |
---|---|
State | New |
Headers | show |
On Fri, 22 Mar 2024 at 09:01, Alistair Francis <alistair23@gmail.com> wrote: > > The following changes since commit fea445e8fe9acea4f775a832815ee22bdf2b0222: > > Merge tag 'pull-maintainer-final-for-real-this-time-200324-1' of https://gitlab.com/stsquad/qemu into staging (2024-03-21 10:31:56 +0000) > > are available in the Git repository at: > > https://github.com/alistair23/qemu.git tags/pull-riscv-to-apply-20240322 > > for you to fetch changes up to 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe: > > target/riscv/kvm: fix timebase-frequency when using KVM acceleration (2024-03-22 15:41:01 +1000) > > ---------------------------------------------------------------- > RISC-V PR for 9.0 > > * Do not enable all named features by default > * A range of Vector fixes > * Update APLIC IDC after claiming iforce register > * Remove the dependency of Zvfbfmin to Zfbfmin > * Fix mode in riscv_tlb_fill > * Fix timebase-frequency when using KVM acceleration > > ---------------------------------------------------------------- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any user-visible changes. -- PMM
22.03.2024 11:53, Alistair Francis : > RISC-V PR for 9.0 > > * Do not enable all named features by default > * A range of Vector fixes > * Update APLIC IDC after claiming iforce register > * Remove the dependency of Zvfbfmin to Zfbfmin > * Fix mode in riscv_tlb_fill > * Fix timebase-frequency when using KVM acceleration Should something from there be picked up for stable (8.2 and probably 7.2)? Thanks, /mjt > ---------------------------------------------------------------- > Daniel Henrique Barboza (10): > target/riscv: do not enable all named features by default > target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX() > trans_rvv.c.inc: set vstart = 0 in int scalar move insns > target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess > target/riscv: always clear vstart in whole vec move insns > target/riscv: always clear vstart for ldst_whole insns > target/riscv/vector_helpers: do early exit when vstart >= vl > target/riscv: remove 'over' brconds from vector trans > trans_rvv.c.inc: remove redundant mark_vs_dirty() calls > target/riscv/vector_helper.c: optimize loops in ldst helpers > > Frank Chang (1): > hw/intc: Update APLIC IDC after claiming iforce register > > Irina Ryapolova (1): > target/riscv: Fix mode in riscv_tlb_fill > > Ivan Klokov (1): > target/riscv: enable 'vstart_eq_zero' in the end of insns > > Max Chou (1): > target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin > > Yong-Xuan Wang (1): > target/riscv/kvm: fix timebase-frequency when using KVM acceleration
On 3/22/24 14:16, Michael Tokarev wrote: > 22.03.2024 11:53, Alistair Francis : > >> RISC-V PR for 9.0 >> >> * Do not enable all named features by default >> * A range of Vector fixes >> * Update APLIC IDC after claiming iforce register >> * Remove the dependency of Zvfbfmin to Zfbfmin >> * Fix mode in riscv_tlb_fill >> * Fix timebase-frequency when using KVM acceleration > > Should something from there be picked up for stable (8.2 and probably 7.2)? Ignore the "Do not enable all named features by default" since it's fixing something that were added in 9.0. The rest you can pick it up to 8.2 at least. Thanks, Daniel > > Thanks, > > /mjt > >> ---------------------------------------------------------------- >> Daniel Henrique Barboza (10): >> target/riscv: do not enable all named features by default >> target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX() >> trans_rvv.c.inc: set vstart = 0 in int scalar move insns >> target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess >> target/riscv: always clear vstart in whole vec move insns >> target/riscv: always clear vstart for ldst_whole insns >> target/riscv/vector_helpers: do early exit when vstart >= vl >> target/riscv: remove 'over' brconds from vector trans >> trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >> target/riscv/vector_helper.c: optimize loops in ldst helpers >> >> Frank Chang (1): >> hw/intc: Update APLIC IDC after claiming iforce register >> >> Irina Ryapolova (1): >> target/riscv: Fix mode in riscv_tlb_fill >> >> Ivan Klokov (1): >> target/riscv: enable 'vstart_eq_zero' in the end of insns >> >> Max Chou (1): >> target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin >> >> Yong-Xuan Wang (1): >> target/riscv/kvm: fix timebase-frequency when using KVM acceleration >
22.03.2024 22:46, Daniel Henrique Barboza : > > > On 3/22/24 14:16, Michael Tokarev wrote: >> 22.03.2024 11:53, Alistair Francis : >> >>> RISC-V PR for 9.0 >>> >>> * Do not enable all named features by default >>> * A range of Vector fixes >>> * Update APLIC IDC after claiming iforce register >>> * Remove the dependency of Zvfbfmin to Zfbfmin >>> * Fix mode in riscv_tlb_fill >>> * Fix timebase-frequency when using KVM acceleration >> >> Should something from there be picked up for stable (8.2 and probably 7.2)? > > Ignore the "Do not enable all named features by default" since it's fixing something > that were added in 9.0. > > The rest you can pick it up to 8.2 at least. Thanks, Unfortunately this doesn't quite work, the following changes fail to apply to 8.2: 929e521a47 target/riscv: always clear vstart for ldst_whole insns b46631f122 target/riscv: remove 'over' brconds from vector trans d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration I tried to back-port at least the first one but it turned out to be another failure. Didn't try looking at the rest. If these really should be in 8.2 (it's your guys to decide, not me), I need help with back-porting these to 8.2 (and/or cherry-picking additional patches from master). Thanks, /mjt >>> ---------------------------------------------------------------- >>> Daniel Henrique Barboza (10): >>> target/riscv: do not enable all named features by default >>> target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX() >>> trans_rvv.c.inc: set vstart = 0 in int scalar move insns >>> target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess >>> target/riscv: always clear vstart in whole vec move insns >>> target/riscv: always clear vstart for ldst_whole insns >>> target/riscv/vector_helpers: do early exit when vstart >= vl >>> target/riscv: remove 'over' brconds from vector trans >>> trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >>> target/riscv/vector_helper.c: optimize loops in ldst helpers >>> >>> Frank Chang (1): >>> hw/intc: Update APLIC IDC after claiming iforce register >>> >>> Irina Ryapolova (1): >>> target/riscv: Fix mode in riscv_tlb_fill >>> >>> Ivan Klokov (1): >>> target/riscv: enable 'vstart_eq_zero' in the end of insns >>> >>> Max Chou (1): >>> target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin >>> >>> Yong-Xuan Wang (1): >>> target/riscv/kvm: fix timebase-frequency when using KVM acceleration >> >
On 3/24/24 12:07, Michael Tokarev wrote: > 22.03.2024 22:46, Daniel Henrique Barboza : >> >> >> On 3/22/24 14:16, Michael Tokarev wrote: >>> 22.03.2024 11:53, Alistair Francis : >>> >>>> RISC-V PR for 9.0 >>>> >>>> * Do not enable all named features by default >>>> * A range of Vector fixes >>>> * Update APLIC IDC after claiming iforce register >>>> * Remove the dependency of Zvfbfmin to Zfbfmin >>>> * Fix mode in riscv_tlb_fill >>>> * Fix timebase-frequency when using KVM acceleration >>> >>> Should something from there be picked up for stable (8.2 and probably 7.2)? >> >> Ignore the "Do not enable all named features by default" since it's fixing something >> that were added in 9.0. >> >> The rest you can pick it up to 8.2 at least. Thanks, > > Unfortunately this doesn't quite work, the following changes > fail to apply to 8.2: > > 929e521a47 target/riscv: always clear vstart for ldst_whole insns > b46631f122 target/riscv: remove 'over' brconds from vector trans > d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls > bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns > 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration > > I tried to back-port at least the first one but it turned out to be > another failure. Didn't try looking at the rest. This particular code (vector emulation) has been going through a lot of changes in the last couple of releases, so I'm not surprised with the difficulty with backporting these. > > If these really should be in 8.2 (it's your guys to decide, not me), > I need help with back-porting these to 8.2 (and/or cherry-picking > additional patches from master). The amount of work can be non-trivial for this backport, so I'd say we should leave it aside for now. If someone has a good argument for this work then we can re-evaluate. Thanks, Daniel > > Thanks, > > /mjt > >>>> ---------------------------------------------------------------- >>>> Daniel Henrique Barboza (10): >>>> target/riscv: do not enable all named features by default >>>> target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX() >>>> trans_rvv.c.inc: set vstart = 0 in int scalar move insns >>>> target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess >>>> target/riscv: always clear vstart in whole vec move insns >>>> target/riscv: always clear vstart for ldst_whole insns >>>> target/riscv/vector_helpers: do early exit when vstart >= vl >>>> target/riscv: remove 'over' brconds from vector trans >>>> trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >>>> target/riscv/vector_helper.c: optimize loops in ldst helpers >>>> >>>> Frank Chang (1): >>>> hw/intc: Update APLIC IDC after claiming iforce register >>>> >>>> Irina Ryapolova (1): >>>> target/riscv: Fix mode in riscv_tlb_fill >>>> >>>> Ivan Klokov (1): >>>> target/riscv: enable 'vstart_eq_zero' in the end of insns >>>> >>>> Max Chou (1): >>>> target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin >>>> >>>> Yong-Xuan Wang (1): >>>> target/riscv/kvm: fix timebase-frequency when using KVM acceleration >>> >> >
On 24.03.2024 21:12, Daniel Henrique Barboza wrote: > On 3/24/24 12:07, Michael Tokarev wrote: >> Unfortunately this doesn't quite work, the following changes >> fail to apply to 8.2: >> >> 929e521a47 target/riscv: always clear vstart for ldst_whole insns >> b46631f122 target/riscv: remove 'over' brconds from vector trans >> d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >> bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns >> 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration > The amount of work can be non-trivial for this backport, so I'd say we should > leave it aside for now. If someone has a good argument for this work then we > can re-evaluate. So, out of 15 patches in this series (minus the first one already mentioned) - should I pick 9 remaining patches for stable (the ones which applies) or none at all? :) Thanks, /mjt
On Tue, Mar 26, 2024 at 7:53 PM Michael Tokarev <mjt@tls.msk.ru> wrote: > > On 24.03.2024 21:12, Daniel Henrique Barboza wrote: > > On 3/24/24 12:07, Michael Tokarev wrote: > > >> Unfortunately this doesn't quite work, the following changes > >> fail to apply to 8.2: > >> > >> 929e521a47 target/riscv: always clear vstart for ldst_whole insns > >> b46631f122 target/riscv: remove 'over' brconds from vector trans > >> d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls > >> bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns > >> 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration > > > The amount of work can be non-trivial for this backport, so I'd say we should > > leave it aside for now. If someone has a good argument for this work then we > > can re-evaluate. > > So, out of 15 patches in this series (minus the first one already > mentioned) - should I pick 9 remaining patches for stable (the ones > which applies) or none at all? :) Sorry for the confusion. The 9 patches that applied and 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration should all be picked for stable. PS: What is the best way in future to help ease some of the stable burden? Should I try and cherry pick them beforehand and then mention that as a follow up to the PR? Alistair > > Thanks, > > /mjt
On 3/26/24 06:56, Alistair Francis wrote: > On Tue, Mar 26, 2024 at 7:53 PM Michael Tokarev <mjt@tls.msk.ru> wrote: >> >> On 24.03.2024 21:12, Daniel Henrique Barboza wrote: >>> On 3/24/24 12:07, Michael Tokarev wrote: >> >>>> Unfortunately this doesn't quite work, the following changes >>>> fail to apply to 8.2: >>>> >>>> 929e521a47 target/riscv: always clear vstart for ldst_whole insns >>>> b46631f122 target/riscv: remove 'over' brconds from vector trans >>>> d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >>>> bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns >>>> 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration >> >>> The amount of work can be non-trivial for this backport, so I'd say we should >>> leave it aside for now. If someone has a good argument for this work then we >>> can re-evaluate. >> >> So, out of 15 patches in this series (minus the first one already >> mentioned) - should I pick 9 remaining patches for stable (the ones >> which applies) or none at all? :) > > Sorry for the confusion. > > The 9 patches that applied and > > 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration > > should all be picked for stable. > > PS: What is the best way in future to help ease some of the stable > burden? Should I try and cherry pick them beforehand and then mention > that as a follow up to the PR? We believe your judgement about what should or shouldn't be in stable, so IMO you can be pro-active into cherry picking fixes into stable and mention it in the PR. Thanks, Daniel > > Alistair > >> >> Thanks, >> >> /mjt
26.03.2024 12:56, Alistair Francis пишет: > On Tue, Mar 26, 2024 at 7:53 PM Michael Tokarev <mjt@tls.msk.ru> wrote: >> >> On 24.03.2024 21:12, Daniel Henrique Barboza wrote: >>> On 3/24/24 12:07, Michael Tokarev wrote: >> >>>> Unfortunately this doesn't quite work, the following changes >>>> fail to apply to 8.2: >>>> >>>> 929e521a47 target/riscv: always clear vstart for ldst_whole insns >>>> b46631f122 target/riscv: remove 'over' brconds from vector trans >>>> d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls >>>> bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns >>>> 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration >> >>> The amount of work can be non-trivial for this backport, so I'd say we should >>> leave it aside for now. If someone has a good argument for this work then we >>> can re-evaluate. >> >> So, out of 15 patches in this series (minus the first one already >> mentioned) - should I pick 9 remaining patches for stable (the ones >> which applies) or none at all? :) > > Sorry for the confusion. > > The 9 patches that applied and > > 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration > > should all be picked for stable. Got it, picked all plus 385e575cd5 which needed just trivial context fixup. Thank you for the clarification! > PS: What is the best way in future to help ease some of the stable > burden? Should I try and cherry pick them beforehand and then mention > that as a follow up to the PR? The only problem for me so far is the patch selection, - this is why I'm asking to Cc changes which should go to stable, to qemu-stable@. So far I was a bit pro-active and asked about some changes which I *feel* are suitable, like in this case. It is much better if someone who actually has knowledge about the area being changed, decides if it's stable material or not. At the same time, I don't mind at all if more changes than needed are Cc'ed like this, - at least as long as it's obvious they're not really needed (like fixing a bug introduced in commit which isn't in any release yet). I usually don't have any issues with applying patches which don't apply directly to stable - this is not a burden. In some cases when this happens, I can edit the commit (like I just did for 385e575cd5), or pick some previous changes too if they're okay, or in even more rare cases, ask for clarification or even for help with back-porting, - but this last category is really rare. Some changes gets rejected for stable in the end due to too much back-porting effort or requiring too much prior context. So the only real issue for me is to know which changes are to pick, - that's all. And this is the only thing I'm asking, - in this thread and elsewhere. Thank you! /mjt