* [PATCH V4 00/15] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM
From: lantianyu1986 @ 2018-10-13 14:53 UTC (permalink / raw)
Cc: linux-mips, linux, kvm, rkrcmar, will.deacon, linux-kernel, hpa,
kys, kvmarm, sthemmin, x86, michael.h.kelley, mingo,
catalin.marinas, jhogan, Lan Tianyu, marc.zyngier, haiyangz,
kvm-ppc, pbonzini, tglx, linux-arm-kernel, christoffer.dall, ralf,
paul.burton, devel, vkuznets, linuxppc-dev
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
For nested memory virtualization, Hyper-v doesn't set write-protect
L1 hypervisor EPT page directory and page table node to track changes
while it relies on guest to tell it changes via HvFlushGuestAddressLlist
hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush
EPT page table with ranges which are specified by L1 hypervisor.
If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to
flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table
and sync L1's EPT table when next EPT page fault is triggered.
HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT
page fault and synchronization of shadow page table.
Change since v3:
1) Remove code of updating "tlbs_dirty" in kvm_flush_remote_tlbs_with_range()
2) Remove directly tlb flush in the kvm_handle_hva_range()
3) Move tlb flush in kvm_set_pte_rmapp() to kvm_mmu_notifier_change_pte()
4) Combine Vitaly's "don't pass EPT configuration info to
vmx_hv_remote_flush_tlb()" fix
Change since v2:
1) Fix comment in the kvm_flush_remote_tlbs_with_range()
2) Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
3) Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
4) Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.
Change since v1:
1) Convert "end_gfn" of struct kvm_tlb_range to "pages" in order
to avoid confusion as to whether "end_gfn" is inclusive or exlusive.
2) Add hyperv tlb range struct and replace kvm tlb range struct
with new struct in order to avoid using kvm struct in the hyperv
code directly.
Lan Tianyu (15):
KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
KVM/MMU: Add tlb flush with range helper function
KVM: Replace old tlb flush function with new one to flush a specified
range.
KVM: Make kvm_set_spte_hva() return int
KVM/MMU: Move tlb flush in kvm_set_pte_rmapp() to
kvm_mmu_notifier_change_pte()
KVM/MMU: Flush tlb directly in the kvm_set_pte_rmapp()
KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()
KVM: Add flush_link and parent_pte in the struct kvm_mmu_page
KVM: Add spte's point in the struct kvm_mmu_page
KVM/MMU: Replace tlb flush function with range list flush function
x86/hyper-v: Add HvFlushGuestAddressList hypercall support
x86/Hyper-v: Add trace in the
hyperv_nested_flush_guest_mapping_range()
KVM/VMX: Change hv flush logic when ept tables are mismatched.
KVM/VMX: Add hv tlb range flush support
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/mips/include/asm/kvm_host.h | 2 +-
arch/mips/kvm/mmu.c | 3 +-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kvm/book3s.c | 3 +-
arch/powerpc/kvm/e500_mmu_host.c | 3 +-
arch/x86/hyperv/nested.c | 85 ++++++++++++++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 32 +++++++++
arch/x86/include/asm/kvm_host.h | 12 +++-
arch/x86/include/asm/mshyperv.h | 16 +++++
arch/x86/include/asm/trace/hyperv.h | 14 ++++
arch/x86/kvm/mmu.c | 138 ++++++++++++++++++++++++++++++------
arch/x86/kvm/paging_tmpl.h | 10 ++-
arch/x86/kvm/vmx.c | 70 +++++++++++++++---
virt/kvm/arm/mmu.c | 6 +-
virt/kvm/kvm_main.c | 5 +-
17 files changed, 360 insertions(+), 45 deletions(-)
--
2.14.4
^ permalink raw reply
* [PATCH V4 1/15] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
From: lantianyu1986 @ 2018-10-13 14:53 UTC (permalink / raw)
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, sthemmin, x86, michael.h.kelley,
mingo, jhogan, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, devel,
tglx, linux-arm-kernel, christoffer.dall, ralf, paul.burton,
pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181013145406.4911-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
Add flush range call back in the kvm_x86_ops and platform can use it
to register its associated function. The parameter "kvm_tlb_range"
accepts a single range and flush list which contains a list of ranges.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change since v1:
Change "end_gfn" to "pages" to aviod confusion as to whether
"end_gfn" is inclusive or exlusive.
---
arch/x86/include/asm/kvm_host.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4b09d4aa9bf4..fea95aa77319 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -439,6 +439,12 @@ struct kvm_mmu {
u64 pdptrs[4]; /* pae */
};
+struct kvm_tlb_range {
+ u64 start_gfn;
+ u64 pages;
+ struct list_head *flush_list;
+};
+
enum pmc_type {
KVM_PMC_GP = 0,
KVM_PMC_FIXED,
@@ -1039,6 +1045,8 @@ struct kvm_x86_ops {
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
int (*tlb_remote_flush)(struct kvm *kvm);
+ int (*tlb_remote_flush_with_range)(struct kvm *kvm,
+ struct kvm_tlb_range *range);
/*
* Flush any TLB entries associated with the given GVA.
--
2.14.4
^ permalink raw reply related
* [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: lantianyu1986 @ 2018-10-13 14:53 UTC (permalink / raw)
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, sthemmin, x86, michael.h.kelley,
mingo, jhogan, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, devel,
tglx, linux-arm-kernel, christoffer.dall, ralf, paul.burton,
pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181013145406.4911-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
This patch is to add wrapper functions for tlb_remote_flush_with_range
callback.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change sicne V3:
Remove code of updating "tlbs_dirty"
Change since V2:
Fix comment in the kvm_flush_remote_tlbs_with_range()
---
arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c73d9f650de7..ff656d85903a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
static union kvm_mmu_page_role
kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
+
+static inline bool kvm_available_flush_tlb_with_range(void)
+{
+ return kvm_x86_ops->tlb_remote_flush_with_range;
+}
+
+static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
+ struct kvm_tlb_range *range)
+{
+ int ret = -ENOTSUPP;
+
+ if (range && kvm_x86_ops->tlb_remote_flush_with_range)
+ ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+
+ if (ret)
+ kvm_flush_remote_tlbs(kvm);
+}
+
+static void kvm_flush_remote_tlbs_with_list(struct kvm *kvm,
+ struct list_head *flush_list)
+{
+ struct kvm_tlb_range range;
+
+ range.flush_list = flush_list;
+
+ kvm_flush_remote_tlbs_with_range(kvm, &range);
+}
+
+static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
+ u64 start_gfn, u64 pages)
+{
+ struct kvm_tlb_range range;
+
+ range.start_gfn = start_gfn;
+ range.pages = pages;
+ range.flush_list = NULL;
+
+ kvm_flush_remote_tlbs_with_range(kvm, &range);
+}
+
void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
{
BUG_ON((mmio_mask & mmio_value) != mmio_value);
--
2.14.4
^ permalink raw reply related
* [PATCH V4 3/15] KVM: Replace old tlb flush function with new one to flush a specified range.
From: lantianyu1986 @ 2018-10-13 14:53 UTC (permalink / raw)
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, sthemmin, x86, michael.h.kelley,
mingo, jhogan, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, devel,
tglx, linux-arm-kernel, christoffer.dall, ralf, paul.burton,
pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181013145406.4911-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_
remote_tlbs_with_address() in some functions without logic change.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
arch/x86/kvm/mmu.c | 31 +++++++++++++++++++++----------
arch/x86/kvm/paging_tmpl.h | 3 ++-
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ff656d85903a..9b9db36df103 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1490,8 +1490,12 @@ static bool __drop_large_spte(struct kvm *kvm, u64 *sptep)
static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
{
- if (__drop_large_spte(vcpu->kvm, sptep))
- kvm_flush_remote_tlbs(vcpu->kvm);
+ if (__drop_large_spte(vcpu->kvm, sptep)) {
+ struct kvm_mmu_page *sp = page_header(__pa(sptep));
+
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+ }
}
/*
@@ -1959,7 +1963,8 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64 *spte, gfn_t gfn)
rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
}
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
@@ -2475,7 +2480,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
account_shadowed(vcpu->kvm, sp);
if (level == PT_PAGE_TABLE_LEVEL &&
rmap_write_protect(vcpu, gfn))
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
flush |= kvm_sync_pages(vcpu, gfn, &invalid_list);
@@ -2595,7 +2600,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep,
return;
drop_parent_pte(child, sptep);
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1);
}
}
@@ -3019,8 +3024,10 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned pte_access,
ret = RET_PF_EMULATE;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
+
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
+ KVM_PAGES_PER_HPAGE(level));
if (unlikely(is_mmio_spte(*sptep)))
ret = RET_PF_EMULATE;
@@ -5695,7 +5702,8 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
* on PT_WRITABLE_MASK anymore.
*/
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
@@ -5759,7 +5767,8 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
* dirty_bitmap.
*/
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_leaf_clear_dirty);
@@ -5777,7 +5786,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct kvm *kvm,
lockdep_assert_held(&kvm->slots_lock);
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_largepage_remove_write_access);
@@ -5794,7 +5804,8 @@ void kvm_mmu_slot_set_dirty(struct kvm *kvm,
/* see kvm_mmu_slot_leaf_clear_dirty */
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 7cf2185b7eb5..6bdca39829bc 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -894,7 +894,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa)
pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
if (mmu_page_zap_pte(vcpu->kvm, sp, sptep))
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm,
+ sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level));
if (!rmap_can_add(vcpu))
break;
--
2.14.4
^ permalink raw reply related
* [PATCH V4 4/15] KVM: Make kvm_set_spte_hva() return int
From: lantianyu1986 @ 2018-10-13 14:53 UTC (permalink / raw)
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, sthemmin, x86, michael.h.kelley,
mingo, jhogan, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, devel,
tglx, linux-arm-kernel, christoffer.dall, ralf, paul.burton,
pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181013145406.4911-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
The patch is to make kvm_set_spte_hva() return int and caller can
check return value to determine flush tlb or not.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/mips/include/asm/kvm_host.h | 2 +-
arch/mips/kvm/mmu.c | 3 ++-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kvm/book3s.c | 3 ++-
arch/powerpc/kvm/e500_mmu_host.c | 3 ++-
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/mmu.c | 3 ++-
virt/kvm/arm/mmu.c | 6 ++++--
10 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 3ad482d2f1eb..efb820bdad2c 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -225,7 +225,7 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm,
unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d6d7336f871..2e506c0b3eb7 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -358,7 +358,7 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm,
unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 2c1c53d12179..71c3f21d80d5 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -933,7 +933,7 @@ enum kvm_mips_fault_result kvm_trap_emul_gva_fault(struct kvm_vcpu *vcpu,
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm,
unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
diff --git a/arch/mips/kvm/mmu.c b/arch/mips/kvm/mmu.c
index d8dcdb350405..97e538a8c1be 100644
--- a/arch/mips/kvm/mmu.c
+++ b/arch/mips/kvm/mmu.c
@@ -551,7 +551,7 @@ static int kvm_set_spte_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
(pte_dirty(old_pte) && !pte_dirty(hva_pte));
}
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
{
unsigned long end = hva + PAGE_SIZE;
int ret;
@@ -559,6 +559,7 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
ret = handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pte);
if (ret)
kvm_mips_callbacks->flush_shadow_all(kvm);
+ return 0;
}
static int kvm_age_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index fac6f631ed29..ab23379c53a9 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -72,7 +72,7 @@ extern int kvm_unmap_hva_range(struct kvm *kvm,
unsigned long start, unsigned long end);
extern int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
extern int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
-extern void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+extern int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
#define HPTEG_CACHE_NUM (1 << 15)
#define HPTEG_HASH_BITS_PTE 13
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index fd9893bc7aa1..437613bb609a 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -850,9 +850,10 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
return kvm->arch.kvm_ops->test_age_hva(kvm, hva);
}
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
{
kvm->arch.kvm_ops->set_spte_hva(kvm, hva, pte);
+ return 0;
}
void kvmppc_mmu_destroy(struct kvm_vcpu *vcpu)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 8f2985e46f6f..c3f312b2bcb3 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -757,10 +757,11 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
return 0;
}
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
{
/* The page will get remapped properly on its next fault */
kvm_unmap_hva(kvm, hva);
+ return 0;
}
/*****************************************/
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fea95aa77319..19985c602ed6 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1504,7 +1504,7 @@ asmlinkage void kvm_spurious_fault(void);
int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end);
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9b9db36df103..fd24a4dc45e9 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1918,9 +1918,10 @@ int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end)
return kvm_handle_hva_range(kvm, start, end, 0, kvm_unmap_rmapp);
}
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
{
kvm_handle_hva(kvm, hva, (unsigned long)&pte, kvm_set_pte_rmapp);
+ return 0;
}
static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index ed162a6c57c5..89a9c5fa9fd7 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1845,14 +1845,14 @@ static int kvm_set_spte_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data
}
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
{
unsigned long end = hva + PAGE_SIZE;
kvm_pfn_t pfn = pte_pfn(pte);
pte_t stage2_pte;
if (!kvm->arch.pgd)
- return;
+ return 0;
trace_kvm_set_spte_hva(hva);
@@ -1863,6 +1863,8 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
clean_dcache_guest_page(pfn, PAGE_SIZE);
stage2_pte = pfn_pte(pfn, PAGE_S2);
handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &stage2_pte);
+
+ return 0;
}
static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
--
2.14.4
^ permalink raw reply related
* Re: [PATCH 5/8] pcmcia: allow PCMCIA support independent of the architecture
From: Dominik Brodowski @ 2018-10-14 5:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-scsi, linux-kbuild, linux-pci, linux-kernel,
Masahiro Yamada, Alexandre Bounine, linuxppc-dev
In-Reply-To: <20181013151016.31674-6-hch@lst.de>
On Sat, Oct 13, 2018 at 05:10:13PM +0200, Christoph Hellwig wrote:
> There is nothing architecture specific in the PCMCIA core, so allow
> building it everywhere. The actual host controllers will depend on ISA,
> PCI or a specific SOC.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good to me, though I'm interested on any subtle (build) breakage when
this gets exposure in -next. Will you push this patch upstream directly, or
should it go in via the pcmcia tree? If it is the former, feel free to add
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Split user/kernel definitions of struct pt_regs
From: Madhavan Srinivasan @ 2018-10-14 6:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20181013105646.5147-1-mpe@ellerman.id.au>
On Saturday 13 October 2018 04:26 PM, Michael Ellerman wrote:
> We use a shared definition for struct pt_regs in uapi/asm/ptrace.h.
> That means the layout of the structure is ABI, ie. we can't change it.
>
> That would be fine if it was only used to describe the user-visible
> register state of a process, but it's also the struct we use in the
> kernel to describe the registers saved in an interrupt frame.
>
> We'd like more flexibility in the content (and possibly layout) of the
> kernel version of the struct, but currently that's not possible.
>
> So split the definition into a user-visible definition which remains
> unchanged, and a kernel internal one.
>
> At the moment they're still identical, and we check that at build
> time. That's because we have code (in ptrace etc.) that assumes that
> they are the same. We will fix that code in future patches, and then
> we can break the strict symmetry between the two structs.
Nice and awesome. But just trying to understand. What will
*regs will point to in the "struct sigcontext".
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/ptrace.h | 27 ++++++++++++++++++
> arch/powerpc/include/uapi/asm/ptrace.h | 7 ++++-
> arch/powerpc/kernel/ptrace.c | 39 ++++++++++++++++++++++++++
> 3 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 447cbd1bee99..3dd15024db93 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -26,6 +26,33 @@
> #include <uapi/asm/ptrace.h>
> #include <asm/asm-const.h>
>
> +#ifndef __ASSEMBLY__
> +struct pt_regs
> +{
> + union {
> + struct user_pt_regs user_regs;
> + struct {
> + unsigned long gpr[32];
> + unsigned long nip;
> + unsigned long msr;
> + unsigned long orig_gpr3;
> + unsigned long ctr;
> + unsigned long link;
> + unsigned long xer;
> + unsigned long ccr;
> +#ifdef CONFIG_PPC64
> + unsigned long softe;
> +#else
> + unsigned long mq;
> +#endif
> + unsigned long trap;
> + unsigned long dar;
> + unsigned long dsisr;
> + unsigned long result;
> + };
> + };
> +};
> +#endif
>
> #ifdef __powerpc64__
>
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h b/arch/powerpc/include/uapi/asm/ptrace.h
> index 55c7a131d2ab..f5f1ccc740fc 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -29,7 +29,12 @@
>
> #ifndef __ASSEMBLY__
>
> -struct pt_regs {
> +#ifdef __KERNEL__
> +struct user_pt_regs
> +#else
> +struct pt_regs
> +#endif
> +{
> unsigned long gpr[32];
> unsigned long nip;
> unsigned long msr;
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 4e372f54088f..939d7f81bbbe 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -3335,3 +3335,42 @@ void do_syscall_trace_leave(struct pt_regs *regs)
>
> user_enter();
> }
> +
> +void __init pt_regs_check(void)
> +{
> + BUILD_BUG_ON(offsetof(struct pt_regs, gpr) !=
> + offsetof(struct user_pt_regs, gpr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, nip) !=
> + offsetof(struct user_pt_regs, nip));
> + BUILD_BUG_ON(offsetof(struct pt_regs, msr) !=
> + offsetof(struct user_pt_regs, msr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, msr) !=
> + offsetof(struct user_pt_regs, msr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
> + offsetof(struct user_pt_regs, orig_gpr3));
> + BUILD_BUG_ON(offsetof(struct pt_regs, ctr) !=
> + offsetof(struct user_pt_regs, ctr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, link) !=
> + offsetof(struct user_pt_regs, link));
> + BUILD_BUG_ON(offsetof(struct pt_regs, xer) !=
> + offsetof(struct user_pt_regs, xer));
> + BUILD_BUG_ON(offsetof(struct pt_regs, ccr) !=
> + offsetof(struct user_pt_regs, ccr));
> +#ifdef __powerpc64__
> + BUILD_BUG_ON(offsetof(struct pt_regs, softe) !=
> + offsetof(struct user_pt_regs, softe));
> +#else
> + BUILD_BUG_ON(offsetof(struct pt_regs, mq) !=
> + offsetof(struct user_pt_regs, mq));
> +#endif
> + BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
> + offsetof(struct user_pt_regs, trap));
> + BUILD_BUG_ON(offsetof(struct pt_regs, dar) !=
> + offsetof(struct user_pt_regs, dar));
> + BUILD_BUG_ON(offsetof(struct pt_regs, dsisr) !=
> + offsetof(struct user_pt_regs, dsisr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, result) !=
> + offsetof(struct user_pt_regs, result));
> +
> + BUILD_BUG_ON(sizeof(struct user_pt_regs) > sizeof(struct pt_regs));
> +}
^ permalink raw reply
* Re: [PATCH v3 06/24] powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
From: Michael Ellerman @ 2018-10-14 7:02 UTC (permalink / raw)
To: Christophe Leroy, Bartlomiej Zolnierkiewicz,
Benjamin Herrenschmidt, Dominik Brodowski, Geoff Levand,
Jens Axboe, Kumar Gala, Li Yang, Nicholas Piggin, Paul Mackerras,
Scott Wood, aneesh.kumar
Cc: linux-fbdev, linux-kernel, dri-devel, linux-block, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <87d0sd19vm.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Set PAGE_KERNEL directly in the caller and do not rely on a
>> hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
>>
>> As already done for PPC64, use pgprot_cache() helpers instead of
>> _PAGE_XXX flags in PPC32 ioremap() derived functions.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Something in here is breaking my p5020ds (both 32-bit and 64-bit):
Oh duh.
That's because I didn't take patch 4.
It didn't have any acks, but I guess I'll just merge it rather than
breaking things.
cheers
^ permalink raw reply
* Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/
From: Thomas Gleixner @ 2018-10-14 6:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-scsi, linux-kbuild, linux-pci, linux-kernel,
Dominik Brodowski, Masahiro Yamada, Alexandre Bounine,
linuxppc-dev
In-Reply-To: <20181013151016.31674-1-hch@lst.de>
On Sat, 13 Oct 2018, Christoph Hellwig wrote:
> Hi all,
>
> currently every architecture that wants to provide on of the common
> periphal busses needs to add some boilerplate code and include the
> right Kconfig files. This series instead just selects the presence
> (when needed) and then handles everything in the bus-specific
> Kconfig file under drivers/.
Nice cleanup.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Liran Alon @ 2018-10-14 7:26 UTC (permalink / raw)
To: lantianyu1986
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, sthemmin, x86, michael.h.kelley,
mingo, jhogan, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, devel,
tglx, linux-arm-kernel, christoffer.dall, ralf, paul.burton,
pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181013145406.4911-3-Tianyu.Lan@microsoft.com>
> On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
>
> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
>
> This patch is to add wrapper functions for tlb_remote_flush_with_range
> callback.
>
> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> ---
> Change sicne V3:
> Remove code of updating "tlbs_dirty"
> Change since V2:
> Fix comment in the kvm_flush_remote_tlbs_with_range()
> ---
> arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index c73d9f650de7..ff656d85903a 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
> static union kvm_mmu_page_role
> kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
>
> +
> +static inline bool kvm_available_flush_tlb_with_range(void)
> +{
> + return kvm_x86_ops->tlb_remote_flush_with_range;
> +}
Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> +
> +static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
> + struct kvm_tlb_range *range)
> +{
> + int ret = -ENOTSUPP;
> +
> + if (range && kvm_x86_ops->tlb_remote_flush_with_range)
> + ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
> +
> + if (ret)
> + kvm_flush_remote_tlbs(kvm);
> +}
> +
> +static void kvm_flush_remote_tlbs_with_list(struct kvm *kvm,
> + struct list_head *flush_list)
> +{
> + struct kvm_tlb_range range;
> +
> + range.flush_list = flush_list;
> +
> + kvm_flush_remote_tlbs_with_range(kvm, &range);
> +}
> +
> +static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
> + u64 start_gfn, u64 pages)
> +{
> + struct kvm_tlb_range range;
> +
> + range.start_gfn = start_gfn;
> + range.pages = pages;
> + range.flush_list = NULL;
> +
> + kvm_flush_remote_tlbs_with_range(kvm, &range);
> +}
> +
> void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
> {
> BUG_ON((mmio_mask & mmio_value) != mmio_value);
> --
> 2.14.4
>
^ permalink raw reply
* Re: [PATCH v3 06/24] powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
From: LEROY Christophe @ 2018-10-14 7:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jens Axboe, Scott Wood, linux-fbdev, Dominik Brodowski,
Bartlomiej Zolnierkiewicz, Geoff Levand, Nicholas Piggin,
linux-kernel, dri-devel, Li Yang, linux-block, Paul Mackerras,
aneesh.kumar, linuxppc-dev, linux-arm-kernel
In-Reply-To: <87d0sd19vm.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Set PAGE_KERNEL directly in the caller and do not rely on a
>> hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
>>
>> As already done for PPC64, use pgprot_cache() helpers instead of
>> _PAGE_XXX flags in PPC32 ioremap() derived functions.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Something in here is breaking my p5020ds (both 32-bit and 64-bit):
>
> # first bad commit: [cb9220cc18345a2a1ec287752e576a2c88fa4a2b]
> powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
Strange, it is calling ioremap_prot(), it should have been calling
ioremap_cache() hence ioremap() since patch 4 of the serie. Did patch
4 apply correctly ?
Christophe
>
> 64-bit:
>
> io scheduler mq-deadline registered
> io scheduler kyber registered
> pcieport 0000:00:00.0: AER enabled with IRQ 482
> pcieport 2000:00:00.0: AER enabled with IRQ 480
> Unable to handle kernel paging request for data at address
> 0x8000080080080000
> Faulting instruction address: 0xc0000000000152e4
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE SMP NR_CPUS=32 CoreNet Generic
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.19.0-rc3-gcc-7.3.1-00135-gcb9220cc1834 #16
> NIP: c0000000000152e4 LR: c0000000005173b8 CTR: 0000000000100000
> REGS: c0000000f30eb420 TRAP: 0300 Not tainted
> (4.19.0-rc3-gcc-7.3.1-00135-gcb9220cc1834)
> MSR: 0000000080029000 <CE,EE,ME> CR: 24000224 XER: 00000000
> DEAR: 8000080080080000 ESR: 0000000000800000 IRQMASK: 0
> GPR00: c0000000005173a0 c0000000f30eb6a0 c000000000f86e00 8000080080080000
> GPR04: 0000000000000000 0000000000400000 00000ffbff000004 0000000000000008
> GPR08: 0000000000000000 0000000000100000 0000000000000000 0000000000000080
> GPR12: 0000000084000422 c00000003ffff7c0 c00000000000263c 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24: c000000000dbe0a0 c000000000d41bf8 8000080080080000 c0000000ffff89a8
> GPR28: c0000000f3492400 c0000000f3492410 0000000000400000 c000000000ff0a18
> NIP [c0000000000152e4] ._memset_io+0x6c/0x9c
> LR [c0000000005173b8] .fsl_qman_probe+0x188/0x918
> Call Trace:
> [c0000000f30eb6a0] [c0000000005173a0] .fsl_qman_probe+0x170/0x918
> (unreliable)
> [c0000000f30eb740] [c0000000005797dc] .platform_drv_probe+0x58/0xac
> [c0000000f30eb7c0] [c0000000005772b0] .really_probe+0x2a8/0x380
> [c0000000f30eb860] [c0000000005776f0] .__driver_attach+0x138/0x13c
> [c0000000f30eb8f0] [c000000000574550] .bus_for_each_dev+0x9c/0x110
> [c0000000f30eb9a0] [c000000000576a18] .driver_attach+0x24/0x38
> [c0000000f30eba10] [c0000000005761ec] .bus_add_driver+0x16c/0x2ac
> [c0000000f30ebab0] [c000000000578194] .driver_register+0x88/0x178
> [c0000000f30ebb30] [c000000000579770] .__platform_driver_register+0x48/0x5c
> [c0000000f30ebba0] [c000000000d85744] .fsl_qman_driver_init+0x1c/0x30
> [c0000000f30ebc10] [c000000000002374] .do_one_initcall+0x70/0x258
> [c0000000f30ebcf0] [c000000000d4a244] .kernel_init_freeable+0x340/0x43c
> [c0000000f30ebdb0] [c000000000002658] .kernel_init+0x1c/0x130
> [c0000000f30ebe30] [c0000000000009e4] .ret_from_kernel_thread+0x58/0x74
> Instruction dump:
> 4e800020 2ba50003 40dd003c 3925fffc 5488402e 7929f082 7d082378 39290001
> 550a801e 7d2903a6 7d4a4378 794a0020 <91430000> 38630004 4200fff8 70a50003
> ---[ end trace 372a57fd67efb6fe ]---
>
> 32 bit:
>
> [ 1.076133] pcieport 2000:02:00.0: AER enabled with IRQ 480
> [ 1.082106] Unable to handle kernel paging request for data at
> address 0xf1100000
> [ 1.089488] Faulting instruction address: 0xc0011c80
> [ 1.094437] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 1.099816] BE SMP NR_CPUS=24 CoreNet Generic
> [ 1.104157] Modules linked in:
> [ 1.107197] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.19.0-rc3-gcc7x-g8f0c636b0542 #1
> [ 1.115181] NIP: c0011c80 LR: c058f970 CTR: 00100000
> [ 1.120216] REGS: e8107c80 TRAP: 0300 Not tainted
> (4.19.0-rc3-gcc7x-g8f0c636b0542)
> [ 1.128026] MSR: 00029002 <CE,EE,ME> CR: 24000284 XER: 00000000
> [ 1.134190] DEAR: f1100000 ESR: 00800000
> [ 1.134190] GPR00: c058f958 e8107d30 e8108000 f1100000 00000000
> 00400000 e8107cd8 e8107d0c
> [ 1.134190] GPR08: 00000000 00100000 00000000 ff000000 24000282
> 00000000 c0003340 00000000
> [ 1.134190] GPR16: 00000000 00000000 00000000 00000000 c0d64410
> c0edb34c c0ec6700 00000007
> [ 1.134190] GPR24: c0ef0000 f1100000 efffcab8 c0ef0000 e8231c00
> e8231c10 0040003f c101d290
> [ 1.171519] NIP [c0011c80] _memset_io+0x90/0xd0
> [ 1.176030] LR [c058f970] fsl_qman_probe+0x190/0x8c0
> [ 1.180975] Call Trace:
> [ 1.183410] [e8107d30] [c001f6c0] ioremap_prot+0x40/0x50 (unreliable)
> [ 1.189830] [e8107d40] [c058f958] fsl_qman_probe+0x178/0x8c0
> [ 1.195475] [e8107d70] [c0600894] platform_drv_probe+0x54/0xb0
> [ 1.201287] [e8107d90] [c05fe15c] really_probe+0x28c/0x350
> [ 1.206756] [e8107dc0] [c05fe73c] __driver_attach+0x12c/0x130
> [ 1.212485] [e8107de0] [c05fb5a8] bus_for_each_dev+0x98/0x110
> [ 1.218213] [e8107e10] [c05fd048] bus_add_driver+0x158/0x2b0
> [ 1.223855] [e8107e40] [c05ff1c4] driver_register+0x94/0x180
> [ 1.229498] [e8107e60] [c0002fc4] do_one_initcall+0x54/0x2d0
> [ 1.235144] [e8107ed0] [c0d650e8] kernel_init_freeable+0x2e8/0x3bc
> [ 1.241302] [e8107f20] [c0003364] kernel_init+0x24/0x130
> [ 1.246599] [e8107f40] [c0015298] ret_from_kernel_thread+0x14/0x1c
> [ 1.252758] Instruction dump:
> [ 1.255711] 2b850003 40dd0040 5488402e 3925fffc 7d082378
> 5529f0be 550a801e 39290001
> [ 1.263435] 7d4a4378 7d2903a6 60000000 60000000 <91430000>
> 38630004 4200fff8 70a50003
> [ 1.271337] ---[ end trace f6eb249464967cf7 ]---
> [ 1.275934]
> [ 2.277413] BUG: sleeping function called from invalid context
> at ./include/linux/percpu-rwsem.h:34
> [ 2.286358] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
> [ 2.292956] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D
> 4.19.0-rc3-gcc7x-g8f0c636b0542 #1
> [ 2.302328] Call Trace:
> [ 2.304762] [e8107b80] [c0aa3774] dump_stack+0x88/0xc4 (unreliable)
> [ 2.311011] [e8107ba0] [c0074e10] ___might_sleep+0xe0/0x130
> [ 2.316567] [e8107bb0] [c0055410] exit_signals+0x50/0x2d0
> [ 2.321949] [e8107bf0] [c00434dc] do_exit+0xcc/0xad0
> [ 2.326897] [e8107c40] [c000ee98] die+0x228/0x390
> [ 2.331582] [e8107c70] [c00153f4] handle_page_fault+0x34/0x38
> [ 2.337311] --- interrupt: 300 at _memset_io+0x90/0xd0
> [ 2.337311] LR = fsl_qman_probe+0x190/0x8c0
> [ 2.346945] [e8107d30] [c001f6c0] ioremap_prot+0x40/0x50 (unreliable)
> [ 2.353368] [e8107d40] [c058f958] fsl_qman_probe+0x178/0x8c0
> [ 2.359010] [e8107d70] [c0600894] platform_drv_probe+0x54/0xb0
> [ 2.364825] [e8107d90] [c05fe15c] really_probe+0x28c/0x350
> [ 2.370294] [e8107dc0] [c05fe73c] __driver_attach+0x12c/0x130
> [ 2.376023] [e8107de0] [c05fb5a8] bus_for_each_dev+0x98/0x110
> [ 2.381751] [e8107e10] [c05fd048] bus_add_driver+0x158/0x2b0
> [ 2.387394] [e8107e40] [c05ff1c4] driver_register+0x94/0x180
> [ 2.393035] [e8107e60] [c0002fc4] do_one_initcall+0x54/0x2d0
> [ 2.398678] [e8107ed0] [c0d650e8] kernel_init_freeable+0x2e8/0x3bc
> [ 2.404840] [e8107f20] [c0003364] kernel_init+0x24/0x130
> [ 2.410135] [e8107f40] [c0015298] ret_from_kernel_thread+0x14/0x1c
> [ 2.416312] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
>
> cheers
^ permalink raw reply
* Re: [PATCH 5/8] pcmcia: allow PCMCIA support independent of the architecture
From: Christoph Hellwig @ 2018-10-14 7:40 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-arch, linux-scsi, linux-kbuild, linux-pci, linux-kernel,
Masahiro Yamada, Alexandre Bounine, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <20181014054252.GA24103@light.dominikbrodowski.net>
On Sun, Oct 14, 2018 at 07:42:52AM +0200, Dominik Brodowski wrote:
> On Sat, Oct 13, 2018 at 05:10:13PM +0200, Christoph Hellwig wrote:
> > There is nothing architecture specific in the PCMCIA core, so allow
> > building it everywhere. The actual host controllers will depend on ISA,
> > PCI or a specific SOC.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Looks good to me, though I'm interested on any subtle (build) breakage when
> this gets exposure in -next. Will you push this patch upstream directly, or
> should it go in via the pcmcia tree? If it is the former, feel free to add
The patches in the series depend on each other (just in terms of
context). I suspect the best would be to get it into the kbuild tree.
It has survived the build bot, which found some interesting issues in
the other patches (as well as the !UML dependency), but if more issues
show I can keep you in the loop.
^ permalink raw reply
* Re: [PATCH v05 4/5] migration/memory: Evaluate LMB assoc changes
From: kbuild test robot @ 2018-10-14 8:10 UTC (permalink / raw)
To: Michael Bringmann
Cc: Thomas Falcon, mwb, Juliet Kim, kbuild-all, Nathan Fontenot,
linuxppc-dev, Tyrel Datwyler
In-Reply-To: <20181013213531.4237.95830.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.19-rc7 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Michael-Bringmann/powerpc-migration-Affinity-fix-for-memory/20181014-130402
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
powerpc64-linux-gnu-ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
arch/powerpc/platforms/pseries/mobility.o: In function `.migration_store':
>> mobility.c:(.text+0x944): undefined reference to `.dlpar_memory_pmt_changes_action'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23972 bytes --]
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Thomas Gleixner @ 2018-10-14 8:16 UTC (permalink / raw)
To: Liran Alon
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, lantianyu1986, sthemmin, x86,
michael.h.kelley, mingo, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, devel, linux-arm-kernel, christoffer.dall,
ralf, paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <4D709C3A-A91C-4CA7-922A-E77618EF21B4@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
On Sun, 14 Oct 2018, Liran Alon wrote:
> > On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
> >
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > This patch is to add wrapper functions for tlb_remote_flush_with_range
> > callback.
> >
> > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > ---
> > Change sicne V3:
> > Remove code of updating "tlbs_dirty"
> > Change since V2:
> > Fix comment in the kvm_flush_remote_tlbs_with_range()
> > ---
> > arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index c73d9f650de7..ff656d85903a 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
> > static union kvm_mmu_page_role
> > kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
> >
> > +
> > +static inline bool kvm_available_flush_tlb_with_range(void)
> > +{
> > + return kvm_x86_ops->tlb_remote_flush_with_range;
> > +}
>
> Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
What's wrong with that?
It provides the implementation and later patches make use of it. It's a
sensible way to split patches into small, self contained entities.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Liran Alon @ 2018-10-14 9:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-mips, linux, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, hpa, kys, kvmarm, lantianyu1986, sthemmin, x86,
michael.h.kelley, mingo, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, devel, linux-arm-kernel, christoffer.dall,
ralf, paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <alpine.DEB.2.21.1810141014350.1438@nanos.tec.linutronix.de>
> On 14 Oct 2018, at 11:16, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sun, 14 Oct 2018, Liran Alon wrote:
>>> On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
>>>
>>> +
>>> +static inline bool kvm_available_flush_tlb_with_range(void)
>>> +{
>>> + return kvm_x86_ops->tlb_remote_flush_with_range;
>>> +}
>>
>> Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
>
> What's wrong with that?
>
> It provides the implementation and later patches make use of it. It's a
> sensible way to split patches into small, self contained entities.
>
> Thanks,
>
> tglx
>
I guess it’s a matter of taste, but I prefer to not add dead-code for patches
in order for each commit to compile nicely without warnings of declared and unused functions.
I would prefer to just add this utility function on the patch that actually use it.
-Liran
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Russell King - ARM Linux @ 2018-10-14 9:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-mips, linux, kvm, rkrcmar, will.deacon, linux-kernel, hpa,
kys, kvmarm, lantianyu1986, sthemmin, x86, michael.h.kelley,
mingo, catalin.marinas, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, Liran Alon, devel, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, pbonzini, vkuznets,
linuxppc-dev
In-Reply-To: <20181014092734.GV30658@n2100.armlinux.org.uk>
On Sun, Oct 14, 2018 at 10:27:34AM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 14, 2018 at 10:16:56AM +0200, Thomas Gleixner wrote:
> > On Sun, 14 Oct 2018, Liran Alon wrote:
> > > > On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
> > > >
> > > > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > > >
> > > > This patch is to add wrapper functions for tlb_remote_flush_with_range
> > > > callback.
> > > >
> > > > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > > > ---
> > > > Change sicne V3:
> > > > Remove code of updating "tlbs_dirty"
> > > > Change since V2:
> > > > Fix comment in the kvm_flush_remote_tlbs_with_range()
> > > > ---
> > > > arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 40 insertions(+)
> > > >
> > > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > > > index c73d9f650de7..ff656d85903a 100644
> > > > --- a/arch/x86/kvm/mmu.c
> > > > +++ b/arch/x86/kvm/mmu.c
> > > > @@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
> > > > static union kvm_mmu_page_role
> > > > kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
> > > >
> > > > +
> > > > +static inline bool kvm_available_flush_tlb_with_range(void)
> > > > +{
> > > > + return kvm_x86_ops->tlb_remote_flush_with_range;
> > > > +}
> > >
> > > Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> >
> > What's wrong with that?
> >
> > It provides the implementation and later patches make use of it. It's a
> > sensible way to split patches into small, self contained entities.
>
> From what I can see of the patches that follow _this_ patch in the
> series, this function remains unused. So, not only is it not used
> in this patch, it's not used in this series.
Note - I seem to have only received patches 1 through 4, so this is
based on the patches I've received.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Russell King - ARM Linux @ 2018-10-14 9:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-mips, linux, kvm, rkrcmar, will.deacon, christoffer.dall,
hpa, kys, kvmarm, lantianyu1986, sthemmin, x86, michael.h.kelley,
mingo, catalin.marinas, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, Liran Alon, pbonzini, linux-arm-kernel,
linux-kernel, ralf, paul.burton, devel, vkuznets, linuxppc-dev
In-Reply-To: <alpine.DEB.2.21.1810141014350.1438@nanos.tec.linutronix.de>
On Sun, Oct 14, 2018 at 10:16:56AM +0200, Thomas Gleixner wrote:
> On Sun, 14 Oct 2018, Liran Alon wrote:
> > > On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
> > >
> > > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > >
> > > This patch is to add wrapper functions for tlb_remote_flush_with_range
> > > callback.
> > >
> > > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > > ---
> > > Change sicne V3:
> > > Remove code of updating "tlbs_dirty"
> > > Change since V2:
> > > Fix comment in the kvm_flush_remote_tlbs_with_range()
> > > ---
> > > arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 40 insertions(+)
> > >
> > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > > index c73d9f650de7..ff656d85903a 100644
> > > --- a/arch/x86/kvm/mmu.c
> > > +++ b/arch/x86/kvm/mmu.c
> > > @@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
> > > static union kvm_mmu_page_role
> > > kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
> > >
> > > +
> > > +static inline bool kvm_available_flush_tlb_with_range(void)
> > > +{
> > > + return kvm_x86_ops->tlb_remote_flush_with_range;
> > > +}
> >
> > Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
>
> What's wrong with that?
>
> It provides the implementation and later patches make use of it. It's a
> sensible way to split patches into small, self contained entities.
From what I can see of the patches that follow _this_ patch in the
series, this function remains unused. So, not only is it not used
in this patch, it's not used in this series.
I think the real question that needs asking is - what is the plan
for this function, and when will it be used?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH v3 06/24] powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
From: LEROY Christophe @ 2018-10-14 9:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jens Axboe, Scott Wood, linux-fbdev, Dominik Brodowski,
Bartlomiej Zolnierkiewicz, Geoff Levand, Nicholas Piggin,
linux-kernel, dri-devel, Li Yang, linux-block, Paul Mackerras,
aneesh.kumar, linuxppc-dev, linux-arm-kernel
In-Reply-To: <87a7nh104q.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> a écrit :
> Michael Ellerman <mpe@ellerman.id.au> writes:
>
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>
>>> Set PAGE_KERNEL directly in the caller and do not rely on a
>>> hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
>>>
>>> As already done for PPC64, use pgprot_cache() helpers instead of
>>> _PAGE_XXX flags in PPC32 ioremap() derived functions.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> Something in here is breaking my p5020ds (both 32-bit and 64-bit):
>
> Oh duh.
>
> That's because I didn't take patch 4.
>
> It didn't have any acks, but I guess I'll just merge it rather than
> breaking things.
Yes indeed. Maybe should I have followed it more carrefully to ensure
it gets an ack.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH v3 06/24] powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
From: LEROY Christophe @ 2018-10-14 10:05 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jens Axboe, Scott Wood, linux-fbdev, Dominik Brodowski,
Bartlomiej Zolnierkiewicz, Geoff Levand, Nicholas Piggin,
linux-kernel, dri-devel, Li Yang, linux-block, Paul Mackerras,
aneesh.kumar, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20181014093957.Horde.CdijSMuadjLRcoigbh8m9A1@messagerie.si.c-s.fr>
LEROY Christophe <christophe.leroy@c-s.fr> a écrit :
> Michael Ellerman <mpe@ellerman.id.au> a écrit :
>
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>
>>> Set PAGE_KERNEL directly in the caller and do not rely on a
>>> hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
>>>
>>> As already done for PPC64, use pgprot_cache() helpers instead of
>>> _PAGE_XXX flags in PPC32 ioremap() derived functions.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> Something in here is breaking my p5020ds (both 32-bit and 64-bit):
>>
>> # first bad commit: [cb9220cc18345a2a1ec287752e576a2c88fa4a2b]
>> powerpc/mm: properly set PAGE_KERNEL flags in ioremap()
>
> Strange, it is calling ioremap_prot(), it should have been calling
> ioremap_cache() hence ioremap() since patch 4 of the serie. Did
> patch 4 apply correctly ?
Oops, forget that stupid comment. ioremap_cache() uses ioremap_prot()
but with the correct flags instead of 0
So patch 4 is needed anyway, because using 0 as flags will now not
anymore implicitely imply PAGE_KERNEL
Christophe
>
> Christophe
>
>>
>> 64-bit:
>>
>> io scheduler mq-deadline registered
>> io scheduler kyber registered
>> pcieport 0000:00:00.0: AER enabled with IRQ 482
>> pcieport 2000:00:00.0: AER enabled with IRQ 480
>> Unable to handle kernel paging request for data at address
>> 0x8000080080080000
>> Faulting instruction address: 0xc0000000000152e4
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> BE SMP NR_CPUS=32 CoreNet Generic
>> Modules linked in:
>> CPU: 1 PID: 1 Comm: swapper/0 Not tainted
>> 4.19.0-rc3-gcc-7.3.1-00135-gcb9220cc1834 #16
>> NIP: c0000000000152e4 LR: c0000000005173b8 CTR: 0000000000100000
>> REGS: c0000000f30eb420 TRAP: 0300 Not tainted
>> (4.19.0-rc3-gcc-7.3.1-00135-gcb9220cc1834)
>> MSR: 0000000080029000 <CE,EE,ME> CR: 24000224 XER: 00000000
>> DEAR: 8000080080080000 ESR: 0000000000800000 IRQMASK: 0
>> GPR00: c0000000005173a0 c0000000f30eb6a0 c000000000f86e00 8000080080080000
>> GPR04: 0000000000000000 0000000000400000 00000ffbff000004 0000000000000008
>> GPR08: 0000000000000000 0000000000100000 0000000000000000 0000000000000080
>> GPR12: 0000000084000422 c00000003ffff7c0 c00000000000263c 0000000000000000
>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR24: c000000000dbe0a0 c000000000d41bf8 8000080080080000 c0000000ffff89a8
>> GPR28: c0000000f3492400 c0000000f3492410 0000000000400000 c000000000ff0a18
>> NIP [c0000000000152e4] ._memset_io+0x6c/0x9c
>> LR [c0000000005173b8] .fsl_qman_probe+0x188/0x918
>> Call Trace:
>> [c0000000f30eb6a0] [c0000000005173a0] .fsl_qman_probe+0x170/0x918
>> (unreliable)
>> [c0000000f30eb740] [c0000000005797dc] .platform_drv_probe+0x58/0xac
>> [c0000000f30eb7c0] [c0000000005772b0] .really_probe+0x2a8/0x380
>> [c0000000f30eb860] [c0000000005776f0] .__driver_attach+0x138/0x13c
>> [c0000000f30eb8f0] [c000000000574550] .bus_for_each_dev+0x9c/0x110
>> [c0000000f30eb9a0] [c000000000576a18] .driver_attach+0x24/0x38
>> [c0000000f30eba10] [c0000000005761ec] .bus_add_driver+0x16c/0x2ac
>> [c0000000f30ebab0] [c000000000578194] .driver_register+0x88/0x178
>> [c0000000f30ebb30] [c000000000579770] .__platform_driver_register+0x48/0x5c
>> [c0000000f30ebba0] [c000000000d85744] .fsl_qman_driver_init+0x1c/0x30
>> [c0000000f30ebc10] [c000000000002374] .do_one_initcall+0x70/0x258
>> [c0000000f30ebcf0] [c000000000d4a244] .kernel_init_freeable+0x340/0x43c
>> [c0000000f30ebdb0] [c000000000002658] .kernel_init+0x1c/0x130
>> [c0000000f30ebe30] [c0000000000009e4] .ret_from_kernel_thread+0x58/0x74
>> Instruction dump:
>> 4e800020 2ba50003 40dd003c 3925fffc 5488402e 7929f082 7d082378 39290001
>> 550a801e 7d2903a6 7d4a4378 794a0020 <91430000> 38630004 4200fff8 70a50003
>> ---[ end trace 372a57fd67efb6fe ]---
>>
>> 32 bit:
>>
>> [ 1.076133] pcieport 2000:02:00.0: AER enabled with IRQ 480
>> [ 1.082106] Unable to handle kernel paging request for data at
>> address 0xf1100000
>> [ 1.089488] Faulting instruction address: 0xc0011c80
>> [ 1.094437] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 1.099816] BE SMP NR_CPUS=24 CoreNet Generic
>> [ 1.104157] Modules linked in:
>> [ 1.107197] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>> 4.19.0-rc3-gcc7x-g8f0c636b0542 #1
>> [ 1.115181] NIP: c0011c80 LR: c058f970 CTR: 00100000
>> [ 1.120216] REGS: e8107c80 TRAP: 0300 Not tainted
>> (4.19.0-rc3-gcc7x-g8f0c636b0542)
>> [ 1.128026] MSR: 00029002 <CE,EE,ME> CR: 24000284 XER: 00000000
>> [ 1.134190] DEAR: f1100000 ESR: 00800000
>> [ 1.134190] GPR00: c058f958 e8107d30 e8108000 f1100000 00000000
>> 00400000 e8107cd8 e8107d0c
>> [ 1.134190] GPR08: 00000000 00100000 00000000 ff000000 24000282
>> 00000000 c0003340 00000000
>> [ 1.134190] GPR16: 00000000 00000000 00000000 00000000 c0d64410
>> c0edb34c c0ec6700 00000007
>> [ 1.134190] GPR24: c0ef0000 f1100000 efffcab8 c0ef0000 e8231c00
>> e8231c10 0040003f c101d290
>> [ 1.171519] NIP [c0011c80] _memset_io+0x90/0xd0
>> [ 1.176030] LR [c058f970] fsl_qman_probe+0x190/0x8c0
>> [ 1.180975] Call Trace:
>> [ 1.183410] [e8107d30] [c001f6c0] ioremap_prot+0x40/0x50 (unreliable)
>> [ 1.189830] [e8107d40] [c058f958] fsl_qman_probe+0x178/0x8c0
>> [ 1.195475] [e8107d70] [c0600894] platform_drv_probe+0x54/0xb0
>> [ 1.201287] [e8107d90] [c05fe15c] really_probe+0x28c/0x350
>> [ 1.206756] [e8107dc0] [c05fe73c] __driver_attach+0x12c/0x130
>> [ 1.212485] [e8107de0] [c05fb5a8] bus_for_each_dev+0x98/0x110
>> [ 1.218213] [e8107e10] [c05fd048] bus_add_driver+0x158/0x2b0
>> [ 1.223855] [e8107e40] [c05ff1c4] driver_register+0x94/0x180
>> [ 1.229498] [e8107e60] [c0002fc4] do_one_initcall+0x54/0x2d0
>> [ 1.235144] [e8107ed0] [c0d650e8] kernel_init_freeable+0x2e8/0x3bc
>> [ 1.241302] [e8107f20] [c0003364] kernel_init+0x24/0x130
>> [ 1.246599] [e8107f40] [c0015298] ret_from_kernel_thread+0x14/0x1c
>> [ 1.252758] Instruction dump:
>> [ 1.255711] 2b850003 40dd0040 5488402e 3925fffc 7d082378
>> 5529f0be 550a801e 39290001
>> [ 1.263435] 7d4a4378 7d2903a6 60000000 60000000 <91430000>
>> 38630004 4200fff8 70a50003
>> [ 1.271337] ---[ end trace f6eb249464967cf7 ]---
>> [ 1.275934]
>> [ 2.277413] BUG: sleeping function called from invalid context
>> at ./include/linux/percpu-rwsem.h:34
>> [ 2.286358] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
>> [ 2.292956] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D
>> 4.19.0-rc3-gcc7x-g8f0c636b0542 #1
>> [ 2.302328] Call Trace:
>> [ 2.304762] [e8107b80] [c0aa3774] dump_stack+0x88/0xc4 (unreliable)
>> [ 2.311011] [e8107ba0] [c0074e10] ___might_sleep+0xe0/0x130
>> [ 2.316567] [e8107bb0] [c0055410] exit_signals+0x50/0x2d0
>> [ 2.321949] [e8107bf0] [c00434dc] do_exit+0xcc/0xad0
>> [ 2.326897] [e8107c40] [c000ee98] die+0x228/0x390
>> [ 2.331582] [e8107c70] [c00153f4] handle_page_fault+0x34/0x38
>> [ 2.337311] --- interrupt: 300 at _memset_io+0x90/0xd0
>> [ 2.337311] LR = fsl_qman_probe+0x190/0x8c0
>> [ 2.346945] [e8107d30] [c001f6c0] ioremap_prot+0x40/0x50 (unreliable)
>> [ 2.353368] [e8107d40] [c058f958] fsl_qman_probe+0x178/0x8c0
>> [ 2.359010] [e8107d70] [c0600894] platform_drv_probe+0x54/0xb0
>> [ 2.364825] [e8107d90] [c05fe15c] really_probe+0x28c/0x350
>> [ 2.370294] [e8107dc0] [c05fe73c] __driver_attach+0x12c/0x130
>> [ 2.376023] [e8107de0] [c05fb5a8] bus_for_each_dev+0x98/0x110
>> [ 2.381751] [e8107e10] [c05fd048] bus_add_driver+0x158/0x2b0
>> [ 2.387394] [e8107e40] [c05ff1c4] driver_register+0x94/0x180
>> [ 2.393035] [e8107e60] [c0002fc4] do_one_initcall+0x54/0x2d0
>> [ 2.398678] [e8107ed0] [c0d650e8] kernel_init_freeable+0x2e8/0x3bc
>> [ 2.404840] [e8107f20] [c0003364] kernel_init+0x24/0x130
>> [ 2.410135] [e8107f40] [c0015298] ret_from_kernel_thread+0x14/0x1c
>> [ 2.416312] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0000000b
>>
>> cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer
From: Michael Ellerman @ 2018-10-14 12:39 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, npiggin, mikey, oohall; +Cc: linuxppc-dev
In-Reply-To: <20181001230105.26040-1-anton@ozlabs.org>
Anton Blanchard <anton@ozlabs.org> writes:
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 70f145e02487..6a1f0a084ca3 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -1035,18 +1035,7 @@ static void __init set_decrementer_max(void)
>
> static void __init init_decrementer_clockevent(void)
> {
> - int cpu = smp_processor_id();
> -
> - clockevents_calc_mult_shift(&decrementer_clockevent, ppc_tb_freq, 4);
> -
> - decrementer_clockevent.max_delta_ns =
> - clockevent_delta2ns(decrementer_max, &decrementer_clockevent);
> - decrementer_clockevent.max_delta_ticks = decrementer_max;
> - decrementer_clockevent.min_delta_ns =
> - clockevent_delta2ns(2, &decrementer_clockevent);
> - decrementer_clockevent.min_delta_ticks = 2;
> -
> - register_decrementer_clockevent(cpu);
> + register_decrementer_clockevent(smp_processor_id());
> }
This broke KVM PR :)
Because we no longer set the mult/shift in decrementer_clockevent, which
is used in kvmppc_emulate_dec().
The patch below fixes it, though it'd be nice to come up with something
cleaner eventually.
cheers
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 6a1f0a084ca3..d21b2b88c0a7 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1036,6 +1036,9 @@ static void __init set_decrementer_max(void)
static void __init init_decrementer_clockevent(void)
{
register_decrementer_clockevent(smp_processor_id());
+
+ /* Set values for KVM, see kvm_emulate_dec() */
+ decrementer_clockevent = *dec;
}
void secondary_cpu_time_init(void)
^ permalink raw reply related
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Tianyu Lan @ 2018-10-14 12:57 UTC (permalink / raw)
To: liran.alon
Cc: linux-mips, linux, kvm, Radim Krcmar, catalin.marinas,
will.deacon, linux-kernel@vger kernel org, H. Peter Anvin, kys,
kvmarm, sthemmin, the arch/x86 maintainers, michael.h.kelley,
Ingo Molnar, jhogan, Tianyu Lan, marc.zyngier, haiyangz, kvm-ppc,
devel, Thomas Gleixner, linux-arm-kernel, christoffer.dall, ralf,
paul.burton, Paolo Bonzini, vkuznets, linuxppc-dev
In-Reply-To: <1BDC7949-CFED-46C2-9D05-42864B0AD0F0@oracle.com>
Hi Liran & Thomas:
Thanks for your review.
On Sun, Oct 14, 2018 at 5:20 PM Liran Alon <liran.alon@oracle.com> wrote:
>
>
>
> > On 14 Oct 2018, at 11:16, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Sun, 14 Oct 2018, Liran Alon wrote:
> >>> On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
> >>>
> >>> +
> >>> +static inline bool kvm_available_flush_tlb_with_range(void)
> >>> +{
> >>> + return kvm_x86_ops->tlb_remote_flush_with_range;
> >>> +}
> >>
> >> Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> >
> > What's wrong with that?
> >
> > It provides the implementation and later patches make use of it. It's a
> > sensible way to split patches into small, self contained entities.
> >
> > Thanks,
> >
> > tglx
> >
>
> I guess it’s a matter of taste, but I prefer to not add dead-code for patches
> in order for each commit to compile nicely without warnings of declared and unused functions.
> I would prefer to just add this utility function on the patch that actually use it.
>
> -Liran
>
Normally, I also prefer to put the function definition into the patch
which use it.
But the following patch "KVM: Replace old tlb flush function with new
one to flush a specified range"
and other patches which use new functions will change a lot of places.
It's not friendly for review and
so I split them into pieces.
--
Best regards
Tianyu Lan
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Tianyu Lan @ 2018-10-14 13:21 UTC (permalink / raw)
To: linux
Cc: linux-mips, linux, kvm, Radim Krcmar, will.deacon,
linux-kernel@vger kernel org, H. Peter Anvin, kys, kvmarm,
sthemmin, the arch/x86 maintainers, michael.h.kelley, Ingo Molnar,
catalin.marinas, jhogan, Tianyu Lan, marc.zyngier, haiyangz,
kvm-ppc, liran.alon, devel, Thomas Gleixner, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, Paolo Bonzini, vkuznets,
linuxppc-dev
In-Reply-To: <20181014093541.GW30658@n2100.armlinux.org.uk>
Hi Russell:
Thanks for your review.
On Sun, Oct 14, 2018 at 5:36 PM Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Sun, Oct 14, 2018 at 10:27:34AM +0100, Russell King - ARM Linux wrote:
> > On Sun, Oct 14, 2018 at 10:16:56AM +0200, Thomas Gleixner wrote:
> > > On Sun, 14 Oct 2018, Liran Alon wrote:
> > > > > On 13 Oct 2018, at 17:53, lantianyu1986@gmail.com wrote:
> > > > >
> > > > > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > > > >
> > > > > This patch is to add wrapper functions for tlb_remote_flush_with_range
> > > > > callback.
> > > > >
> > > > > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > > > > ---
> > > > > Change sicne V3:
> > > > > Remove code of updating "tlbs_dirty"
> > > > > Change since V2:
> > > > > Fix comment in the kvm_flush_remote_tlbs_with_range()
> > > > > ---
> > > > > arch/x86/kvm/mmu.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > > > > 1 file changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > > > > index c73d9f650de7..ff656d85903a 100644
> > > > > --- a/arch/x86/kvm/mmu.c
> > > > > +++ b/arch/x86/kvm/mmu.c
> > > > > @@ -264,6 +264,46 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
> > > > > static union kvm_mmu_page_role
> > > > > kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
> > > > >
> > > > > +
> > > > > +static inline bool kvm_available_flush_tlb_with_range(void)
> > > > > +{
> > > > > + return kvm_x86_ops->tlb_remote_flush_with_range;
> > > > > +}
> > > >
> > > > Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> > >
> > > What's wrong with that?
> > >
> > > It provides the implementation and later patches make use of it. It's a
> > > sensible way to split patches into small, self contained entities.
> >
> > From what I can see of the patches that follow _this_ patch in the
> > series, this function remains unused. So, not only is it not used
> > in this patch, it's not used in this series.
>
> Note - I seem to have only received patches 1 through 4, so this is
> based on the patches I've received.
>
Sorry to confuse your. I get from CCers from get_maintainer.pl script.
The next patch "[PATCH V4 3/15]KVM: Replace old tlb flush function with
new one to flush a specified range" calls new function.
https://lkml.org/lkml/2018/10/13/254
The patch "[PATCH V4 4/15] KVM: Make kvm_set_spte_hva() return int"
changes under ARM directory. Please have a look. Thanks.
--
Best regards
Tianyu Lan
^ permalink raw reply
* Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function
From: Russell King - ARM Linux @ 2018-10-14 13:33 UTC (permalink / raw)
To: Tianyu Lan
Cc: linux-mips, kvm, Radim Krcmar, will.deacon,
linux-kernel@vger kernel org, H. Peter Anvin, kys, kvmarm,
sthemmin, the arch/x86 maintainers, michael.h.kelley, Ingo Molnar,
catalin.marinas, jhogan, Tianyu Lan, marc.zyngier, haiyangz,
kvm-ppc, liran.alon, devel, Thomas Gleixner, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, Paolo Bonzini, vkuznets,
linuxppc-dev
In-Reply-To: <CAOLK0pzHAc1ipDbd3Trg2W_Gb_DxdEKM2ML5Fk09u0-O8y6UAg@mail.gmail.com>
On Sun, Oct 14, 2018 at 09:21:23PM +0800, Tianyu Lan wrote:
> Sorry to confuse your. I get from CCers from get_maintainer.pl script.
Unfortunately you seem to have made a mistake. My email address is
'linux@armlinux.org.uk' not 'linux@armlinux.org'. There is no
'linux@armlinux.org' in MAINTAINERS, yet your emails appear to be
copied to this address.
Consequently, if it was your intention to copy me with the entire
series, that didn't happen.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/pseries: Add driver for PAPR SCM regions
From: Oliver @ 2018-10-14 23:14 UTC (permalink / raw)
To: Dan Williams; +Cc: Nathan Fontenot, linuxppc-dev, linux-nvdimm@lists.01.org
In-Reply-To: <CAPcyv4jhs9f2DdOk30KU9___mWMtowQi0LP-OD1E+_5xFbxWgA@mail.gmail.com>
On Sat, Oct 13, 2018 at 9:37 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Oct 9, 2018 at 11:21 PM Oliver O'Halloran <oohall@gmail.com> wrote:
> >
> > Adds a driver that implements support for enabling and accessing PAPR
> > SCM regions. Unfortunately due to how the PAPR interface works we can't
> > use the existing of_pmem driver (yet) because:
> >
> > a) The guest is required to use the H_SCM_BIND_MEM h-call to add
> > add the SCM region to it's physical address space, and
> > b) There is currently no mechanism for relating a bare of_pmem region
> > to the backing DIMM (or not-a-DIMM for our case).
> >
> > Both of these are easily handled by rolling the functionality into a
> > seperate driver so here we are...
> >
> > Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> > ---
> > The alternative implementation here is that we have the pseries code
> > do the h-calls and craft a pmem-region@<addr> node based on that.
> > However, that doesn't solve b) and mpe has expressed his dislike of
> > adding new stuff to the DT at runtime so i'd say that's a non-starter.
> > ---
> > arch/powerpc/platforms/pseries/Kconfig | 7 +
> > arch/powerpc/platforms/pseries/Makefile | 1 +
> > arch/powerpc/platforms/pseries/papr_scm.c | 340 ++++++++++++++++++++++++++++++
> > 3 files changed, 348 insertions(+)
> > create mode 100644 arch/powerpc/platforms/pseries/papr_scm.c
> >
> > diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> > index 0c698fd6d491..4b0fcb80efe5 100644
> > --- a/arch/powerpc/platforms/pseries/Kconfig
> > +++ b/arch/powerpc/platforms/pseries/Kconfig
> > @@ -140,3 +140,10 @@ config IBMEBUS
> > bool "Support for GX bus based adapters"
> > help
> > Bus device driver for GX bus based adapters.
> > +
> > +config PAPR_SCM
> > + depends on PPC_PSERIES && MEMORY_HOTPLUG
> > + select LIBNVDIMM
> > + tristate "Support for the PAPR Storage Class Memory interface"
> > + help
> > + Enable access to hypervisor provided storage class memory.
> > diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> > index 892b27ced973..a43ec843c8e2 100644
> > --- a/arch/powerpc/platforms/pseries/Makefile
> > +++ b/arch/powerpc/platforms/pseries/Makefile
> > @@ -24,6 +24,7 @@ obj-$(CONFIG_IO_EVENT_IRQ) += io_event_irq.o
> > obj-$(CONFIG_LPARCFG) += lparcfg.o
> > obj-$(CONFIG_IBMVIO) += vio.o
> > obj-$(CONFIG_IBMEBUS) += ibmebus.o
> > +obj-$(CONFIG_PAPR_SCM) += papr_scm.o
> >
> > ifdef CONFIG_PPC_PSERIES
> > obj-$(CONFIG_SUSPEND) += suspend.o
> > diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> > new file mode 100644
> > index 000000000000..87d4dbc18845
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> > @@ -0,0 +1,340 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#define pr_fmt(fmt) "papr-scm: " fmt
> > +
> > +#include <linux/of.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/ioport.h>
> > +#include <linux/slab.h>
> > +#include <linux/ndctl.h>
> > +#include <linux/libnvdimm.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <asm/plpar_wrappers.h>
> > +
> > +#define BIND_ANY_ADDR (~0ul)
> > +
> > +#define PAPR_SCM_DIMM_CMD_MASK \
> > + ((1ul << ND_CMD_GET_CONFIG_SIZE) | \
> > + (1ul << ND_CMD_GET_CONFIG_DATA) | \
> > + (1ul << ND_CMD_SET_CONFIG_DATA))
> > +
> > +struct papr_scm_priv {
> > + struct platform_device *pdev;
> > + struct device_node *dn;
> > + uint32_t drc_index;
> > + uint64_t blocks;
> > + uint64_t block_size;
> > + int metadata_size;
> > +
> > + uint64_t bound_addr;
> > +
> > + struct nvdimm_bus_descriptor bus_desc;
> > + struct nvdimm_bus *bus;
> > + struct nvdimm *nvdimm;
> > + struct resource res;
> > + struct nd_region *region;
> > + struct nd_interleave_set nd_set;
> > +};
> > +
> > +static int drc_pmem_bind(struct papr_scm_priv *p)
> > +{
> > + unsigned long ret[PLPAR_HCALL_BUFSIZE];
> > + uint64_t rc, token;
> > +
> > + /*
> > + * When the hypervisor cannot map all the requested memory in a single
> > + * hcall it returns H_BUSY and we call again with the token until
> > + * we get H_SUCCESS. Aborting the retry loop before getting H_SUCCESS
> > + * leave the system in an undefined state, so we wait.
> > + */
> > + token = 0;
> > +
> > + do {
> > + rc = plpar_hcall(H_SCM_BIND_MEM, ret, p->drc_index, 0,
> > + p->blocks, BIND_ANY_ADDR, token);
> > + token = be64_to_cpu(ret[0]);
>
> Does plpar_hcall sleep? Should there be a cond_resched() here if not?
That's probably a good idea. The implementations I have to test with
never return H_BUSY and I had figured it just indicated that
>
> > + } while (rc == H_BUSY);
> > +
> > + if (rc) {
> > + dev_err(&p->pdev->dev, "bind err: %lld\n", rc);
> > + return -ENXIO;
> > + }
> > +
> > + p->bound_addr = be64_to_cpu(ret[1]);
> > +
> > + dev_dbg(&p->pdev->dev, "bound drc %x to %pR\n", p->drc_index, &p->res);
> > +
> > + return 0;
> > +}
> > +
> > +static int drc_pmem_unbind(struct papr_scm_priv *p)
> > +{
> > + unsigned long ret[PLPAR_HCALL_BUFSIZE];
> > + uint64_t rc, token;
> > +
> > + token = 0;
> > +
> > + /* NB: unbind has the same retry requirements mentioned above */
> > + do {
> > + rc = plpar_hcall(H_SCM_UNBIND_MEM, ret, p->drc_index,
> > + p->bound_addr, p->blocks, token);
> > + token = be64_to_cpu(ret);
>
> ...same busy loop comment.
>
> > + } while (rc == H_BUSY);
> > +
> > + if (rc)
> > + dev_err(&p->pdev->dev, "unbind error: %lld\n", rc);
> > +
> > + return !!rc;
> > +}
> > +
> > +static int papr_scm_meta_get(struct papr_scm_priv *p,
> > + struct nd_cmd_get_config_data_hdr *hdr)
> > +{
> > + unsigned long data[PLPAR_HCALL_BUFSIZE];
> > + int64_t ret;
> > +
> > + if (hdr->in_offset >= p->metadata_size || hdr->in_length != 1)
> > + return -EINVAL;
> > +
> > + ret = plpar_hcall(H_SCM_READ_METADATA, data, p->drc_index,
> > + hdr->in_offset, 1);
> > +
> > + if (ret == H_PARAMETER) /* bad DRC index */
> > + return -ENODEV;
> > + if (ret)
> > + return -EINVAL; /* other invalid parameter */
> > +
> > + hdr->out_buf[0] = data[0] & 0xff;
> > +
> > + return 0;
> > +}
> > +
> > +static int papr_scm_meta_set(struct papr_scm_priv *p,
> > + struct nd_cmd_set_config_hdr *hdr)
> > +{
> > + int64_t ret;
> > +
> > + if (hdr->in_offset >= p->metadata_size || hdr->in_length != 1)
> > + return -EINVAL;
> > +
> > + ret = plpar_hcall_norets(H_SCM_WRITE_METADATA,
> > + p->drc_index, hdr->in_offset, hdr->in_buf[0], 1);
> > +
> > + if (ret == H_PARAMETER) /* bad DRC index */
> > + return -ENODEV;
> > + if (ret)
> > + return -EINVAL; /* other invalid parameter */
> > +
> > + return 0;
> > +}
> > +
> > +int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
> > + unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
> > +{
> > + struct nd_cmd_get_config_size *get_size_hdr;
> > + struct papr_scm_priv *p;
> > +
> > + /* Only dimm-specific calls are supported atm */
> > + if (!nvdimm)
> > + return -EINVAL;
> > +
> > + p = nvdimm_provider_data(nvdimm);
> > +
> > + switch (cmd) {
> > + case ND_CMD_GET_CONFIG_SIZE:
> > + get_size_hdr = buf;
> > +
> > + get_size_hdr->status = 0;
> > + get_size_hdr->max_xfer = 1;
> > + get_size_hdr->config_size = p->metadata_size;
> > + *cmd_rc = 0;
> > + break;
> > +
> > + case ND_CMD_GET_CONFIG_DATA:
> > + *cmd_rc = papr_scm_meta_get(p, buf);
> > + break;
> > +
> > + case ND_CMD_SET_CONFIG_DATA:
> > + *cmd_rc = papr_scm_meta_set(p, buf);
> > + break;
> > +
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct attribute_group *region_attr_groups[] = {
> > + &nd_region_attribute_group,
> > + &nd_device_attribute_group,
> > + &nd_mapping_attribute_group,
> > + &nd_numa_attribute_group,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group *bus_attr_groups[] = {
> > + &nvdimm_bus_attribute_group,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group *papr_scm_dimm_groups[] = {
> > + &nvdimm_attribute_group,
> > + &nd_device_attribute_group,
> > + NULL,
> > +};
> > +
> > +static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> > +{
> > + struct device *dev = &p->pdev->dev;
> > + struct nd_mapping_desc mapping;
> > + struct nd_region_desc ndr_desc;
> > + unsigned long dimm_flags;
> > +
> > + p->bus_desc.ndctl = papr_scm_ndctl;
> > + p->bus_desc.module = THIS_MODULE;
> > + p->bus_desc.of_node = p->pdev->dev.of_node;
> > + p->bus_desc.attr_groups = bus_attr_groups;
> > + p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL);
> > +
> > + if (!p->bus_desc.provider_name)
> > + return -ENOMEM;
> > +
> > + p->bus = nvdimm_bus_register(NULL, &p->bus_desc);
> > + if (!p->bus) {
> > + dev_err(dev, "Error creating nvdimm bus %pOF\n", p->dn);
> > + return -ENXIO;
> > + }
> > +
> > + dimm_flags = 0;
> > + set_bit(NDD_ALIASING, &dimm_flags);
> > +
> > + p->nvdimm = nvdimm_create(p->bus, p, papr_scm_dimm_groups,
> > + dimm_flags, PAPR_SCM_DIMM_CMD_MASK, 0, NULL);
>
> Looks good, although I'm just about to push out commits that change
> this function signature to take a 'security_ops' pointer. If you need
> a stable branch to base this on, let me know.
>
> > + if (!p->nvdimm) {
> > + dev_err(dev, "Error creating DIMM object for %pOF\n", p->dn);
> > + goto err;
> > + }
> > +
> > + /* now add the region */
> > +
> > + memset(&mapping, 0, sizeof(mapping));
> > + mapping.nvdimm = p->nvdimm;
> > + mapping.start = p->res.start;
> > + mapping.size = p->blocks * p->block_size; // XXX: potential overflow?
>
> Ideally, should be nvdimm relative addresses. Since you have just a
> single DIMM per-region I would expect this to be 0 to
> nvdimm->region_size. That said I don't think anything breaks if you
> make the nvdimm address equal to the system-physical address, just
> wanted to point out the intent. This only matters when you have
> multiple DIMMs per region and need to record the per-DIMM contribution
> in the labels on each DIMM.
bleh
That's what I assumed originally. I wasn't sure so I looked at what
the NFIT driver did and confused myself by assuming the address field
of acpi_nfit_memory_map was an SPA.
>
> Other than that looks ok to me:
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> ...just the matter of what to do about function signature change.
^ permalink raw reply
* [PATCH v3 1/2] powerpc/pseries: PAPR persistent memory support
From: Oliver O'Halloran @ 2018-10-14 23:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, dan.j.williams, Oliver O'Halloran, linux-nvdimm
This patch implements support for discovering storage class memory
devices at boot and for handling hotplug of new regions via RTAS
hotplug events.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
v2: Added missing pmem.c
v3: no changes
---
arch/powerpc/include/asm/firmware.h | 3 +-
arch/powerpc/include/asm/hvcall.h | 10 +-
arch/powerpc/include/asm/rtas.h | 2 +
arch/powerpc/kernel/rtasd.c | 2 +
arch/powerpc/platforms/pseries/Makefile | 2 +-
arch/powerpc/platforms/pseries/dlpar.c | 4 +
arch/powerpc/platforms/pseries/firmware.c | 1 +
arch/powerpc/platforms/pseries/pmem.c | 164 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/pseries.h | 5 +
arch/powerpc/platforms/pseries/ras.c | 3 +-
10 files changed, 192 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/pmem.c
diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
index 7a051bd21f87..113c64d5d394 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -52,6 +52,7 @@
#define FW_FEATURE_PRRN ASM_CONST(0x0000000200000000)
#define FW_FEATURE_DRMEM_V2 ASM_CONST(0x0000000400000000)
#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000800000000)
+#define FW_FEATURE_PAPR_SCM ASM_CONST(0x0000001000000000)
#ifndef __ASSEMBLY__
@@ -69,7 +70,7 @@ enum {
FW_FEATURE_SET_MODE | FW_FEATURE_BEST_ENERGY |
FW_FEATURE_TYPE1_AFFINITY | FW_FEATURE_PRRN |
FW_FEATURE_HPT_RESIZE | FW_FEATURE_DRMEM_V2 |
- FW_FEATURE_DRC_INFO,
+ FW_FEATURE_DRC_INFO | FW_FEATURE_PAPR_SCM,
FW_FEATURE_PSERIES_ALWAYS = 0,
FW_FEATURE_POWERNV_POSSIBLE = FW_FEATURE_OPAL,
FW_FEATURE_POWERNV_ALWAYS = 0,
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index a0b17f9f1ea4..0e81ef83b35a 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -295,7 +295,15 @@
#define H_INT_ESB 0x3C8
#define H_INT_SYNC 0x3CC
#define H_INT_RESET 0x3D0
-#define MAX_HCALL_OPCODE H_INT_RESET
+#define H_SCM_READ_METADATA 0x3E4
+#define H_SCM_WRITE_METADATA 0x3E8
+#define H_SCM_BIND_MEM 0x3EC
+#define H_SCM_UNBIND_MEM 0x3F0
+#define H_SCM_QUERY_BLOCK_MEM_BINDING 0x3F4
+#define H_SCM_QUERY_LOGICAL_MEM_BINDING 0x3F8
+#define H_SCM_MEM_QUERY 0x3FC
+#define H_SCM_BLOCK_CLEAR 0x400
+#define MAX_HCALL_OPCODE H_SCM_BLOCK_CLEAR
/* H_VIOCTL functions */
#define H_GET_VIOA_DUMP_SIZE 0x01
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 71e393c46a49..1e81f3d55457 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -125,6 +125,7 @@ struct rtas_suspend_me_data {
#define RTAS_TYPE_INFO 0xE2
#define RTAS_TYPE_DEALLOC 0xE3
#define RTAS_TYPE_DUMP 0xE4
+#define RTAS_TYPE_HOTPLUG 0xE5
/* I don't add PowerMGM events right now, this is a different topic */
#define RTAS_TYPE_PMGM_POWER_SW_ON 0x60
#define RTAS_TYPE_PMGM_POWER_SW_OFF 0x61
@@ -316,6 +317,7 @@ struct pseries_hp_errorlog {
#define PSERIES_HP_ELOG_RESOURCE_MEM 2
#define PSERIES_HP_ELOG_RESOURCE_SLOT 3
#define PSERIES_HP_ELOG_RESOURCE_PHB 4
+#define PSERIES_HP_ELOG_RESOURCE_PMEM 6
#define PSERIES_HP_ELOG_ACTION_ADD 1
#define PSERIES_HP_ELOG_ACTION_REMOVE 2
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 44d66c33d59d..088fe9edd13e 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -91,6 +91,8 @@ static char *rtas_event_type(int type)
return "Dump Notification Event";
case RTAS_TYPE_PRRN:
return "Platform Resource Reassignment Event";
+ case RTAS_TYPE_HOTPLUG:
+ return "Hotplug Event";
}
return rtas_type[0];
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 7e89d5c47068..892b27ced973 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_KEXEC_CORE) += kexec.o
obj-$(CONFIG_PSERIES_ENERGY) += pseries_energy.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o
-obj-$(CONFIG_MEMORY_HOTPLUG) += hotplug-memory.o
+obj-$(CONFIG_MEMORY_HOTPLUG) += hotplug-memory.o pmem.o
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index a0b20c03f078..795996fefdb9 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -357,6 +357,10 @@ static int handle_dlpar_errorlog(struct pseries_hp_errorlog *hp_elog)
case PSERIES_HP_ELOG_RESOURCE_CPU:
rc = dlpar_cpu(hp_elog);
break;
+ case PSERIES_HP_ELOG_RESOURCE_PMEM:
+ rc = dlpar_hp_pmem(hp_elog);
+ break;
+
default:
pr_warn_ratelimited("Invalid resource (%d) specified\n",
hp_elog->resource);
diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platforms/pseries/firmware.c
index a3bbeb43689e..4927de57d8ee 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -65,6 +65,7 @@ hypertas_fw_features_table[] = {
{FW_FEATURE_SET_MODE, "hcall-set-mode"},
{FW_FEATURE_BEST_ENERGY, "hcall-best-energy-1*"},
{FW_FEATURE_HPT_RESIZE, "hcall-hpt-resize"},
+ {FW_FEATURE_PAPR_SCM, "hcall-scm"},
};
/* Build up the firmware features bitmask using the contents of
diff --git a/arch/powerpc/platforms/pseries/pmem.c b/arch/powerpc/platforms/pseries/pmem.c
new file mode 100644
index 000000000000..a27f40eb57b1
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/pmem.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Handles hot and cold plug of persistent memory regions on pseries.
+ */
+
+#define pr_fmt(fmt) "pseries-pmem: " fmt
+
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/sched.h> /* for idle_task_exit */
+#include <linux/sched/hotplug.h>
+#include <linux/cpu.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+#include <asm/prom.h>
+#include <asm/rtas.h>
+#include <asm/firmware.h>
+#include <asm/machdep.h>
+#include <asm/vdso_datapage.h>
+#include <asm/plpar_wrappers.h>
+#include <asm/topology.h>
+
+#include "pseries.h"
+#include "offline_states.h"
+
+static struct device_node *pmem_node;
+
+static ssize_t pmem_drc_add_node(u32 drc_index)
+{
+ struct device_node *dn;
+ int rc;
+
+ pr_debug("Attempting to add pmem node, drc index: %x\n", drc_index);
+
+ rc = dlpar_acquire_drc(drc_index);
+ if (rc) {
+ pr_err("Failed to acquire DRC, rc: %d, drc index: %x\n",
+ rc, drc_index);
+ return -EINVAL;
+ }
+
+ dn = dlpar_configure_connector(cpu_to_be32(drc_index), pmem_node);
+ if (!dn) {
+ pr_err("configure-connector failed for drc %x\n", drc_index);
+ dlpar_release_drc(drc_index);
+ return -EINVAL;
+ }
+
+ /* NB: The of reconfig notifier creates platform device from the node */
+ rc = dlpar_attach_node(dn, pmem_node);
+ if (rc) {
+ pr_err("Failed to attach node %s, rc: %d, drc index: %x\n",
+ dn->name, rc, drc_index);
+
+ if (dlpar_release_drc(drc_index))
+ dlpar_free_cc_nodes(dn);
+
+ return rc;
+ }
+
+ pr_info("Successfully added %pOF, drc index: %x\n", dn, drc_index);
+
+ return 0;
+}
+
+static ssize_t pmem_drc_remove_node(u32 drc_index)
+{
+ struct device_node *dn;
+ uint32_t index;
+ int rc;
+
+ for_each_child_of_node(pmem_node, dn) {
+ if (of_property_read_u32(dn, "ibm,my-drc-index", &index))
+ continue;
+ if (index == drc_index)
+ break;
+ }
+
+ if (!dn) {
+ pr_err("Attempting to remove unused DRC index %x\n", drc_index);
+ return -ENODEV;
+ }
+
+ pr_debug("Attempting to remove %pOF, drc index: %x\n", dn, drc_index);
+
+ /* * NB: tears down the ibm,pmemory device as a side-effect */
+ rc = dlpar_detach_node(dn);
+ if (rc)
+ return rc;
+
+ rc = dlpar_release_drc(drc_index);
+ if (rc) {
+ pr_err("Failed to release drc (%x) for CPU %s, rc: %d\n",
+ drc_index, dn->name, rc);
+ dlpar_attach_node(dn, pmem_node);
+ return rc;
+ }
+
+ pr_info("Successfully removed PMEM with drc index: %x\n", drc_index);
+
+ return 0;
+}
+
+int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
+{
+ u32 count, drc_index;
+ int rc;
+
+ /* slim chance, but we might get a hotplug event while booting */
+ if (!pmem_node)
+ pmem_node = of_find_node_by_type(NULL, "ibm,persistent-memory");
+ if (!pmem_node) {
+ pr_err("Hotplug event for a pmem device, but none exists\n");
+ return -ENODEV;
+ }
+
+ if (hp_elog->id_type != PSERIES_HP_ELOG_ID_DRC_INDEX) {
+ pr_err("Unsupported hotplug event type %d\n",
+ hp_elog->id_type);
+ return -EINVAL;
+ }
+
+ count = hp_elog->_drc_u.drc_count;
+ drc_index = hp_elog->_drc_u.drc_index;
+
+ lock_device_hotplug();
+
+ if (hp_elog->action == PSERIES_HP_ELOG_ACTION_ADD) {
+ rc = pmem_drc_add_node(drc_index);
+ } else if (hp_elog->action == PSERIES_HP_ELOG_ACTION_REMOVE) {
+ rc = pmem_drc_remove_node(drc_index);
+ } else {
+ pr_err("Unsupported hotplug action (%d)\n", hp_elog->action);
+ rc = -EINVAL;
+ }
+
+ unlock_device_hotplug();
+ return rc;
+}
+
+const struct of_device_id drc_pmem_match[] = {
+ { .type = "ibm,persistent-memory", },
+ {}
+};
+
+static int pseries_pmem_init(void)
+{
+ pmem_node = of_find_node_by_type(NULL, "ibm,persistent-memory");
+ if (!pmem_node)
+ return 0;
+
+ /*
+ * The generic OF bus probe/populate handles creating platform devices
+ * from the child (ibm,pmemory) nodes. The generic code registers an of
+ * reconfig notifier to handle the hot-add/remove cases too.
+ */
+ of_platform_bus_probe(pmem_node, drc_pmem_match, NULL);
+
+ return 0;
+}
+machine_arch_initcall(pseries, pseries_pmem_init);
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 60db2ee511fb..d0829677c896 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -63,11 +63,16 @@ void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog,
struct completion *hotplug_done, int *rc);
#ifdef CONFIG_MEMORY_HOTPLUG
int dlpar_memory(struct pseries_hp_errorlog *hp_elog);
+int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog);
#else
static inline int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
{
return -EOPNOTSUPP;
}
+int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
+{
+ return -EOPNOTSUPP;
+};
#endif
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index 851ce326874a..ae22fc007276 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -237,7 +237,8 @@ static irqreturn_t ras_hotplug_interrupt(int irq, void *dev_id)
* hotplug events on the ras_log_buf to be handled by rtas_errd.
*/
if (hp_elog->resource == PSERIES_HP_ELOG_RESOURCE_MEM ||
- hp_elog->resource == PSERIES_HP_ELOG_RESOURCE_CPU)
+ hp_elog->resource == PSERIES_HP_ELOG_RESOURCE_CPU ||
+ hp_elog->resource == PSERIES_HP_ELOG_RESOURCE_PMEM)
queue_hotplug_event(hp_elog, NULL, NULL);
else
log_error(ras_log_buf, ERR_TYPE_RTAS_LOG, 0);
--
2.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox