linux-next: manual merge of the kvm tree with the powerpc tree

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  include/uapi/linux/kvm.h

between commit:

  9bb4a6f38fd4 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability")

from the powerpc tree and commits:

  644f706719f0 ("KVM: x86: hyper-v: Introduce KVM_CAP_HYPERV_ENFORCE_CPUID")
  6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2")
  0dbb11230437 ("KVM: X86: Introduce KVM_HC_MAP_GPA_RANGE hypercall")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index 9016e96de971,9febe1412f7a..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -1083,7 -1083,9 +1083,10 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_SGX_ATTRIBUTE 196
  #define KVM_CAP_VM_COPY_ENC_CONTEXT_FROM 197
  #define KVM_CAP_PTP_KVM 198
- #define KVM_CAP_PPC_RPT_INVALIDATE 199
+ #define KVM_CAP_HYPERV_ENFORCE_CPUID 199
+ #define KVM_CAP_SREGS2 200
+ #define KVM_CAP_EXIT_HYPERCALL 201
++#define KVM_CAP_PPC_RPT_INVALIDATE 202
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Paolo Bonzini]

On 22/06/21 07:25, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>    include/uapi/linux/kvm.h
> 
> between commit:
> 
>    9bb4a6f38fd4 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability")
> 
> from the powerpc tree and commits:
> 
>    644f706719f0 ("KVM: x86: hyper-v: Introduce KVM_CAP_HYPERV_ENFORCE_CPUID")
>    6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2")
>    0dbb11230437 ("KVM: X86: Introduce KVM_HC_MAP_GPA_RANGE hypercall")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

What are the dependencies of these KVM patches on patches from the bare 
metal trees, and can you guys *please* start using topic branches?

I've been asking you for literally years, but this is the first time I 
remember that Linus will have to resolve conflicts in uAPI changes and 
it is *not* acceptable.

Please drop the patches at 
https://www.spinics.net/lists/kvm-ppc/msg18666.html from the powerpc 
tree, and merge them through either the kvm-powerpc or kvm trees.

Paolo

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:
> On 22/06/21 07:25, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the kvm tree got a conflict in:
>> 
>>    include/uapi/linux/kvm.h
>> 
>> between commit:
>> 
>>    9bb4a6f38fd4 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability")
>> 
>> from the powerpc tree and commits:
>> 
>>    644f706719f0 ("KVM: x86: hyper-v: Introduce KVM_CAP_HYPERV_ENFORCE_CPUID")
>>    6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2")
>>    0dbb11230437 ("KVM: X86: Introduce KVM_HC_MAP_GPA_RANGE hypercall")
>> 
>> from the kvm tree.
>> 
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>> 
>
> What are the dependencies of these KVM patches on patches from the bare 
> metal trees,

I don't think there's actually a semantic dependency on my tree, but
there's multiple textual conflicts with my tree. That series has to go
via both trees, or there will be conflicts.

> ... and can you guys *please* start using topic branches?
>
> I've been asking you for literally years, but this is the first time I 
> remember that Linus will have to resolve conflicts in uAPI changes and 
> it is *not* acceptable.

The patches are in a topic branch, which I will ask you to pull before
the merge window, in order to resolve any conflicts.

> Please drop the patches at 
> https://www.spinics.net/lists/kvm-ppc/msg18666.html from the powerpc 
> tree, and merge them through either the kvm-powerpc or kvm trees.

The kvm-ppc tree is not taking patches at the moment.

But it doesn't matter anyway, this series needs to be merged into my
tree and the KVM tree regardless.

The topic branch is here:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/ppc-kvm


The commit Stephen mentioned has been rebased since to squash in a fix.
But what is in the topic branch is now final, I won't rebase what's
there.

cheers

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Paolo Bonzini]

On 22/06/21 16:51, Michael Ellerman wrote:
>> Please drop the patches at
>> https://www.spinics.net/lists/kvm-ppc/msg18666.html  from the powerpc
>> tree, and merge them through either the kvm-powerpc or kvm trees.
> The kvm-ppc tree is not taking patches at the moment.

If so, let's remove the "T" entry from MAINTAINERS and add an entry for 
the kvm@vger.kernel.org mailing list.

>   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/ppc-kvm
> 
> The commit Stephen mentioned has been rebased since to squash in a fix.
> But what is in the topic branch is now final, I won't rebase what's
> there.

Thanks, I pulled it.  Anyway, if the workflow is not the one indicated 
by MAINTAINERS it's never a bad idea to Cc more people when applying 
patches.

Paolo

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/mm/fault.c

between commit:

  49a502ea23bf ("powerpc/mm: Make NULL pointer deferences explicit on bad page faults.")

