Skip to contentSkip to conversation

Preparing kvm/next for first pull request of 3.15 merge window

DISCUSSION Paolo Bonzini 5 participants 8 messages Mar 25, 2014 – Mar 26, 2014 KVM

lore
Share & tools
lore

Paolo Bonzini

author maintainer
#0 lore raw

Hi all,

I've pushed the last set of updates to kvm/next for the 3.15 merge window. I don't expect any other changes for either x86 or s390 (thanks Christian!). The pull request is already pretty beefy.

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC:
Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Also, the pull requests I got in the last couple of months were a bit messy, and I'm already fearing that Linus notices. In the future, I'll tag kvm-3.x-base (e.g. kvm-3.16-base) when I open kvm/next, and I will *reject* pull requests from submaintainers that include extra non-KVM commits without a very good reason.

Palo

#1 lore raw
Quoted 10 lines · Paolo Bonzini

Hi all,

I've pushed the last set of updates to kvm/next for the 3.15 merge window. I don't expect any other changes for either x86 or s390 (thanks Christian!). The pull request is already pretty beefy.

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

I think the only thing Marc had was the cache patches which I see you've already applied to next. I only have a small cosmetic fix, which I was waiting to compile together with something more comprehensive before sending a pull request, so I'm not planning on sending anything for this merge window.

We will also change to using a shared tree so you will only receive pull request from *either* me *or* Marc following this merge window.

Quoted 7 lines

Also, the pull requests I got in the last couple of months were a bit messy, and I'm already fearing that Linus notices. In the future, I'll tag kvm-3.x-base (e.g. kvm-3.16-base) when I open kvm/next, and I will *reject* pull requests from submaintainers that include extra non-KVM commits without a very good reason.

We generally try to submit arm/arm64 core code directly to Russell/Catalin.

Thanks,
-Christoffer

#2 lore raw
In reply to Paolo Bonzini
Quoted 7 lines · Paolo Bonzini

Hi all,

I've pushed the last set of updates to kvm/next for the 3.15 merge window. I don't expect any other changes for either x86 or s390 (thanks Christian!). The pull request is already pretty beefy.

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Also, the pull requests I got in the last couple of months were a bit messy, and I'm already fearing that Linus notices. In the future, I'll tag kvm-3.x-base (e.g. kvm-3.16-base) when I open kvm/next, and I will *reject* pull requests from submaintainers that include extra non-KVM commits without a very good reason.

Paolo,

can you clarify this statement? What are the dont do things: (I already checked one obvious answer)

[ ] I include non-kvm s390 patches (with a Maintainer ack from Martin or Heiko) which are required for other patches. These patches might even go via the s390 tree as well [ ] My pull request is based on current kvm/next instead of kvm/next that was branched away after rc1
[X] My pull request is based on 3.x-rcy instead of kvm/next
[ ] My pull request is based on kvm/queue instead of kvm/next
[ ] other: .....

Or maybe: what is your preferred way of pull requests from submaintainers?

Thanks

Christian

#4 lore raw
In reply to Paolo Bonzini
Quoted 11 lines · Paolo Bonzini

Hi all,

I've pushed the last set of updates to kvm/next for the 3.15 merge window. I don't expect any other changes for either x86 or s390 (thanks Christian!). The pull request is already pretty beefy.

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Alex has 5 commits in his kvm-ppc-queue branch that should go in. That tree is based on your kvm-3.14-2 tag, not on e724f080f5dd. Would you accept a pull request for that from me on Alex's behalf since he's away? Do you need me to rebase it at all?

There is also the set of 8 patches that I just posted and Scott acked. I can make a branch based on e724f080f5dd and send you a pull request.

Let me know what you would prefer regarding Alex's kvm-ppc-queue branch.

Paul.

author maintainer
#5 lore raw

Il 26/03/2014 04:51, Paul Mackerras ha scritto:

Quoted 9 lines
Quoted 5 lines
Quoted 5 lines

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Alex has 5 commits in his kvm-ppc-queue branch that should go in. That tree is based on your kvm-3.14-2 tag, not on e724f080f5dd. Would you accept a pull request for that from me on Alex's behalf since he's away?

Yes, of course.

Quoted 1 line

Do you need me to rebase it at all?

These are:

1ac4484979 PPC: KVM: Introduce hypervisor call H_GET_TCE e0a7be38c9 PPC: KVM: fix RESUME_GUEST check before returning from kvmppc_run_core()
013e98e657 PPC: KVM: fix RESUME_GUEST check before ending CEDE in kvmppc_run_core()
e8a7f11fe0 PPC: KVM: fix VCPU run for HV KVM (v2)
26d96ec97c PPC: KVM: introduce helper to check RESUME_GUEST and related

I would consider rebasing; but you know better than me the effect of the two host-crash-fixing patches and how the testability/bisectability of kvm-ppc-queue is affected.

In particular, how likely is it that reverse-bisection ("which commit fixed the bug?") would end up on e724f080f5dd rather than one of the four RESUME_GUEST commits?

Quoted 3 lines

There is also the set of 8 patches that I just posted and Scott acked. I can make a branch based on e724f080f5dd and send you a pull request.

Yes, thanks!

Paolo

Quoted 2 lines

Let me know what you would prefer regarding Alex's kvm-ppc-queue branch.

author maintainer
#3 lore raw
In reply to Christian Borntraeger

Il 25/03/2014 21:35, Christian Borntraeger ha scritto:

Quoted 7 lines · Paolo Bonzini
Quoted 5 lines

Also, the pull requests I got in the last couple of months were a bit messy, and I'm already fearing that Linus notices. In the future, I'll tag kvm-3.x-base (e.g. kvm-3.16-base) when I open kvm/next, and I will *reject* pull requests from submaintainers that include extra non-KVM commits without a very good reason.

