On 23/09/23, Michael Tokarev wrote:
> [Trimming Cc list]
> 
> 22.09.2023 13:45, Anton Johansson:
> > On 21/09/23, Michael Tokarev wrote:
> 
> > > > Anton Johansson (9):
> > > >     accel/kvm: Widen pc/saved_insn for kvm_sw_breakpoint
> > > >     accel/hvf: Widen pc/saved_insn for hvf_sw_breakpoint
> > > >     target: Use vaddr for kvm_arch_[insert|remove]_hw_breakpoint
> > > >     target: Use vaddr for hvf_arch_[insert|remove]_hw_breakpoint
> > > >     Replace target_ulong with abi_ptr in cpu_[st|ld]*()
> > > >     include/exec: typedef abi_ptr to vaddr in softmmu
> > > >     include/exec: Widen tlb_hit/tlb_hit_page()
> > > >     accel/tcg: Widen address arg. in tlb_compare_set()
> > > >     accel/tcg: Update run_on_cpu_data static assert
> > > 
> > > Pinging a relatively old patchset, - which fixes from here needs to
> > > go to stable-8.1?
> ...
> > The rest of the patches can be delayed without issue.
> 
> Now I'm confused.  What do you mean "delayed"?
> Should the rest be picked up for 8.1.2 or 8.1.3 or maybe 8.1.4?
> 
> The whole series has been accepted/applied to master, I asked which
> changes should be picked up for stable-8.1, - there's no delay involved,
> it is either picked up or not, either needed in stable or not.
> 
> Yes, "Widen tlb_hit/tlb_hit_page()" fixes a known bug and I picked
> up that one, - unfortunately it missed 8.1.1 release.  The question
> is about the other changes in this patch set, - do they fix other
> similar, not yet discovered, bugs in other places, or not fixing
> anything? Or should we delay picking them up until a bug is reported? :)
> 
> Thank you for the changes and the reply!
> 
> /mjt

Oh I see what you mean now, thanks for the clarification!:) I'm not that 
used to think in terms of what patches end up in stable.

The other patches in this series are refactors to reduce 
target-dependence in accel/, and they do not fix any bugs directly. 
Eventually we'll need to pick them up for compiling cputlb.c once for 
system mode etc., or other patches that depend on the refactor, but they 
are not critical to get in due to fixing some bug, that's what I meant 
by "can be delayed without issue".

How do you usually deal with these types of refactor heavy changes? 
Picking asap vs delaying until absolutely needed?

Thanks again for the explanation, I hope this was of some help.

//Anton

Reply via email to