from the powerpc tree and commit:

  d7b456152230 ("KVM: PPC: Book3S HV: Implement functions to access quadrants 1 & 2")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/mm/fault.c
index c866d9a710fe,2e6fb1d758c3..000000000000
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@@ -650,9 -636,9 +650,10 @@@ void bad_page_fault(struct pt_regs *reg
  	switch (TRAP(regs)) {
  	case 0x300:
  	case 0x380:
+ 	case 0xe00:
 -		printk(KERN_ALERT "Unable to handle kernel paging request for "
 -			"data at address 0x%08lx\n", regs->dar);
 +		pr_alert("BUG: %s at 0x%08lx\n",
 +			 regs->dar < PAGE_SIZE ? "Kernel NULL pointer dereference" :
 +			 "Unable to handle kernel data access", regs->dar);
  		break;
  	case 0x400:
  	case 0x480:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Paolo Bonzini]

On 15/02/2017 12:16, Michael Ellerman wrote:
>> However, the reason was that this is simply not how topic branches
>> should work: topic branches should be the base for other work, they
>> shouldn't contain _all_ the work.
> 
> I think that's an overly specific definition of what a topic branch is.
> 
> It's just a branch related to some "topic", in this case powerpc kvm,
> where commits can go so they can be shared between two trees.

Right.  However, in the specific case of working across maintainers, I
think there is an interest in minimizing the number of files that are
updated in two trees.  That limits conflicts.

Typically in x86 land people send a series with generic+KVM patches,
Thomas Gleixner picks the generic ones and places them in a topic branch
that we both pull from.  I then apply the KVM patches independently.
It's worth noting that x86 arch maintainers don't care that much about
what's going on in arch/x86/kvm/, and especially they delegate all
testing to me.  So I guess that may be the source of the disagreement.

If you would like to unify testing of non-KVM and KVM code for
arch/powerpc, it doesn't make much sense for Paul to send his patches to
me at all.  Instead, _I_ should prepare topic branches for Paul whenever
I make sweeping all-arch changes to KVM, that he can include in his pull
requests to you.  It'd feel weird though.

Paolo

>> As far as I understand, there was no reason for you to get B1.
>
> Well no reason other than it's ~1300 lines of code in my arch, which I
> would like to go through my normal testing procedures.

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 14/02/2017 09:45, Michael Ellerman wrote:
>>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>>> interrupts from guest to host" and cherry-pick the top two patches
>>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>>> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
>>> your next branch, but leave the rest for my tree only.
>>
>> I don't see how that helps anything.
>> 
>> In fact it guarantees a mess because those two commits would now go to
>> Linus via my tree (cherry picked) and via Paul's as part of his second
>> merge of the topic branch.
>>
>> So unless you can give me a good reason I'll merge the tip of the topic
>> branch into my next, as planned.
>
> Yes, Paul's second merge did guarantee a mess, so go ahead.

OK, glad we agree on that.

I've now merged it and most of the conflicts are gone. The one remaining
one will be fixed if you take Paul's second pull, or otherwise it's
trivial for Linus to fix.

> However, the reason was that this is simply not how topic branches
> should work: topic branches should be the base for other work, they
> shouldn't contain _all_ the work.

I think that's an overly specific definition of what a topic branch is.

It's just a branch related to some "topic", in this case powerpc kvm,
where commits can go so they can be shared between two trees.


> So the right workflow would have been:
>
> - Paul submits topic branch A to you

That never existed though. Paul had a series of 20 patches to enable KVM
with the radix MMU.

So to create 'A' he would have to split his series in two. Which he can
obviously do, but it's unnecessary IMHO.

> - you merge A
>
> - Paul merges topic branch A into his "next" branch
>
> - Paul applies KVM-specific patches B1 on top of his "next" branch.
>
> - Paul sends pull request to me (with A + kvmppc work).

Yeah we could have done it that way. But it unnecessarily splits the
series across the trees, and means I have no way of testing the whole in
my tree.

> As far as I understand, there was no reason for you to get B1.

Well no reason other than it's ~1300 lines of code in my arch, which I
would like to go through my normal testing procedures.

I also don't see how it hurts in any way for B1 to go to Linus via both
trees.

> The last two patches (let's call them B2) also didn't need to go through
> the kvm-ppc branch at all.  You could have applied them directly on top
> of A.

I'm pretty sure Paul did need the last patch to fix a bug, but maybe
he reworked that code, I forget.

You're right the second last patch didn't need to go via kvm-ppc. I put
it in the topic branch because it was based on earlier patches in there,
but I could have put it in my tree and fixed up the conflict when I
merged the topic branch.

cheers

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Michael Ellerman]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
>   arch/powerpc/kvm/book3s_hv_rm_xics.c
>
> between commit:
>
>   ab9bad0ead9a ("powerpc/powernv: Remove separate entry for OPAL real mode calls")
>
> from the powerpc tree and commit:
>
>   21acd0e4df04 ("KVM: PPC: Book 3S: XICS: Don't lock twice when checking for resend")
>
> from the kvm tree.

Thanks.

That will go away if/when Paolo merges the rest of Paul's next.

cheers


> diff --cc arch/powerpc/kvm/book3s_hv_rm_xics.c
> index 29f43ed6d5eb,0b2e388f4cdf..000000000000
> --- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
> +++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
> @@@ -35,8 -35,8 +35,8 @@@ int kvm_irq_bypass = 1
>   EXPORT_SYMBOL(kvm_irq_bypass);
>   
>   static void icp_rm_deliver_irq(struct kvmppc_xics *xics, struct kvmppc_icp *icp,
> - 			    u32 new_irq);
> + 			    u32 new_irq, bool check_resend);
>  -static int xics_opal_rm_set_server(unsigned int hw_irq, int server_cpu);
>  +static int xics_opal_set_server(unsigned int hw_irq, int server_cpu);
>   
>   /* -- ICS routines -- */
>   static void ics_rm_check_resend(struct kvmppc_xics *xics,

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kvm/book3s_hv_rm_xics.c

between commit:

  ab9bad0ead9a ("powerpc/powernv: Remove separate entry for OPAL real mode calls")

from the powerpc tree and commit:

  21acd0e4df04 ("KVM: PPC: Book 3S: XICS: Don't lock twice when checking for resend")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/kvm/book3s_hv_rm_xics.c
index 29f43ed6d5eb,0b2e388f4cdf..000000000000
--- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
@@@ -35,8 -35,8 +35,8 @@@ int kvm_irq_bypass = 1
  EXPORT_SYMBOL(kvm_irq_bypass);
  
  static void icp_rm_deliver_irq(struct kvmppc_xics *xics, struct kvmppc_icp *icp,
- 			    u32 new_irq);
+ 			    u32 new_irq, bool check_resend);
 -static int xics_opal_rm_set_server(unsigned int hw_irq, int server_cpu);
 +static int xics_opal_set_server(unsigned int hw_irq, int server_cpu);
  
  /* -- ICS routines -- */
  static void ics_rm_check_resend(struct kvmppc_xics *xics,

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Paolo Bonzini]

