qemu-stable
[Top][All Lists]
Advanced

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

Re: [PULL 00/15] riscv-to-apply queue


From: Alistair Francis
Subject: Re: [PULL 00/15] riscv-to-apply queue
Date: Tue, 26 Mar 2024 19:56:34 +1000

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



reply via email to

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