Re: linux-next: manual merge of the kvm tree with the powerpc tree
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 k...@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
Re: linux-next: manual merge of the kvm tree with the powerpc tree
Paolo Bonzini 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
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
linux-next: manual merge of the kvm tree with the powerpc tree
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..
--- 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
pgpwGe91thm7M.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm tree with the powerpc tree
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..
--- 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:
pgpIg5PDVVgoj.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the kvm tree with the powerpc tree
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
Paolo Bonzini 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
Stephen Rothwell 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..
> --- 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
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..
--- 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
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
Paolo Bonzini 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
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..
--- 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_TIMEOUT1 /* 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));
+
linux-next: manual merge of the kvm tree with the powerpc tree
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..
--- 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_AFFINITY0x0580 /* Type 1 NUMA affinity */
#define OV5_PRRN 0x0540 /* Platform Resource Reassignment */
+#define OV5_RESIZE_HPT0x0601 /* Hash Page Table resizing */
- #define OV5_PFO_HW_RNG0x0E80 /* PFO Random Number Generator
*/
- #define OV5_PFO_HW_8420x0E40 /* PFO Compression Accelerator
*/
- #define OV5_PFO_HW_ENCR 0x0E20 /* PFO Encryption Accelerator */
- #define OV5_SUB_PROCESSORS0x0F01 /* 1,2,or 4 Sub-Processors supported */
+ #define OV5_PFO_HW_RNG0x1180 /* PFO Random Number Generator
*/
+ #define OV5_PFO_HW_8420x1140 /* PFO Compression Accelerator
*/
+ #define OV5_PFO_HW_ENCR 0x1120 /* PFO Encryption Accelerator */
+ #define OV5_SUB_PROCESSORS0x1501 /* 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_RADIX0x1820 /* 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
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..
--- 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_MODE0x31C
#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_RESET0x380
#define MAX_HCALL_OPCODE H_SIGNAL_SYS_RESET
Re: linux-next: manual merge of the kvm tree with the powerpc tree
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
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..
--- 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);
- mfcrr9
- 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
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..
--- 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
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..
--- 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the kvm tree with the powerpc tree
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the kvm tree with the powerpc tree
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..
--- 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 */
subir1,r1,INT_FRAME_SIZE/* alloc stack frame*/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the kvm tree with the powerpc tree
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..
--- 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
#include
#include
-#include
+#include
+ #include
#include
#include
#include
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