On 14/02/2017 09:45, Michael Ellerman wrote:
>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>> interrupts from guest to host" and cherry-pick the top two patches
>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
>> your next branch, but leave the rest for my tree only.
>
> I don't see how that helps anything.
> 
> In fact it guarantees a mess because those two commits would now go to
> Linus via my tree (cherry picked) and via Paul's as part of his second
> merge of the topic branch.
>
> So unless you can give me a good reason I'll merge the tip of the topic
> branch into my next, as planned.

Yes, Paul's second merge did guarantee a mess, so go ahead.

However, the reason was that this is simply not how topic branches
should work: topic branches should be the base for other work, they
shouldn't contain _all_ the work.  So the right workflow would have been:

- Paul submits topic branch A to you

- you merge A

- Paul merges topic branch A into his "next" branch

- Paul applies KVM-specific patches B1 on top of his "next" branch.

- Paul sends pull request to me (with A + kvmppc work).

As far as I understand, there was no reason for you to get B1.

The last two patches (let's call them B2) also didn't need to go through
the kvm-ppc branch at all.  You could have applied them directly on top
of A.  Linus then would get A and B2 from you, and A and B1 from me:

                  base -→ A -----→ B1
                          ↓        ↓
                   ppc -→ ▪        ▪ ←- kvm
                          ↓        |
                          B2       |
                          ↓        ↓
                      torvalds/linux.git


If necessary, things could have been arranged so that Linus got A and B2
from you, and all three of A/B1/B2 from me:

- Paul submits topic branch B2 to you, based on topic branch A

- you merge B2

- Paul merges B2 and I get it from him

The result would have been:

                  base -→ A -----→ B1
                          ↓ ↘      ↓
                   ppc -→ ▪   B2 → ▪
                          ↓ ↙      ↓
                          ▪        ▪ ←- kvm
                          ↓        ↓
                      torvalds/linux.git

Paolo

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 10/02/2017 04:59, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the kvm tree got a conflict in:
>> 
>>   arch/powerpc/include/asm/head-64.h
>> 
>> between commit:
>> 
>>   852e5da99d15 ("powerpc/64s: Tidy up after exception handler rework")
>> 
>> from the powerpc tree and commit:
>> 
>>   7ede531773ea ("KVM: PPC: Book3S: Move 64-bit KVM interrupt handler out from alt section")
>> 
>> from the kvm tree.
>
> Michael, please pull the topic branch as soon as possible, so that the
> conflicts don't hit Linus.

They won't hit Linus until I send my pull request.

> That said, the topic branch is a mess.  It starts with generic arch
> patches (until "powerpc/64: Allow for relocation-on interrupts from
> guest to host") then it's only KVM, then on the top there's two more
> generic patches that were added _after_ Paul merged it.

It's not a mess, it's a collection of patches which touch either arch/powerpc
or arch/powerpc/kvm, or are otherwise related.

Yeah I could have merged just the start of Paul's series, but that
seemed pointless, it doesn't prevent or add any conflicts, and it means
I'm unable to test his series as a whole.

Paul has also now merged the remaining two commits, and sent you a pull
request including them.

> If possible, please pull only up to "powerpc/64: Allow for relocation-on
> interrupts from guest to host" and cherry-pick the top two patches
> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
> your next branch, but leave the rest for my tree only.

I don't see how that helps anything.

In fact it guarantees a mess because those two commits would now go to
Linus via my tree (cherry picked) and via Paul's as part of his second
merge of the topic branch.

So unless you can give me a good reason I'll merge the tip of the topic
branch into my next, as planned.

cheers

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/platforms/pseries/lpar.c

between commit:

  dbcf929c0062 ("powerpc/pseries: Add support for hash table resizing")

from the powerpc tree and commit:

  cc3d2940133d ("powerpc/64: Enable use of radix MMU under hypervisor on POWER9")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/platforms/pseries/lpar.c
index c2e13a51f369,0587655aea69..000000000000
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@@ -611,112 -609,29 +611,135 @@@ static int __init disable_bulk_remove(c
  
  __setup("bulk_remove=", disable_bulk_remove);
  
 +#define HPT_RESIZE_TIMEOUT	10000 /* ms */
 +
 +struct hpt_resize_state {
 +	unsigned long shift;
 +	int commit_rc;
 +};
 +
 +static int pseries_lpar_resize_hpt_commit(void *data)
 +{
 +	struct hpt_resize_state *state = data;
 +
 +	state->commit_rc = plpar_resize_hpt_commit(0, state->shift);
 +	if (state->commit_rc != H_SUCCESS)
 +		return -EIO;
 +
 +	/* Hypervisor has transitioned the HTAB, update our globals */
 +	ppc64_pft_size = state->shift;
 +	htab_size_bytes = 1UL << ppc64_pft_size;
 +	htab_hash_mask = (htab_size_bytes >> 7) - 1;
 +
 +	return 0;
 +}
 +
 +/* Must be called in user context */
 +static int pseries_lpar_resize_hpt(unsigned long shift)
 +{
 +	struct hpt_resize_state state = {
 +		.shift = shift,
 +		.commit_rc = H_FUNCTION,
 +	};
 +	unsigned int delay, total_delay = 0;
 +	int rc;
 +	ktime_t t0, t1, t2;
 +
 +	might_sleep();
 +
 +	if (!firmware_has_feature(FW_FEATURE_HPT_RESIZE))
 +		return -ENODEV;
 +
 +	printk(KERN_INFO "lpar: Attempting to resize HPT to shift %lu\n",
 +	       shift);
 +
 +	t0 = ktime_get();
 +
 +	rc = plpar_resize_hpt_prepare(0, shift);
 +	while (H_IS_LONG_BUSY(rc)) {
 +		delay = get_longbusy_msecs(rc);
 +		total_delay += delay;
 +		if (total_delay > HPT_RESIZE_TIMEOUT) {
 +			/* prepare with shift==0 cancels an in-progress resize */
 +			rc = plpar_resize_hpt_prepare(0, 0);
 +			if (rc != H_SUCCESS)
 +				printk(KERN_WARNING
 +				       "lpar: Unexpected error %d cancelling timed out HPT resize\n",
 +				       rc);
 +			return -ETIMEDOUT;
 +		}
 +		msleep(delay);
 +		rc = plpar_resize_hpt_prepare(0, shift);
 +	};
 +
 +	switch (rc) {
 +	case H_SUCCESS:
 +		/* Continue on */
 +		break;
 +
 +	case H_PARAMETER:
 +		return -EINVAL;
 +	case H_RESOURCE:
 +		return -EPERM;
 +	default:
 +		printk(KERN_WARNING
 +		       "lpar: Unexpected error %d from H_RESIZE_HPT_PREPARE\n",
 +		       rc);
 +		return -EIO;
 +	}
 +
 +	t1 = ktime_get();
 +
 +	rc = stop_machine(pseries_lpar_resize_hpt_commit, &state, NULL);
 +
 +	t2 = ktime_get();
 +
 +	if (rc != 0) {
 +		switch (state.commit_rc) {
 +		case H_PTEG_FULL:
 +			printk(KERN_WARNING
 +			       "lpar: Hash collision while resizing HPT\n");
 +			return -ENOSPC;
 +
 +		default:
 +			printk(KERN_WARNING
 +			       "lpar: Unexpected error %d from H_RESIZE_HPT_COMMIT\n",
 +			       state.commit_rc);
 +			return -EIO;
 +		};
 +	}
 +
 +	printk(KERN_INFO
 +	       "lpar: HPT resize to shift %lu complete (%lld ms / %lld ms)\n",
 +	       shift, (long long) ktime_ms_delta(t1, t0),
 +	       (long long) ktime_ms_delta(t2, t1));
 +
 +	return 0;
 +}
 +
+ /* Actually only used for radix, so far */
+ static int pseries_lpar_register_process_table(unsigned long base,
+ 			unsigned long page_size, unsigned long table_size)
+ {
+ 	long rc;
+ 	unsigned long flags = PROC_TABLE_NEW;
+ 
+ 	if (radix_enabled())
+ 		flags |= PROC_TABLE_RADIX | PROC_TABLE_GTSE;
+ 	for (;;) {
+ 		rc = plpar_hcall_norets(H_REGISTER_PROC_TBL, flags, base,
+ 					page_size, table_size);
+ 		if (!H_IS_LONG_BUSY(rc))
+ 			break;
+ 		mdelay(get_longbusy_msecs(rc));
+ 	}
+ 	if (rc != H_SUCCESS) {
+ 		pr_err("Failed to register process table (rc=%ld)\n", rc);
+ 		BUG();
+ 	}
+ 	return rc;
+ }
+ 
  void __init hpte_init_pseries(void)
  {
  	mmu_hash_ops.hpte_invalidate	 = pSeries_lpar_hpte_invalidate;
@@@ -728,9 -643,14 +751,15 @@@
  	mmu_hash_ops.flush_hash_range	 = pSeries_lpar_flush_hash_range;
  	mmu_hash_ops.hpte_clear_all      = pseries_hpte_clear_all;
  	mmu_hash_ops.hugepage_invalidate = pSeries_lpar_hugepage_invalidate;
 +	mmu_hash_ops.resize_hpt		 = pseries_lpar_resize_hpt;
  }
  
+ void radix_init_pseries(void)
+ {
+ 	pr_info("Using radix MMU under hypervisor\n");
+ 	register_process_table = pseries_lpar_register_process_table;
+ }
+ 
  #ifdef CONFIG_PPC_SMLPAR
  #define CMO_FREE_HINT_DEFAULT 1
  static int cmo_free_hint_flag = CMO_FREE_HINT_DEFAULT;

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/include/asm/prom.h

between commit:

  0de0fb09bbce ("powerpc/pseries: Advertise HPT resizing support via CAS")

from the powerpc tree and commit:

  3f4ab2f83b4e ("powerpc/pseries: Fixes for the "ibm,architecture-vec-5" options")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/include/asm/prom.h
index 00fcfcbdd053,8af2546ea593..000000000000
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@@ -151,11 -153,17 +153,18 @@@ struct of_drconf_cell 
  #define OV5_XCMO		0x0440	/* Page Coalescing */
  #define OV5_TYPE1_AFFINITY	0x0580	/* Type 1 NUMA affinity */
  #define OV5_PRRN		0x0540	/* Platform Resource Reassignment */
 +#define OV5_RESIZE_HPT		0x0601	/* Hash Page Table resizing */
- #define OV5_PFO_HW_RNG		0x0E80	/* PFO Random Number Generator */
- #define OV5_PFO_HW_842		0x0E40	/* PFO Compression Accelerator */
- #define OV5_PFO_HW_ENCR		0x0E20	/* PFO Encryption Accelerator */
- #define OV5_SUB_PROCESSORS	0x0F01	/* 1,2,or 4 Sub-Processors supported */
+ #define OV5_PFO_HW_RNG		0x1180	/* PFO Random Number Generator */
+ #define OV5_PFO_HW_842		0x1140	/* PFO Compression Accelerator */
+ #define OV5_PFO_HW_ENCR		0x1120	/* PFO Encryption Accelerator */
+ #define OV5_SUB_PROCESSORS	0x1501	/* 1,2,or 4 Sub-Processors supported */
+ #define OV5_XIVE_EXPLOIT	0x1701	/* XIVE exploitation supported */
+ #define OV5_MMU_RADIX_300	0x1880	/* ISA v3.00 radix MMU supported */
+ #define OV5_MMU_HASH_300	0x1840	/* ISA v3.00 hash MMU supported */
+ #define OV5_MMU_SEGM_RADIX	0x1820	/* radix mode (no segmentation) */
+ #define OV5_MMU_PROC_TBL	0x1810	/* hcall selects SLB or proc table */
+ #define OV5_MMU_SLB		0x1800	/* always use SLB */
+ #define OV5_MMU_GTSE		0x1808	/* Guest translation shootdown */
  
  /* Option Vector 6: IBM PAPR hints */
  #define OV6_LINUX		0x02	/* Linux is our OS */

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/include/asm/hvcall.h

between commit:

  64b40ffbc830 ("powerpc/pseries: Add hypercall wrappers for hash page table resizing")

from the powerpc tree and commit:

  cc3d2940133d ("powerpc/64: Enable use of radix MMU under hypervisor on POWER9")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/include/asm/hvcall.h
index 490c4b9f4e3a,54d11b3a6bf7..000000000000
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@@ -276,8 -276,7 +276,9 @@@
  #define H_GET_MPP_X		0x314
  #define H_SET_MODE		0x31C
  #define H_CLEAR_HPT		0x358
 +#define H_RESIZE_HPT_PREPARE	0x36C
 +#define H_RESIZE_HPT_COMMIT	0x370
+ #define H_REGISTER_PROC_TBL	0x37C
  #define H_SIGNAL_SYS_RESET	0x380
  #define MAX_HCALL_OPCODE	H_SIGNAL_SYS_RESET
  

Re: linux-next: manual merge of the kvm tree with the powerpc tree

[Paolo Bonzini]

On 10/02/2017 04:59, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/powerpc/include/asm/head-64.h
> 
> between commit:
> 
>   852e5da99d15 ("powerpc/64s: Tidy up after exception handler rework")
> 
> from the powerpc tree and commit:
> 
>   7ede531773ea ("KVM: PPC: Book3S: Move 64-bit KVM interrupt handler out from alt section")
> 
> from the kvm tree.
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/powerpc/kernel/exceptions-64s.S
> 
> between commit:
> 
>   1a6822d194c3 ("powerpc/64s: Use (start, size) rather than (start, end) for exception handlers")
> 
> from the powerpc tree and commit:
> 
>   bc3551257af8 ("powerpc/64: Allow for relocation-on interrupts from guest to host")
> 
> from the kvm tree.

Michael, please pull the topic branch as soon as possible, so that the
conflicts don't hit Linus.

That said, the topic branch is a mess.  It starts with generic arch
patches (until "powerpc/64: Allow for relocation-on interrupts from
guest to host") then it's only KVM, then on the top there's two more
generic patches that were added _after_ Paul merged it.

If possible, please pull only up to "powerpc/64: Allow for relocation-on
interrupts from guest to host" and cherry-pick the top two patches
("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
"powerpc/powernv: Remove separate entry for OPAL real mode calls") into
your next branch, but leave the rest for my tree only.

Paolo

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kernel/exceptions-64s.S

between commit:

  1a6822d194c3 ("powerpc/64s: Use (start, size) rather than (start, end) for exception handlers")

from the powerpc tree and commit:

  bc3551257af8 ("powerpc/64: Allow for relocation-on interrupts from guest to host")

from the kvm tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/kernel/exceptions-64s.S
index a6205a4a3574,34a04a5fa468..000000000000
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@@ -720,14 -720,10 +720,10 @@@ hardware_interrupt_hv
  	FTR_SECTION_ELSE
  		_MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
  					    EXC_STD, SOFTEN_TEST_PR)
- do_kvm_0x500:
- 		KVM_HANDLER(PACA_EXGEN, EXC_STD, 0x500)
  	ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
 -EXC_REAL_END(hardware_interrupt, 0x500, 0x600)
 +EXC_REAL_END(hardware_interrupt, 0x500, 0x100)
  
 -EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x4600)
 +EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x100)
  	.globl hardware_interrupt_relon_hv;
  hardware_interrupt_relon_hv:
  	BEGIN_FTR_SECTION
@@@ -735,8 -731,10 +731,10 @@@
  	FTR_SECTION_ELSE
  		_MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common, EXC_STD, SOFTEN_TEST_PR)
  	ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
 -EXC_VIRT_END(hardware_interrupt, 0x4500, 0x4600)
 +EXC_VIRT_END(hardware_interrupt, 0x4500, 0x100)
  
