[GIT PULL] KVM/riscv changes for 6.9

[Anup Patel]

On Mon, Mar 11, 2024 at 7:40 PM Paolo Bonzini <pbonzini at redhat.com> wrote:
>
> On 3/8/24 16:40, Sean Christopherson wrote:
> > You're missing the point.  I don't care when patches land in the RISC-V tree, nor
> > do I care that you made a last minute tweak to fix a bug.  I care when commits
> > show up in linux-next, and*none*  of these commits were in linux-next until
> > yesterday.
> >
> >    $ git tag -l --contains 2c5af1c8460376751d57c50af88a053a3b869926
> >    next-20240307
> >    next-20240308
> >
> > The*entire*  purpose of linux-next is to integrate*all*  work destined for the
> > next kernel into a single tree, so that conflicts, bugs, etc. can be found and
> > fixed*before*  the next merge window.
>
> Indeed, and this is more important as more work is routed towards
> different trees.  At this point we have 5 more or less active
> architectures, and especially in selftests land it's important to
> coordinate with each other.
>
> Anup, ideally, when you say that a patch is "queued" it should only be a
> short time before you're ready to send it to me - and that means putting
> it in a place where linux-next picks it up.  For x86 I generally compile
> test and run kvm-unit-tests on one of Intel or AMD, and leave the
> remaining tests for later (because they take a day or two), but in
> general it's a matter of days before linux-next get the patches.
>

Currently, I was collecting patches in the queue and allowing people
(including myself) to test the queue for a longer time and updating
"next" branch only a couple of weeks before I send PR.

Going forward, I will follow your suggestion. This means once a
series is tested on queue, I will move it to the "next" branch sooner
so that "linux-next" picks it sooner.

Regards,
Anup