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

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

[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.

Palo

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

[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.

Palo

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

[Christoffer Dall]

On 25 March 2014 10:29, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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.

>
> 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

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

[Christoffer Dall]

On 25 March 2014 10:29, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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.

>
> 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

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

[Christian Borntraeger]

On 25/03/14 18:29, Paolo Bonzini wrote:
> 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

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

[Christian Borntraeger]

On 25/03/14 18:29, Paolo Bonzini wrote:
> 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

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

[Paolo Bonzini]

Il 25/03/2014 21:35, Christian Borntraeger ha scritto:
> On 25/03/14 18:29, Paolo Bonzini wrote:
>> 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.
>
> 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. :)

> [ ] 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.

> [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.

> [ ] 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

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

[Paolo Bonzini]

Il 25/03/2014 21:35, Christian Borntraeger ha scritto:
> On 25/03/14 18:29, Paolo Bonzini wrote:
>> 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.
>
> 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. :)

> [ ] 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.

> [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.

> [ ] 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

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

[Paul Mackerras]

On Tue, Mar 25, 2014 at 06:29:45PM +0100, Paolo Bonzini wrote:
> 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.

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

[Paul Mackerras]

On Tue, Mar 25, 2014 at 06:29:45PM +0100, Paolo Bonzini wrote:
> 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.

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

[Paolo Bonzini]

Il 26/03/2014 04:51, Paul Mackerras ha scritto:
>> > 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.

> 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?

> 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

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

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

[Paolo Bonzini]

Il 26/03/2014 04:51, Paul Mackerras ha scritto:
>> > 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.

> 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?

> 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

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

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

[Greg Kurz]

On Wed, 26 Mar 2014 10:19:52 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 26/03/2014 04:51, Paul Mackerras ha scritto:
> >> > 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.
> 
> > 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?
> 

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

> > 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
> 
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

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

[Greg Kurz]

On Wed, 26 Mar 2014 10:19:52 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 26/03/2014 04:51, Paul Mackerras ha scritto:
> >> > 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.
> 
> > 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?
> 

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

> > 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
> 
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

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

[Paul Mackerras]

On Wed, Mar 26, 2014 at 10:19:52AM +0100, Paolo Bonzini wrote:
> Il 26/03/2014 04:51, Paul Mackerras ha scritto:
> >>> 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.
> 
> >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?

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.

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

[Paul Mackerras]

On Wed, Mar 26, 2014 at 10:19:52AM +0100, Paolo Bonzini wrote:
> Il 26/03/2014 04:51, Paul Mackerras ha scritto:
> >>> 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.
> 
> >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?

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.