+ TRAMP_KVM(PACA_EXGEN, 0x500)
+ TRAMP_KVM_HV(PACA_EXGEN, 0x500)
  EXC_COMMON_ASYNC(hardware_interrupt_common, 0x500, do_IRQ)
  
  
@@@ -884,35 -907,15 +907,15 @@@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE
  	b	system_call_common ;
  #endif
  
 -EXC_REAL_BEGIN(system_call, 0xc00, 0xd00)
 +EXC_REAL_BEGIN(system_call, 0xc00, 0x100)
- 	 /*
- 	  * If CONFIG_KVM_BOOK3S_64_HANDLER is set, save the PPR (on systems
- 	  * that support it) before changing to HMT_MEDIUM. That allows the KVM
- 	  * code to save that value into the guest state (it is the guest's PPR
- 	  * value). Otherwise just change to HMT_MEDIUM as userspace has
- 	  * already saved the PPR.
- 	  */
- #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
- 	SET_SCRATCH0(r13)
- 	GET_PACA(r13)
- 	std	r9,PACA_EXGEN+EX_R9(r13)
- 	OPT_GET_SPR(r9, SPRN_PPR, CPU_FTR_HAS_PPR);
- 	HMT_MEDIUM;
- 	std	r10,PACA_EXGEN+EX_R10(r13)
- 	OPT_SAVE_REG_TO_PACA(PACA_EXGEN+EX_PPR, r9, CPU_FTR_HAS_PPR);
- 	mfcr	r9
- 	KVMTEST_PR(0xc00)
- 	GET_SCRATCH0(r13)
- #else
- 	HMT_MEDIUM;
- #endif
+ 	SYSCALL_KVMTEST
  	SYSCALL_PSERIES_1
  	SYSCALL_PSERIES_2_RFID
  	SYSCALL_PSERIES_3
 -EXC_REAL_END(system_call, 0xc00, 0xd00)
 +EXC_REAL_END(system_call, 0xc00, 0x100)
  
 -EXC_VIRT_BEGIN(system_call, 0x4c00, 0x4d00)
 +EXC_VIRT_BEGIN(system_call, 0x4c00, 0x100)