Quoted 5 lines

can you clarify this statement? What are the dont do things: (I already checked one obvious answer)

[ ] I include non-kvm s390 patches (with a Maintainer ack from Martin or Heiko) which are required for other patches. These patches might even go via the s390 tree as well

This is okay. The patches will stand out in the diffstat and I'll check that they have Acked-bys before pulling. Bonus for using signed tags and mentioning it in the tag message. :)

Quoted 2 lines

[ ] My pull request is based on current kvm/next instead of kvm/next that was branched away after rc1

This is not only okay, it's almost always desirable. It's also okay to base your pull request on your last pull request. Any commit between kvm-3.x-base and kvm/next will do.

Exception: if there is a particularly important bugfix that you want in both -rc and kvm/next, make the pull request based on kvm-3.x-base. After pulling it in kvm/next, I'll "forward" the pull request immediately to Linus. But it should happen very rarely, and only for very bad bugs introduced during the last merge window.

For an example, see https://lkml.org/lkml/2014/3/18/112.

Quoted 1 line

[X] My pull request is based on 3.x-rcy instead of kvm/next

Indeed this is bad and it is my main complaint. As mentioned above, pull requests should be based on a commit between kvm-3.x-base and kvm/next.

Quoted 1 line

[ ] My pull request is based on kvm/queue instead of kvm/next

This is not bad per se, but kvm/queue can be rebased: if down the line I have problems with kvm/queue, you'll have to resend the pull request.

In fact, there should be no need to base pull requests on kvm/queue. Even if your arch-specific patches touch virt/kvm/ or have prerequisites in virt/kvm/, it is better to harass me until I test kvm/queue and merge it back into kvm/next. :)

Paolo

#6 lore raw
In reply to Paolo Bonzini
Quoted 25 lines · On Wed, 26 Mar 2014 10:19:52 +0100 Paolo Bonzini <[email protected]> wrote:

Il 26/03/2014 04:51, Paul Mackerras ha scritto:

Quoted 9 lines
Quoted 5 lines
Quoted 5 lines

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Alex has 5 commits in his kvm-ppc-queue branch that should go in. That tree is based on your kvm-3.14-2 tag, not on e724f080f5dd. Would you accept a pull request for that from me on Alex's behalf since he's away?

Yes, of course.

Quoted 1 line

Do you need me to rebase it at all?

These are:

1ac4484979 PPC: KVM: Introduce hypervisor call H_GET_TCE e0a7be38c9 PPC: KVM: fix RESUME_GUEST check before returning from kvmppc_run_core()
013e98e657 PPC: KVM: fix RESUME_GUEST check before ending CEDE in kvmppc_run_core()
e8a7f11fe0 PPC: KVM: fix VCPU run for HV KVM (v2)
26d96ec97c PPC: KVM: introduce helper to check RESUME_GUEST and related

Quoted 8 lines

I would consider rebasing; but you know better than me the effect of the two host-crash-fixing patches and how the testability/bisectability of kvm-ppc-queue is affected.

In particular, how likely is it that reverse-bisection ("which commit fixed the bug?") would end up on e724f080f5dd rather than one of the four RESUME_GUEST commits?

Paul,

It is safe to merge e0a7be38c9, 013e98e657, e8a7f11fe0 and 26d96ec97c as a single patch... thing I should I've done from the beginning I guess. :)

Cheers.

--
Greg

Quoted 16 lines
Quoted 3 lines

There is also the set of 8 patches that I just posted and Scott acked. I can make a branch based on e724f080f5dd and send you a pull request.

Yes, thanks!

Paolo

Quoted 2 lines

Let me know what you would prefer regarding Alex's kvm-ppc-queue branch.

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 7 lines
Gregory Kurz                                     [email protected]
                                                 [email protected]
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.
#7 lore raw
In reply to Paolo Bonzini
Quoted 25 lines · Paolo Bonzini

Il 26/03/2014 04:51, Paul Mackerras ha scritto:

Quoted 9 lines
Quoted 5 lines
Quoted 5 lines

I would like to know from ARM and PPC maintainers *now* (before the merge window opens) what will be in 3.15. Also, PPC guys, please make sure the pull requests will be based on commit e724f080f5dd (KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE, 2014-03-13).

Alex has 5 commits in his kvm-ppc-queue branch that should go in. That tree is based on your kvm-3.14-2 tag, not on e724f080f5dd. Would you accept a pull request for that from me on Alex's behalf since he's away?

Yes, of course.

Quoted 1 line

Do you need me to rebase it at all?

These are:

1ac4484979 PPC: KVM: Introduce hypervisor call H_GET_TCE e0a7be38c9 PPC: KVM: fix RESUME_GUEST check before returning from kvmppc_run_core()
013e98e657 PPC: KVM: fix RESUME_GUEST check before ending CEDE in kvmppc_run_core()
e8a7f11fe0 PPC: KVM: fix VCPU run for HV KVM (v2)
26d96ec97c PPC: KVM: introduce helper to check RESUME_GUEST and related

Quoted 7 lines

I would consider rebasing; but you know better than me the effect of the two host-crash-fixing patches and how the testability/bisectability of kvm-ppc-queue is affected.

In particular, how likely is it that reverse-bisection ("which commit fixed the bug?") would end up on e724f080f5dd rather than one of the four RESUME_GUEST commits?

OK, based on that and the fact that 4 of those commits should ideally be combined into one (as Greg commented), I will apply those changes as two commits on top of e724f080f5dd, followed by the 8 that I posted recently, and send you a pull request.

Thanks,
Paul.