- 	HMT_MEDIUM
+ 	SYSCALL_KVMTEST
  	SYSCALL_PSERIES_1
  	SYSCALL_PSERIES_2_DIRECT
  	SYSCALL_PSERIES_3
@@@ -926,8 -929,8 +929,8 @@@ EXC_VIRT(single_step, 0x4d00, 0x100, 0x
  TRAMP_KVM(PACA_EXGEN, 0xd00)
  EXC_COMMON(single_step_common, 0xd00, single_step_exception)
  
 -EXC_REAL_OOL_HV(h_data_storage, 0xe00, 0xe20)
 -EXC_VIRT_OOL_HV(h_data_storage, 0x4e00, 0x4e20, 0xe00)
 +EXC_REAL_OOL_HV(h_data_storage, 0xe00, 0x20)
- EXC_VIRT_NONE(0x4e00, 0x20)
++EXC_VIRT_OOL_HV(h_data_storage, 0x4e00, 0x20, 0xe00)
  TRAMP_KVM_HV_SKIP(PACA_EXGEN, 0xe00)
  EXC_COMMON_BEGIN(h_data_storage_common)
  	mfspr   r10,SPRN_HDAR
@@@ -942,8 -945,8 +945,8 @@@
  	b       ret_from_except
  
  
 -EXC_REAL_OOL_HV(h_instr_storage, 0xe20, 0xe40)
 -EXC_VIRT_OOL_HV(h_instr_storage, 0x4e20, 0x4e40, 0xe20)
 +EXC_REAL_OOL_HV(h_instr_storage, 0xe20, 0x20)
- EXC_VIRT_NONE(0x4e20, 0x20)
++EXC_VIRT_OOL_HV(h_instr_storage, 0x4e20, 0x20, 0xe20)
  TRAMP_KVM_HV(PACA_EXGEN, 0xe20)
  EXC_COMMON(h_instr_storage_common, 0xe20, unknown_exception)
  

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/include/asm/head-64.h

between commit:

  852e5da99d15 ("powerpc/64s: Tidy up after exception handler rework")

from the powerpc tree and commit:

  7ede531773ea ("KVM: PPC: Book3S: Move 64-bit KVM interrupt handler out from alt section")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/include/asm/head-64.h
index a475711cd9c3,9bd81619d090..000000000000
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@@ -223,8 -217,8 +223,8 @@@ name
  	FIXED_SECTION_ENTRY_BEGIN(virt_trampolines, name)
  
  #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
 -#define TRAMP_KVM_BEGIN(name)						\
 +#define TRAMP_KVM_BEGIN(name)					\
- 	TRAMP_REAL_BEGIN(name)
+ 	TRAMP_VIRT_BEGIN(name)
  #else
  #define TRAMP_KVM_BEGIN(name)
  #endif

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kernel/Makefile

between commit:

  27d114966735 ("powerpc/32: Remove RELOCATABLE_PPC32")

from the powerpc tree and commit:

  fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/kernel/Makefile
index 62df36c3f138,6972a23433d3..000000000000
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@@ -46,7 -41,8 +46,7 @@@ obj-$(CONFIG_VDSO32)		+= vdso32
  obj-$(CONFIG_HAVE_HW_BREAKPOINT)	+= hw_breakpoint.o
  obj-$(CONFIG_PPC_BOOK3S_64)	+= cpu_setup_ppc970.o cpu_setup_pa6t.o
  obj-$(CONFIG_PPC_BOOK3S_64)	+= cpu_setup_power.o
- obj-$(CONFIG_PPC_BOOK3S_64)	+= mce.o mce_power.o
+ obj-$(CONFIG_PPC_BOOK3S_64)	+= mce.o mce_power.o hmi.o
 -obj64-$(CONFIG_RELOCATABLE)	+= reloc_64.o
  obj-$(CONFIG_PPC_BOOK3E_64)	+= exceptions-64e.o idle_book3e.o
  obj-$(CONFIG_PPC64)		+= vdso64/
  obj-$(CONFIG_ALTIVEC)		+= vecemu.o

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kernel/idle_book3s.S

between commit:

  69c592ed40d3 ("powerpc/opal: Add real mode call wrappers")

from the powerpc tree and commit:

  fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt")

from the kvm tree.

I fixed it up (on Michael's advise, I used the version form the kvm tree)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kernel/exceptions-64s.S

between commit:

  9baaef0a22c8 ("powerpc/irq: Add support for HV virtualization interrupts")

from the powerpc tree and commit:

  fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/kernel/exceptions-64s.S
index 6200e4925d26,0eba47e074b9..000000000000
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@@ -669,8 -680,8 +669,10 @@@ _GLOBAL(__replay_interrupt
  BEGIN_FTR_SECTION
  	cmpwi	r3,0xe80
  	beq	h_doorbell_common
 +	cmpwi	r3,0xea0
 +	beq	h_virt_irq_common
+ 	cmpwi	r3,0xe60
+ 	beq	hmi_exception_common
  FTR_SECTION_ELSE
  	cmpwi	r3,0xa00
  	beq	doorbell_super_common
@@@ -1161,18 -1172,9 +1163,18 @@@ fwnmi_data_area
  	. = 0x8000
  #endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
  
 +	STD_EXCEPTION_COMMON(0xf60, facility_unavailable, facility_unavailable_exception)
 +	STD_EXCEPTION_COMMON(0xf80, hv_facility_unavailable, facility_unavailable_exception)
 +
 +#ifdef CONFIG_CBE_RAS
 +	STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
 +	STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
 +	STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
 +#endif /* CONFIG_CBE_RAS */
 +
  	.globl hmi_exception_early
  hmi_exception_early:
- 	EXCEPTION_PROLOG_1(PACA_EXGEN, NOTEST, 0xe60)
+ 	EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST, 0xe62)
  	mr	r10,r1			/* Save r1			*/
  	ld	r1,PACAEMERGSP(r13)	/* Use emergency stack		*/
  	subi	r1,r1,INT_FRAME_SIZE	/* alloc stack frame		*/

linux-next: manual merge of the kvm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/powerpc/kvm/book3s_64_vio_hv.c

between commit:

  f64e8084c94b ("powerpc/mm: Move hash related mmu-*.h headers to book3s/")

from the powerpc tree and commit:

  d3695aa4f452 ("KVM: PPC: Add support for multiple-TCE hcalls")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/kvm/book3s_64_vio_hv.c
index 039028d3ccb5,44be73e6aa26..000000000000
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@@ -29,7 -30,8 +30,8 @@@
  #include <asm/tlbflush.h>
  #include <asm/kvm_ppc.h>
  #include <asm/kvm_book3s.h>
 -#include <asm/mmu-hash64.h>
 +#include <asm/book3s/64/mmu-hash.h>
+ #include <asm/mmu_context.h>
  #include <asm/hvcall.h>
  #include <asm/synch.h>
  #include <asm/ppc-opcode.h>