[PATCH V2 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support
Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
with specified ranges. This patch is to add the hypercall support.
Signed-off-by: Lan Tianyu
---
Change since v1:
Add hyperv tlb flush struct to avoid use kvm tlb flush struct
in the hyperv file.
---
arch/x86/hyperv/nested.c | 103 +
arch/x86/include/asm/hyperv-tlfs.h | 17 ++
arch/x86/include/asm/mshyperv.h| 16 ++
3 files changed, 136 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index b8e60cc50461..40ddbfd54573 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -7,15 +7,32 @@
*
* Author : Lan Tianyu
*/
+#define pr_fmt(fmt) "Hyper-V: " fmt
#include
#include
#include
#include
+#include
#include
+/*
+ * MAX_FLUSH_PAGES = "additional_pages" + 1. It's limited
+ * by the bitwidth of "additional_pages" in union hv_gpa_page_range.
+ */
+#define MAX_FLUSH_PAGES (2048)
+
+/*
+ * All input flush parameters are in single page. The max flush count
+ * is equal with how many entries of union hv_gpa_page_range can be
+ * populated in the input parameter page. MAX_FLUSH_REP_COUNT
+ * = (4096 - 16) / 8. (“Page Size” - "Address Space" - "Flags") /
+ * "GPA Range".
+ */
+#define MAX_FLUSH_REP_COUNT (510)
+
int hyperv_flush_guest_mapping(u64 as)
{
struct hv_guest_mapping_flush **flush_pcpu;
@@ -54,3 +71,89 @@ int hyperv_flush_guest_mapping(u64 as)
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
+
+static int fill_flush_list(union hv_gpa_page_range gpa_list[],
+ int offset, u64 start_gfn, u64 pages)
+{
+ int gpa_n = offset;
+ u64 cur = start_gfn;
+ u64 additional_pages;
+
+ do {
+ if (gpa_n >= MAX_FLUSH_REP_COUNT) {
+ pr_warn("Request exceeds HvFlushGuestList max flush
count.");
+ return -ENOSPC;
+ }
+
+ if (pages > MAX_FLUSH_PAGES) {
+ additional_pages = MAX_FLUSH_PAGES - 1;
+ pages -= MAX_FLUSH_PAGES;
+ } else {
+ additional_pages = pages - 1;
+ pages = 0;
+ }
+
+ gpa_list[gpa_n].page.additional_pages = additional_pages;
+ gpa_list[gpa_n].page.largepage = false;
+ gpa_list[gpa_n].page.basepfn = cur;
+
+ cur += additional_pages + 1;
+ gpa_n++;
+ } while (pages > 0);
+
+ return gpa_n;
+}
+
+int hyperv_flush_guest_mapping_range(u64 as, struct hyperv_tlb_range *range)
+{
+ struct hv_guest_mapping_flush_list **flush_pcpu;
+ struct hv_guest_mapping_flush_list *flush;
+ u64 status = 0;
+ unsigned long flags;
+ int ret = -ENOTSUPP;
+ int gpa_n = 0;
+
+ if (!hv_hypercall_pg)
+ goto fault;
+
+ local_irq_save(flags);
+
+ flush_pcpu = (struct hv_guest_mapping_flush_list **)
+ this_cpu_ptr(hyperv_pcpu_input_arg);
+
+ flush = *flush_pcpu;
+ if (unlikely(!flush)) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ flush->address_space = as;
+ flush->flags = 0;
+
+ if (!range->flush_list)
+ gpa_n = fill_flush_list(flush->gpa_list, gpa_n,
+ range->start_gfn, range->pages);
+ else if (range->parse_flush_list_func)
+ gpa_n = range->parse_flush_list_func(flush->gpa_list, gpa_n,
+ range->flush_list, fill_flush_list);
+ else
+ gpa_n = -1;
+
+ if (gpa_n < 0) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ status = hv_do_rep_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST,
+gpa_n, 0, flush, NULL);
+
+ local_irq_restore(flags);
+
+ if (!(status & HV_HYPERCALL_RESULT_MASK))
+ ret = 0;
+ else
+ ret = status;
+fault:
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index e977b6b3a538..512f22b4 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -353,6 +353,7 @@ struct hv_tsc_emulation_status {
#define HVCALL_POST_MESSAGE0x005c
#define HVCALL_SIGNAL_EVENT0x005d
#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
#define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE 0x0001
#define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT12
@@ -750,6 +751,22 @@ struct hv_guest_mapping_flush {
u64 flags;
};
+/* HvFlushGuestPhysicalAddressList hypercall */
+union hv_gpa_page_range {
+ u64 address_space;
+ struct {
+
[PATCH V2 6/13] KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()
kvm_mmu_zap_collapsible_spte() returns flush request to the
slot_handle_leaf() and the latter does flush on demand. When
range flush is available, make kvm_mmu_zap_collapsible_spte()
to flush tlb with range directly to avoid returning range back
to slot_handle_leaf().
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 56538fa6c017..85a81a62e0a7 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5674,7 +5674,13 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
!kvm_is_reserved_pfn(pfn) &&
PageTransCompoundMap(pfn_to_page(pfn))) {
drop_spte(kvm, sptep);
- need_tlb_flush = 1;
+
+ if (kvm_available_flush_tlb_with_range())
+ kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+ else
+ need_tlb_flush = 1;
+
goto restart;
}
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()
This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().
Signed-off-by: Lan Tianyu
---
arch/x86/hyperv/nested.c| 1 +
arch/x86/include/asm/trace/hyperv.h | 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 40ddbfd54573..ae7181c6ede4 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -154,6 +154,7 @@ int hyperv_flush_guest_mapping_range(u64 as, struct
hyperv_tlb_range *range)
else
ret = status;
fault:
+ trace_hyperv_nested_flush_guest_mapping_range(as, ret);
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h
b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
);
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+ TP_PROTO(u64 as, int ret),
+ TP_ARGS(as, ret),
+
+ TP_STRUCT__entry(
+ __field(u64, as)
+ __field(int, ret)
+ ),
+ TP_fast_assign(__entry->as = as;
+ __entry->ret = ret;
+ ),
+ TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+ );
+
TRACE_EVENT(hyperv_send_ipi_mask,
TP_PROTO(const struct cpumask *cpus,
int vector),
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 8/13] KVM: Add spte's point in the struct kvm_mmu_page
It's necessary to check whether mmu page is last or large page when add
mmu page into flush list. "spte" is needed for such check and so add
spte point in the struct kvm_mmu_page.
Signed-off-by: Lan Tianyu
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu.c | 5 +
arch/x86/kvm/paging_tmpl.h | 2 ++
3 files changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c96bc4cbe4b7..d42d96e637b5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -296,6 +296,7 @@ struct kvm_mmu_page {
int root_count; /* Currently serving as active root */
unsigned int unsync_children;
struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
+ u64 *sptep;
/* The page is obsolete if mmu_valid_gen != kvm->arch.mmu_valid_gen. */
unsigned long mmu_valid_gen;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 85a81a62e0a7..8f27cb8c3989 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3162,6 +3162,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
pseudo_gfn = base_addr >> PAGE_SHIFT;
sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
iterator.level - 1, 1, ACC_ALL);
+ sp->sptep = iterator.sptep;
link_shadow_page(vcpu, iterator.sptep, sp);
}
@@ -3599,6 +3600,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
sp = kvm_mmu_get_page(vcpu, 0, 0,
vcpu->arch.mmu.shadow_root_level, 1, ACC_ALL);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = __pa(sp->spt);
} else if (vcpu->arch.mmu.shadow_root_level == PT32E_ROOT_LEVEL) {
@@ -3615,6 +3617,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
i << 30, PT32_ROOT_LEVEL, 1, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | PT_PRESENT_MASK;
}
@@ -3655,6 +3658,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
vcpu->arch.mmu.shadow_root_level, 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = root;
return 0;
@@ -3692,6 +3696,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | pm_mask;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 708a5e44861a..5cbaf7c4a729 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -632,6 +632,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
table_gfn = gw->table_gfn[it.level - 2];
sp = kvm_mmu_get_page(vcpu, table_gfn, addr, it.level-1,
false, access);
+ sp->sptep = it.sptep;
}
/*
@@ -662,6 +663,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
true, direct_access);
+ sp->sptep = it.sptep;
link_shadow_page(vcpu, it.sptep, sp);
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 5/13] KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
Originally, flush tlb is done by slot_handle_level_range(). This patch
is to flush tlb directly in the kvm_zap_gfn_range() when range
flush is available.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index dfd2a0710417..56538fa6c017 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5578,6 +5578,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start,
gfn_t gfn_end)
{
struct kvm_memslots *slots;
struct kvm_memory_slot *memslot;
+ bool flush = false;
int i;
spin_lock(>mmu_lock);
@@ -5585,18 +5586,27 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t
gfn_start, gfn_t gfn_end)
slots = __kvm_memslots(kvm, i);
kvm_for_each_memslot(memslot, slots) {
gfn_t start, end;
+ bool flush_tlb = true;
start = max(gfn_start, memslot->base_gfn);
end = min(gfn_end, memslot->base_gfn + memslot->npages);
if (start >= end)
continue;
- slot_handle_level_range(kvm, memslot, kvm_zap_rmapp,
- PT_PAGE_TABLE_LEVEL,
PT_MAX_HUGEPAGE_LEVEL,
- start, end - 1, true);
+ if (kvm_available_flush_tlb_with_range())
+ flush_tlb = false;
+
+ flush = slot_handle_level_range(kvm, memslot,
+ kvm_zap_rmapp, PT_PAGE_TABLE_LEVEL,
+ PT_MAX_HUGEPAGE_LEVEL, start,
+ end - 1, flush_tlb);
}
}
+ if (flush && kvm_available_flush_tlb_with_range())
+ kvm_flush_remote_tlbs_with_address(kvm, gfn_start,
+ gfn_end - gfn_start + 1);
+
spin_unlock(>mmu_lock);
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 9/13] KVM/MMU: Replace tlb flush function with range list flush function
This patch is to use range list flush function in the
mmu_sync_children(), kvm_mmu_commit_zap_page() and
FNAME(sync_page)().
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 26 +++---
arch/x86/kvm/paging_tmpl.h | 5 -
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 8f27cb8c3989..0390e67715ee 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1092,6 +1092,13 @@ static void update_gfn_disallow_lpage_count(struct
kvm_memory_slot *slot,
}
}
+static void kvm_mmu_queue_flush_request(struct kvm_mmu_page *sp,
+ struct list_head *flush_list)
+{
+ if (sp->sptep && is_last_spte(*sp->sptep, sp->role.level))
+ list_add(>flush_link, flush_list);
+}
+
void kvm_mmu_gfn_disallow_lpage(struct kvm_memory_slot *slot, gfn_t gfn)
{
update_gfn_disallow_lpage_count(slot, gfn, 1);
@@ -2369,12 +2376,16 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
while (mmu_unsync_walk(parent, )) {
bool protected = false;
+ LIST_HEAD(flush_list);
- for_each_sp(pages, sp, parents, i)
+ for_each_sp(pages, sp, parents, i) {
protected |= rmap_write_protect(vcpu, sp->gfn);
+ kvm_mmu_queue_flush_request(sp, _list);
+ }
if (protected) {
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_list(vcpu->kvm,
+ _list);
flush = false;
}
@@ -2710,6 +2721,7 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
{
struct kvm_mmu_page *sp, *nsp;
+ LIST_HEAD(flush_list);
if (list_empty(invalid_list))
return;
@@ -2723,7 +2735,15 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
* In addition, kvm_flush_remote_tlbs waits for all vcpus to exit
* guest mode and/or lockless shadow page table walks.
*/
- kvm_flush_remote_tlbs(kvm);
+ if (kvm_available_flush_tlb_with_range()) {
+ list_for_each_entry(sp, invalid_list, link)
+ kvm_mmu_queue_flush_request(sp, _list);
+
+ if (!list_empty(_list))
+ kvm_flush_remote_tlbs_with_list(kvm, _list);
+ } else {
+ kvm_flush_remote_tlbs(kvm);
+ }
list_for_each_entry_safe(sp, nsp, invalid_list, link) {
WARN_ON(!sp->role.invalid || sp->root_count);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 5cbaf7c4a729..a5f967e81429 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -972,6 +972,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, struct
kvm_mmu_page *sp)
bool host_writable;
gpa_t first_pte_gpa;
int set_spte_ret = 0;
+ LIST_HEAD(flush_list);
/* direct kvm_mmu_page can not be unsync. */
BUG_ON(sp->role.direct);
@@ -1032,10 +1033,12 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu,
struct kvm_mmu_page *sp)
pte_access, PT_PAGE_TABLE_LEVEL,
gfn, spte_to_pfn(sp->spt[i]),
true, false, host_writable);
+ if (set_spte_ret && kvm_available_flush_tlb_with_range())
+ kvm_mmu_queue_flush_request(sp, _list);
}
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_list(vcpu->kvm, _list);
return nr_present;
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 2/13] KVM/MMU: Add tlb flush with range helper function
This patch is to add wrapper functions for tlb_remote_flush_with_range
callback.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 48
1 file changed, 48 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c67f09086378..ac3b748f58f8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -253,6 +253,54 @@ 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) {
+ /*
+* Read tlbs_dirty before setting KVM_REQ_TLB_FLUSH in
+* kvm_make_all_cpus_request.
+*/
+ long dirty_count = smp_load_acquire(>tlbs_dirty);
+
+ ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+ cmpxchg(>tlbs_dirty, dirty_count, 0);
+ }
+
+ 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, );
+}
+
+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, );
+}
+
void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
{
BUG_ON((mmio_mask & mmio_value) != mmio_value);
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()
This patch is to flush tlb directly in the kvm_handle_hva_range()
when range flush is available.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 822e170881a4..dfd2a0710417 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1888,6 +1888,13 @@ static int kvm_handle_hva_range(struct kvm *kvm,
)
ret |= handler(kvm, iterator.rmap, memslot,
iterator.gfn, iterator.level,
data);
+
+ if (ret && kvm_available_flush_tlb_with_range()) {
+ kvm_flush_remote_tlbs_with_address(kvm,
+ gfn_start,
+ gfn_end - gfn_start);
+ ret = 0;
+ }
}
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.
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
---
arch/x86/kvm/mmu.c | 33 ++---
arch/x86/kvm/paging_tmpl.h | 3 ++-
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ac3b748f58f8..822e170881a4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1482,8 +1482,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));
+ }
}
/*
@@ -1770,7 +1774,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct
kvm_rmap_head *rmap_head,
}
if (need_flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, gfn, 1);
return 0;
}
@@ -1951,7 +1955,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)
@@ -2467,7 +2472,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, _list);
@@ -2587,7 +2592,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);
}
}
@@ -3011,8 +3016,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;
@@ -5621,7 +5628,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,
@@ -5685,7 +5693,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);
@@ -5703,7 +5712,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct
kvm *kvm,
lockdep_assert_held(>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);
@@ -5720,7 +5730,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 14ffd973df54..708a5e44861a 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -893,7 +893,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))
[PATCH V2 00/13] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM
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 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 (13): 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/MMU: Flush tlb directly in the kvm_handle_hva_range() 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/x86/hyperv/nested.c| 104 ++ arch/x86/include/asm/hyperv-tlfs.h | 17 + arch/x86/include/asm/kvm_host.h | 10 +++ arch/x86/include/asm/mshyperv.h | 16 arch/x86/include/asm/trace/hyperv.h | 14 arch/x86/kvm/mmu.c | 143 +++- arch/x86/kvm/paging_tmpl.h | 16 +++- arch/x86/kvm/vmx.c | 65 +--- 8 files changed, 354 insertions(+), 31 deletions(-) -- 2.14.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
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
---
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 8e90488c3d56..a6b77978502e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -402,6 +402,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,
@@ -991,6 +997,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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case
On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> On Fri, Sep 14, 2018 at 5:50 AM, Thomas Gleixner wrote:
>> The code flow for the vclocks is convoluted as it requires the vclocks
>> which can be invalidated separately from the vsyscall_gtod_data sequence to
>> store the fact in a separate variable. That's inefficient.
>>
>
>> notrace static int do_hres(clockid_t clk, struct timespec *ts)
>> {
>> struct vgtod_ts *base = >basetime[clk];
>> unsigned int seq;
>> - int mode;
>> - u64 ns;
>> + u64 cycles, ns;
>>
>> do {
>> seq = gtod_read_begin(gtod);
>> - mode = gtod->vclock_mode;
>> ts->tv_sec = base->sec;
>> ns = base->nsec;
>> - ns += vgetsns();
>> + cycles = vgetcyc(gtod->vclock_mode);
>> + if (unlikely((s64)cycles < 0))
>> + return vdso_fallback_gettime(clk, ts);
>
> i was contemplating this, and I would suggest one of two optimizations:
>
> 1. have all the helpers return a struct containing a u64 and a bool,
> and use that bool. The compiler should do okay.
>
> 2. Be sneaky. Later in the series, you do:
>
> if (unlikely((s64)cycles < 0))
> return vdso_fallback_gettime(clk, ts);
> - ns += (cycles - gtod->cycle_last) * gtod->mult;
> + if (cycles > last)
> + ns += (cycles - last) * gtod->mult;
>
> How about:
>
> if (unlikely((s64)cycles <= last)) {
> if (cycles < 0) [or cycles == -1 or whatever]
> return vdso_fallback_gettime;
> } else {
> ns += (cycles - last) * gtod->mult;
> }
>
> which should actually make this whole mess be essentially free.
>
> Also, I'm not entirely convinced that this "last" thing is needed at
> all. John, what's the scenario under which we need it?
So my memory is probably a bit foggy, but I recall that as we
accelerated gettimeofday, we found that even on systems that claimed
to have synced TSCs, they were actually just slightly out of sync.
Enough that right after cycles_last had been updated, a read on
another cpu could come in just behind cycles_last, resulting in a
negative interval causing lots of havoc.
So the sanity check is needed to avoid that case.
thanks
-john
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch V2 01/11] clocksource: Provide clocksource_arch_init()
On Mon, Sep 17, 2018 at 5:45 AM, Thomas Gleixner wrote: > Architectures have extra archdata in the clocksource, e.g. for VDSO > support. There are no sanity checks or general initializations for this > available. Add support for that. > > Signed-off-by: Thomas Gleixner Sorry, Let me try reply-all this time. :) Acked-by: John Stultz thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-mmc: Remove do {} while (0) loop for single statement macro
On Sat, 2018-09-15 at 18:47 +0530, Nishad Kamdar wrote:
> This patch removes do {} while (0) loop for single statement macros.
> Issue found by checkpatch.
Some or all of this code is not used and should be deleted instead.
> Signed-off-by: Nishad Kamdar
> ---
> drivers/staging/mt7621-mmc/sd.c | 28 +++-
> 1 file changed, 7 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
> index 7474f9ed7b5b..ec12a3a5a926 100644
> --- a/drivers/staging/mt7621-mmc/sd.c
> +++ b/drivers/staging/mt7621-mmc/sd.c
> @@ -104,14 +104,10 @@ static int cd_active_low = 1;
> /* gate means clock power down */
> static int g_clk_gate = 0;
> #define msdc_gate_clock(id) \
> - do { \
> - g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN)); \
> - } while (0)
> + (g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN)))
> /* not like power down register. 1 means clock on. */
> #define msdc_ungate_clock(id) \
> - do {\
> - g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN); \
> - } while (0)
> + (g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN))
>
> // do we need sync object or not
> void msdc_clk_status(int *status)
> @@ -170,9 +166,7 @@ static void msdc_clr_fifo(struct msdc_host *host)
> } while (0)
>
> #define msdc_irq_restore(val) \
> - do {\
> - sdr_set_bits(host->base + MSDC_INTEN, val); \
> - } while (0)
> + (sdr_set_bits(host->base + MSDC_INTEN, val))
>
> /* clock source for host: global */
> #if defined(CONFIG_SOC_MT7620)
> @@ -186,26 +180,18 @@ static u32 hclks[] = {5000}; /* +/- by chhung */
> //always keep the VMC on.
> //
> #define msdc_vcore_on(host) \
> - do {\
> - (void)hwPowerOn(MT65XX_POWER_LDO_VMC, VOL_3300, "SD"); \
> - } while (0)
> + ((void)hwPowerOn(MT65XX_POWER_LDO_VMC, VOL_3300, "SD"))
> #define msdc_vcore_off(host) \
> - do {\
> - (void)hwPowerDown(MT65XX_POWER_LDO_VMC, "SD"); \
> - } while (0)
> + ((void)hwPowerDown(MT65XX_POWER_LDO_VMC, "SD"))
>
> //
> // the vdd output for card: global
> // always keep the VMCH on.
> //
> #define msdc_vdd_on(host) \
> - do {\
> - (void)hwPowerOn(MT65XX_POWER_LDO_VMCH, VOL_3300, "SD"); \
> - } while (0)
> + ((void)hwPowerOn(MT65XX_POWER_LDO_VMCH, VOL_3300, "SD"))
> #define msdc_vdd_off(host) \
> - do {\
> - (void)hwPowerDown(MT65XX_POWER_LDO_VMCH, "SD"); \
> - } while (0)
> + ((void)hwPowerDown(MT65XX_POWER_LDO_VMCH, "SD"))
>
> #define sdc_is_busy() (readl(host->base + SDC_STS) &
> SDC_STS_SDCBUSY)
> #define sdc_is_cmd_busy() (readl(host->base + SDC_STS) &
> SDC_STS_CMDBUSY)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case
On Fri, Sep 14, 2018 at 5:50 AM, Thomas Gleixner wrote:
> The code flow for the vclocks is convoluted as it requires the vclocks
> which can be invalidated separately from the vsyscall_gtod_data sequence to
> store the fact in a separate variable. That's inefficient.
>
> notrace static int do_hres(clockid_t clk, struct timespec *ts)
> {
> struct vgtod_ts *base = >basetime[clk];
> unsigned int seq;
> - int mode;
> - u64 ns;
> + u64 cycles, ns;
>
> do {
> seq = gtod_read_begin(gtod);
> - mode = gtod->vclock_mode;
> ts->tv_sec = base->sec;
> ns = base->nsec;
> - ns += vgetsns();
> + cycles = vgetcyc(gtod->vclock_mode);
> + if (unlikely((s64)cycles < 0))
> + return vdso_fallback_gettime(clk, ts);
i was contemplating this, and I would suggest one of two optimizations:
1. have all the helpers return a struct containing a u64 and a bool,
and use that bool. The compiler should do okay.
2. Be sneaky. Later in the series, you do:
if (unlikely((s64)cycles < 0))
return vdso_fallback_gettime(clk, ts);
- ns += (cycles - gtod->cycle_last) * gtod->mult;
+ if (cycles > last)
+ ns += (cycles - last) * gtod->mult;
How about:
if (unlikely((s64)cycles <= last)) {
if (cycles < 0) [or cycles == -1 or whatever]
return vdso_fallback_gettime;
} else {
ns += (cycles - last) * gtod->mult;
}
which should actually make this whole mess be essentially free.
Also, I'm not entirely convinced that this "last" thing is needed at
all. John, what's the scenario under which we need it?
--Andy
--Andy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling
On 17/09/2018 18:51, Florian Fainelli wrote: On 09/17/2018 04:47 AM, Phil Elwell wrote: Hi Stefan, On 17/09/2018 12:39, Stefan Wahren wrote: Hi Phil, Am 17.09.2018 um 10:22 schrieb Phil Elwell: Both sides of the VCHIQ communications mechanism need to agree on the cache line size. Using an incorrect value can lead to data corruption, but having the two sides using different values is usually worse. In the absence of an obvious convenient run-time method to determine the correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a Device Tree property, written by the firmware, to configure the kernel driver. This method was vetoed during the upstreaming process, so a fixed value of 32 was used instead, and some corruptions ensued. This is take 2 at arriving at the correct value. Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with a 64-byte cache line. Document the new string in the binding, and use it on the appropriate platforms. The final patch is a (seemingly cosmetic) correction of the Device Tree "reg" declaration for the device node, but it doubles as an indication to the Raspberry Pi firmware that the kernel driver is running a recent kernel driver that chooses the correct value. As such it would help if the DT patches are not merged before the driver patch. v3: Builds without errors, tested on multiple Raspberry Pi models. v2: Replaced ARM-specific logic used to determine cache line size with a new compatible string for BCM2836 and BCM2837. Phil Elwell (4): staging/vc04_services: Use correct cache line size dt-bindings: soc: Document "brcm,bcm2836-vchiq" ARM: dts: bcm283x: Correct vchiq compatible string ARM: dts: bcm283x: Correct mailbox register sizes since my pull requests are out, would it be okay to apply patch #1 for 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with these patches)? Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me. Humm, did you mean you would like not to be delayed? In any case Stefan, you can send an additional pull request, and I will merge it and send a second pull request towards ARM SoC maintainers, that's not a problem. No, I meant what I wrote - I would prefer patch 1 to be merged before patch 4 (or at least in the same release) to avoid the need for another firmware change, hence delaying patch 4 is good. It makes sense for the other commits to be merged in that order, but the normal compatible-string fallback mechanism means there is no hard dependency there. Phil ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling
On 09/17/2018 04:47 AM, Phil Elwell wrote: > Hi Stefan, > > On 17/09/2018 12:39, Stefan Wahren wrote: >> Hi Phil, >> >> Am 17.09.2018 um 10:22 schrieb Phil Elwell: >>> Both sides of the VCHIQ communications mechanism need to agree on the cache >>> line size. Using an incorrect value can lead to data corruption, but having >>> the >>> two sides using different values is usually worse. >>> >>> In the absence of an obvious convenient run-time method to determine the >>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used >>> a >>> Device Tree property, written by the firmware, to configure the kernel >>> driver. >>> This method was vetoed during the upstreaming process, so a fixed value of >>> 32 >>> was used instead, and some corruptions ensued. This is take 2 at arriving at >>> the correct value. >>> >>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with >>> a 64-byte cache line. Document the new string in the binding, and use it on >>> the appropriate platforms. >>> >>> The final patch is a (seemingly cosmetic) correction of the Device Tree >>> "reg" >>> declaration for the device node, but it doubles as an indication to the >>> Raspberry Pi firmware that the kernel driver is running a recent kernel >>> driver >>> that chooses the correct value. As such it would help if the DT patches are >>> not merged before the driver patch. >>> >>> v3: Builds without errors, tested on multiple Raspberry Pi models. >>> v2: Replaced ARM-specific logic used to determine cache line size with >>> a new compatible string for BCM2836 and BCM2837. >>> >>> Phil Elwell (4): >>> staging/vc04_services: Use correct cache line size >>> dt-bindings: soc: Document "brcm,bcm2836-vchiq" >>> ARM: dts: bcm283x: Correct vchiq compatible string >>> ARM: dts: bcm283x: Correct mailbox register sizes >> >> since my pull requests are out, would it be okay to apply patch #1 for >> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with >> these patches)? > > Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with > me. Humm, did you mean you would like not to be delayed? In any case Stefan, you can send an additional pull request, and I will merge it and send a second pull request towards ARM SoC maintainers, that's not a problem. -- Florian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Targeted Global B2B Companies Emails List
Hello, Hope all is well! We are a database organization. We provide business executives' contact information. Below, I've included a few examples: Industry-Specific Lists: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer Services, Cultural, Education, Energy, Utilities & Waste Treatment, Finance, Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services, Manufacturing, Media & Internet, Metals & Mining, Organizations, Real Estate, Retail, Software, Telecommunications, Transportation, and more! Technology-Specific Lists: SAP users, PeopleSoft users, SIEBEL customers, Oracle Application customers, Microsoft Dynamic users, Sales force users, Microsoft Exchange users, QuickBooks, Lawson users, Act users, JD Edward users, ASP users, Microsoft GP Applications users, Net Suite users, IBM DBMS Application users, McAfee users, MS Dynamics GP (Great Plains), and many more. Title-Specific Lists: C-level executives: CEO, CFO, CIO, CTO, CMO, CISO, CSO, COO Key decision-makers: All C-level, VP-level, and Director-level executives HR Executives: VP of HR, HR Director & HR Manager, etc. Marketing Executives: CMO, VP of Marketing, Director of Marketing, Marketing Managers IT Executives: CIO, CTO, CISO, IT-VP, IT-Director, IT Manager, MIS Manager, etc. Please keep me informed for any additional details. I look forward to hearing from you. Regards, Alyssa Marketing Executive If you don't want to include yourself in our mailing list, please reply back “Leave Out" in a subject line ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 6/6] staging: erofs: option validation in remount
Add option validation in remount. After this patch, remount
can change recognized options, and for unknown options remount
will fail and report error.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index a6a4874d9c9e..2a952cc7e27d 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -656,10 +656,23 @@ static int erofs_show_options(struct seq_file *seq,
struct dentry *root)
static int erofs_remount(struct super_block *sb, int *flags, char *data)
{
+ struct erofs_sb_info *sbi = EROFS_SB(sb);
+ unsigned int org_mnt_opt = sbi->mount_opt;
+ unsigned int org_inject_rate = erofs_get_fault_rate(sbi);
+ int err;
+
BUG_ON(!sb_rdonly(sb));
+ err = parse_options(sb, data);
+ if (err)
+ goto out;
*flags |= MS_RDONLY;
return 0;
+out:
+ __erofs_build_fault_attr(sbi, org_inject_rate);
+ sbi->mount_opt = org_mnt_opt;
+
+ return err;
}
const struct super_operations erofs_sops = {
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 4/6] staging: erofs: introduce a new helper erofs_get_fault_rate()
Introduce a new helper for getting fault rate, so that we
don't have to check macro in calling place.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 3f5ae64b9c60..24f3423ed804 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -145,6 +145,11 @@ char *erofs_fault_name[FAULT_MAX] = {
[FAULT_KMALLOC] = "kmalloc",
};
+static unsigned int erofs_get_fault_rate(struct erofs_sb_info *sbi)
+{
+ return sbi->fault_info.inject_rate;
+}
+
static void __erofs_build_fault_attr(struct erofs_sb_info *sbi,
unsigned int rate)
{
@@ -173,6 +178,11 @@ static int erofs_build_fault_attr(struct erofs_sb_info
*sbi,
return 0;
}
#else
+static unsigned int erofs_get_fault_rate(struct erofs_sb_info *sbi)
+{
+ return 0;
+}
+
static void __erofs_build_fault_attr(struct erofs_sb_info *sbi,
unsigned int rate)
{
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 5/6] staging: erofs: code cleanup for erofs_show_options()
Call erofs_get_fault_rate() to get fault rate instead of directly getting it from sbi, so we can remove the macro check surrounding it. Signed-off-by: Chengguang Xu --- drivers/staging/erofs/super.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c index 24f3423ed804..a6a4874d9c9e 100644 --- a/drivers/staging/erofs/super.c +++ b/drivers/staging/erofs/super.c @@ -648,11 +648,9 @@ static int erofs_show_options(struct seq_file *seq, struct dentry *root) else seq_puts(seq, ",noacl"); #endif -#ifdef CONFIG_EROFS_FAULT_INJECTION if (test_opt(sbi, FAULT_INJECTION)) seq_printf(seq, ",fault_injection=%u", - sbi->fault_info.inject_rate); -#endif + erofs_get_fault_rate(sbi)); return 0; } -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/6] staging: erofs: introduce a new helper __erofs_build_fault_attr()
Introduce a new helper __erofs_build_fault_attr() to handle set/clear
erofs_fault_info, we need this funciton for internal use case.
for example, reset fault_injection option in remount.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 7ce2fd3d49f3..3f5ae64b9c60 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -145,14 +145,10 @@ char *erofs_fault_name[FAULT_MAX] = {
[FAULT_KMALLOC] = "kmalloc",
};
-static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
- substring_t *args)
+static void __erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ unsigned int rate)
{
struct erofs_fault_info *ffi = >fault_info;
- int rate = 0;
-
- if (args->from && match_int(args, ))
- return -EINVAL;
if (rate) {
atomic_set(>inject_ops, 0);
@@ -164,7 +160,24 @@ static int erofs_build_fault_attr(struct erofs_sb_info
*sbi,
set_opt(sbi, FAILt_INJECTION);
}
+
+static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ substring_t *args)
+{
+ int rate = 0;
+
+ if (args->from && match_int(args, ))
+ return -EINVAL;
+
+ __erofs_build_fault_attr(sbi, rate);
+ return 0;
+}
#else
+static void __erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ unsigned int rate)
+{
+}
+
static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
substring_t *args)
{
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/6] staging: erofs: code cleanup for option parsing of fault_injection
Define a dummpy function of erofs_build_fault_attr() when macro
CONFIG_EROFS_FAULT_INJECTION is disabled, so that we don't have to
check the macro in calling place. Based on above adjustment,
do proper code cleanup for option parsing of fault_injection.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 9e421536cbdf..7ce2fd3d49f3 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -145,10 +145,14 @@ char *erofs_fault_name[FAULT_MAX] = {
[FAULT_KMALLOC] = "kmalloc",
};
-static void erofs_build_fault_attr(struct erofs_sb_info *sbi,
- unsigned int rate)
+static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ substring_t *args)
{
struct erofs_fault_info *ffi = >fault_info;
+ int rate = 0;
+
+ if (args->from && match_int(args, ))
+ return -EINVAL;
if (rate) {
atomic_set(>inject_ops, 0);
@@ -157,6 +161,15 @@ static void erofs_build_fault_attr(struct erofs_sb_info
*sbi,
} else {
memset(ffi, 0, sizeof(struct erofs_fault_info));
}
+
+ set_opt(sbi, FAILt_INJECTION);
+}
+#else
+static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ substring_t *args)
+{
+ infoln("fault_injection options not supported");
+ return 0;
}
#endif
@@ -193,7 +206,7 @@ static int parse_options(struct super_block *sb, char
*options)
{
substring_t args[MAX_OPT_ARGS];
char *p;
- int arg = 0;
+ int err;
if (!options)
return 0;
@@ -238,18 +251,12 @@ static int parse_options(struct super_block *sb, char
*options)
infoln("noacl options not supported");
break;
#endif
-#ifdef CONFIG_EROFS_FAULT_INJECTION
- case Opt_fault_injection:
- if (args->from && match_int(args, ))
- return -EINVAL;
- erofs_build_fault_attr(EROFS_SB(sb), arg);
- set_opt(EROFS_SB(sb), FAULT_INJECTION);
- break;
-#else
case Opt_fault_injection:
- infoln("fault_injection options not supported");
+ err = erofs_build_fault_attr(EROFS_SB(sb), args);
+ if (err)
+ return err;
break;
-#endif
+
default:
errln("Unrecognized mount option \"%s\" "
"or missing value", p);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/6] staging: erofs: code cleanup for erofs_kmalloc()
Define a dummy function of time_to_inject()/erofs_show_injection_info(),
so that we don't have to check macro CONFIG_EROFS_FAULT_INJECTION in
calling place.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/internal.h | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index f20c6e9b7471..0011b9d505fd 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -42,12 +42,12 @@
#define DBG_BUGON(...) ((void)0)
#endif
-#ifdef CONFIG_EROFS_FAULT_INJECTION
enum {
FAULT_KMALLOC,
FAULT_MAX,
};
+#ifdef CONFIG_EROFS_FAULT_INJECTION
extern char *erofs_fault_name[FAULT_MAX];
#define IS_FAULT_SET(fi, type) ((fi)->inject_type & (1 << (type)))
@@ -143,17 +143,24 @@ static inline bool time_to_inject(struct erofs_sb_info
*sbi, int type)
}
return false;
}
+#else
+static inline bool time_to_inject(struct erofs_sb_info *sbi, int type)
+{
+ return false;
+}
+
+static inline void erofs_show_injection_info(int type)
+{
+}
#endif
static inline void *erofs_kmalloc(struct erofs_sb_info *sbi,
size_t size, gfp_t flags)
{
-#ifdef CONFIG_EROFS_FAULT_INJECTION
if (time_to_inject(sbi, FAULT_KMALLOC)) {
erofs_show_injection_info(FAULT_KMALLOC);
return NULL;
}
-#endif
return kmalloc(size, flags);
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/6] staging: erofs: option validation for remount and some code cleanups
This patch set mainly does option validation for remount and at the same time does related code cleanups. Currently when we call fault injection related code we have to surround it with macro CONFIG_EROFS_FAULT_INJECTION in every calling place, after this patch set we don't have to do that, so the code looks clean and more understandable. v1->v2: Address Chao's comments: - Allow to set fault_injection=0. - Keep flag bit when setting fault_injection=0. - Show injection info in original place. - Rebase code on latest erofs branch in Chao's linux tree. - Fix building issue. Chengguang Xu (6): staging: erofs: code cleanup for erofs_kmalloc() staging: erofs: code cleanup for option parsing of fault_injection staging: erofs: introduce a new helper __erofs_build_fault_attr() staging: erofs: introduce a new helper erofs_get_fault_rate() staging: erofs: code cleanup for erofs_show_options() staging: erofs: option validation in remount drivers/staging/erofs/internal.h | 13 -- drivers/staging/erofs/super.c| 73 +--- 2 files changed, 67 insertions(+), 19 deletions(-) -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Targeted Global B2B Companies emails list
Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? We also have the data intelligence of: • Managed Service Providers (MSP’s) – 25,000 unique companies • Managed Security Service Providers (MSSP’s) – 7,520 unique companies • IT Decision Makers – 6million across all industry • Business Decision Makers – 10 million across all industry • Value Added Resellers- VARs • Independent Software Vendors- ISVs • System Integrators- SIs • VoIP Service Providers. • Telecommunications Service Providers (TSPs) • Application Service Providers (ASPs) • IT Managed Services Providers (ITMSP) • Storage Service Providers (SSPs) Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Marie Ward Marketing Specialist If you don't want to include yourself in our mailing list, please reply back “Leave Out" in a subject line ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown operation was requested
> -Original Message- > From: Greg KH > Sent: Monday, September 17, 2018 7:28 AM > To: KY Srinivasan > Cc: o...@aepfle.de; Stephen Hemminger ; > jasow...@redhat.com; linux-ker...@vger.kernel.org; Michael Kelley > (EOSG) ; a...@canonical.com; > de...@linuxdriverproject.org; vkuznets > Subject: Re: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown > operation was requested > > On Mon, Sep 17, 2018 at 02:16:48PM +, KY Srinivasan wrote: > > > > > > > -Original Message- > > > From: Greg KH > > > Sent: Sunday, September 16, 2018 9:56 PM > > > To: KY Srinivasan > > > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > > > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen > > > Hemminger ; Michael Kelley (EOSG) > > > ; vkuznets > > > Subject: Re: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown > > > operation was requested > > > > > > On Mon, Sep 17, 2018 at 04:14:55AM +, k...@linuxonhyperv.com > wrote: > > > > From: Vitaly Kuznetsov > > > > > > > > 'error' variable is left uninitialized in case we see an unknown > > > > operation. > > > > As we don't immediately return and proceed to pwrite() we need to set > it > > > > to something, HV_E_FAIL sounds good enough. > > > > > > > > Signed-off-by: Vitaly Kuznetsov > > > > Signed-off-by: K. Y. Srinivasan > > > > --- > > > > tools/hv/hv_fcopy_daemon.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > No need to backport for stable? > > Thanks for pointing this out. Should I resubmit with the stable tag? > > I can do it... :) Thank you! K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/2] hv_netvsc: associate VF and PV device by serial number
From: Stephen Hemminger Date: Fri, 14 Sep 2018 12:54:55 -0700 > The Hyper-V implementation of PCI controller has concept of 32 bit serial > number > (not to be confused with PCI-E serial number). This value is sent in the > protocol > from the host to indicate SR-IOV VF device is attached to a synthetic NIC. > > Using the serial number (instead of MAC address) to associate the two devices > avoids lots of potential problems when there are duplicate MAC addresses from > tunnels or layered devices. > > The patch set is broken into two parts, one is for the PCI controller > and the other is for the netvsc device. Normally, these go through different > trees but sending them together here for better review. The PCI changes > were submitted previously, but the main review comment was "why do you > need this?". This is why. > > v2 - slot name can be shorter. > remove locking when creating pci_slots; see comment for explaination Series applied, thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown operation was requested
On Mon, Sep 17, 2018 at 02:16:48PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Greg KH > > Sent: Sunday, September 16, 2018 9:56 PM > > To: KY Srinivasan > > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen > > Hemminger ; Michael Kelley (EOSG) > > ; vkuznets > > Subject: Re: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown > > operation was requested > > > > On Mon, Sep 17, 2018 at 04:14:55AM +, k...@linuxonhyperv.com wrote: > > > From: Vitaly Kuznetsov > > > > > > 'error' variable is left uninitialized in case we see an unknown > > > operation. > > > As we don't immediately return and proceed to pwrite() we need to set it > > > to something, HV_E_FAIL sounds good enough. > > > > > > Signed-off-by: Vitaly Kuznetsov > > > Signed-off-by: K. Y. Srinivasan > > > --- > > > tools/hv/hv_fcopy_daemon.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > No need to backport for stable? > Thanks for pointing this out. Should I resubmit with the stable tag? I can do it... :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] staging: erofs: code cleanup for option parsing of fault_injection
On 2018/9/17 21:52, cgxu519 wrote:
> On 09/14/2018 11:22 PM, Chao Yu wrote:
>> On 2018/9/13 13:46, cgxu519 wrote:
>>> On 09/13/2018 10:15 AM, Chao Yu wrote:
On 2018/9/12 13:10, Chengguang Xu wrote:
> Define a dummpy function of erofs_build_fault_attr() when macro
> CONFIG_EROFS_FAULT_INJECTION is disabled, so that we don't have to
> check the macro in calling place. Based on above adjustment,
> do proper code cleanup for option parsing of fault_injection.
>
> Signed-off-by: Chengguang Xu
> ---
> drivers/staging/erofs/super.c | 33 ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
> index 1aec509c805f..14dbb6517b8d 100644
> --- a/drivers/staging/erofs/super.c
> +++ b/drivers/staging/erofs/super.c
> @@ -144,18 +144,33 @@ char *erofs_fault_name[FAULT_MAX] = {
> [FAULT_KMALLOC] = "kmalloc",
> };
> -static void erofs_build_fault_attr(struct erofs_sb_info *sbi,
> - unsigned int rate)
> +static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
> + substring_t *args)
> {
> struct erofs_fault_info *ffi = >fault_info;
> + int rate = 0;
> +
> + if (args->from && match_int(args, ))
> + return -EINVAL;
> if (rate) {
> atomic_set(>inject_ops, 0);
> ffi->inject_rate = rate;
> ffi->inject_type = (1 << FAULT_MAX) - 1;
> + set_opt(sbi, FAULT_INJECTION);
> } else {
> memset(ffi, 0, sizeof(struct erofs_fault_info));
> + clear_opt(sbi, FAULT_INJECTION);
Hmmm, if user mounts/remounts image with -o fault_injection=0, user can not
check such info in anywhere, as we skip showing this option due to lack of
EROFS_MOUNT_FAULT_INJECTION bit. How about keeping this bit?
>>> IIUC, the purpose of fault_injection=0 is for disabling fault injection
>>> function,
>>> so isn't it the same as default? Should we distinguish explicit setting
>>> value 0
>> IMO, if user set fault_injection=0 during mount, it means user want to enable
>> this feature but currently user want to set the rate to zero, later user may
>> change it to non-zero. And with EROFS_MOUNT_FAULT_INJECTION being set, user
>> can
>> check current rate value via ->show_options.
>
> Hi Chao,
>
> Do you mean user can modify the value without remount? or maybe in the future?
Yeah, like we did in f2fs, we can export sysfs node for configuring fault
injection rate/type.
Thanks,
>
> Thanks,
> Chengguang
>
>
>
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown operation was requested
> -Original Message- > From: Greg KH > Sent: Sunday, September 16, 2018 9:56 PM > To: KY Srinivasan > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen > Hemminger ; Michael Kelley (EOSG) > ; vkuznets > Subject: Re: [PATCH 2/2] tools: hv: fcopy: set 'error' in case an unknown > operation was requested > > On Mon, Sep 17, 2018 at 04:14:55AM +, k...@linuxonhyperv.com wrote: > > From: Vitaly Kuznetsov > > > > 'error' variable is left uninitialized in case we see an unknown operation. > > As we don't immediately return and proceed to pwrite() we need to set it > > to something, HV_E_FAIL sounds good enough. > > > > Signed-off-by: Vitaly Kuznetsov > > Signed-off-by: K. Y. Srinivasan > > --- > > tools/hv/hv_fcopy_daemon.c | 1 + > > 1 file changed, 1 insertion(+) > > No need to backport for stable? Thanks for pointing this out. Should I resubmit with the stable tag? Thanks, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] staging: erofs: code cleanup for option parsing of fault_injection
On 09/14/2018 11:22 PM, Chao Yu wrote:
On 2018/9/13 13:46, cgxu519 wrote:
On 09/13/2018 10:15 AM, Chao Yu wrote:
On 2018/9/12 13:10, Chengguang Xu wrote:
Define a dummpy function of erofs_build_fault_attr() when macro
CONFIG_EROFS_FAULT_INJECTION is disabled, so that we don't have to
check the macro in calling place. Based on above adjustment,
do proper code cleanup for option parsing of fault_injection.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 1aec509c805f..14dbb6517b8d 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -144,18 +144,33 @@ char *erofs_fault_name[FAULT_MAX] = {
[FAULT_KMALLOC] = "kmalloc",
};
-static void erofs_build_fault_attr(struct erofs_sb_info *sbi,
- unsigned int rate)
+static int erofs_build_fault_attr(struct erofs_sb_info *sbi,
+ substring_t *args)
{
struct erofs_fault_info *ffi = >fault_info;
+ int rate = 0;
+
+ if (args->from && match_int(args, ))
+ return -EINVAL;
if (rate) {
atomic_set(>inject_ops, 0);
ffi->inject_rate = rate;
ffi->inject_type = (1 << FAULT_MAX) - 1;
+ set_opt(sbi, FAULT_INJECTION);
} else {
memset(ffi, 0, sizeof(struct erofs_fault_info));
+ clear_opt(sbi, FAULT_INJECTION);
Hmmm, if user mounts/remounts image with -o fault_injection=0, user can not
check such info in anywhere, as we skip showing this option due to lack of
EROFS_MOUNT_FAULT_INJECTION bit. How about keeping this bit?
IIUC, the purpose of fault_injection=0 is for disabling fault injection
function,
so isn't it the same as default? Should we distinguish explicit setting value 0
IMO, if user set fault_injection=0 during mount, it means user want to enable
this feature but currently user want to set the rate to zero, later user may
change it to non-zero. And with EROFS_MOUNT_FAULT_INJECTION being set, user can
check current rate value via ->show_options.
Hi Chao,
Do you mean user can modify the value without remount? or maybe in the
future?
Thanks,
Chengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 11/11] x66/vdso: Add CLOCK_TAI support
With the storage array in place it's now trivial to support CLOCK_TAI in
the vdso. Extend the base time storage array and add the update code.
Signed-off-by: Thomas Gleixner
---
V2: Remove the masking trick
arch/x86/entry/vsyscall/vsyscall_gtod.c |4
arch/x86/include/asm/vgtod.h|4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -51,6 +51,10 @@ void update_vsyscall(struct timekeeper *
base->sec = tk->xtime_sec;
base->nsec = tk->tkr_mono.xtime_nsec;
+ base = >basetime[CLOCK_TAI];
+ base->sec = tk->xtime_sec + (s64)tk->tai_offset;
+ base->nsec = tk->tkr_mono.xtime_nsec;
+
base = >basetime[CLOCK_MONOTONIC];
base->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec;
nsec = tk->tkr_mono.xtime_nsec;
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -18,8 +18,8 @@ struct vgtod_ts {
u64 nsec;
};
-#define VGTOD_BASES(CLOCK_MONOTONIC_COARSE + 1)
-#define VGTOD_HRES (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC))
+#define VGTOD_BASES(CLOCK_TAI + 1)
+#define VGTOD_HRES (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC) |
BIT(CLOCK_TAI))
#define VGTOD_COARSE (BIT(CLOCK_REALTIME_COARSE) |
BIT(CLOCK_MONOTONIC_COARSE))
/*
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 03/11] x86/vdso: Enforce 64bit clocksource
All VDSO clock sources are TSC based and use CLOCKSOURCE_MASK(64). There is
no point in masking with all FF. Get rid of it and enforce the mask in the
sanity checker.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |2 +-
arch/x86/kernel/time.c |6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -199,7 +199,7 @@ notrace static inline u64 vgetsns(int *m
#endif
else
return 0;
- v = (cycles - gtod->cycle_last) & gtod->mask;
+ v = cycles - gtod->cycle_last;
return v * gtod->mult;
}
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -120,4 +120,10 @@ void clocksource_arch_init(struct clocks
cs->name, cs->archdata.vclock_mode);
cs->archdata.vclock_mode = VCLOCK_NONE;
}
+
+ if (cs->mask != CLOCKSOURCE_MASK(64)) {
+ pr_warn("clocksource %s registered with invalid mask %016llx.
Disabling vclock.\n",
+ cs->name, cs->mask);
+ cs->archdata.vclock_mode = VCLOCK_NONE;
+ }
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 06/11] x86/vdso: Collapse high resolution functions
do_realtime() and do_monotonic() are now the same except for the storage
array index. Hand the index in as an argument and collapse the functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -203,35 +203,12 @@ notrace static inline u64 vgetsns(int *m
return v * gtod->mult;
}
-/* Code size doesn't matter (vdso is 4k anyway) and this is faster. */
-notrace static int __always_inline do_realtime(struct timespec *ts)
+notrace static int do_hres(clockid_t clk, struct timespec *ts)
{
- struct vgtod_ts *base = >basetime[CLOCK_REALTIME];
+ struct vgtod_ts *base = >basetime[clk];
unsigned int seq;
- u64 ns;
int mode;
-
- do {
- seq = gtod_read_begin(gtod);
- mode = gtod->vclock_mode;
- ts->tv_sec = base->sec;
- ns = base->nsec;
- ns += vgetsns();
- ns >>= gtod->shift;
- } while (unlikely(gtod_read_retry(gtod, seq)));
-
- ts->tv_sec += __iter_div_u64_rem(ns, NSEC_PER_SEC, );
- ts->tv_nsec = ns;
-
- return mode;
-}
-
-notrace static int __always_inline do_monotonic(struct timespec *ts)
-{
- struct vgtod_ts *base = >basetime[CLOCK_MONOTONIC];
- unsigned int seq;
u64 ns;
- int mode;
do {
seq = gtod_read_begin(gtod);
@@ -276,11 +253,11 @@ notrace int __vdso_clock_gettime(clockid
{
switch (clock) {
case CLOCK_REALTIME:
- if (do_realtime(ts) == VCLOCK_NONE)
+ if (do_hres(CLOCK_REALTIME, ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_MONOTONIC:
- if (do_monotonic(ts) == VCLOCK_NONE)
+ if (do_hres(CLOCK_MONOTONIC, ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_REALTIME_COARSE:
@@ -303,7 +280,9 @@ int clock_gettime(clockid_t, struct time
notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
{
if (likely(tv != NULL)) {
- if (unlikely(do_realtime((struct timespec *)tv) == VCLOCK_NONE))
+ struct timespec *ts = (struct timespec *) tv;
+
+ if (unlikely(do_hres(CLOCK_REALTIME, ts) == VCLOCK_NONE))
return vdso_fallback_gtod(tv, tz);
tv->tv_usec /= 1000;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 09/11] x86/vdso: Simplify the invalid vclock case
The code flow for the vclocks is convoluted as it requires the vclocks
which can be invalidated separately from the vsyscall_gtod_data sequence to
store the fact in a separate variable. That's inefficient.
Restructure the code so the vclock readout returns cycles and the
conversion to nanoseconds is handled at the call site.
If the clock gets invalidated or vclock is already VCLOCK_NONE, return
U64_MAX as the cycle value, which is invalid for all clocks and leave the
sequence loop immediately in that case by calling the fallback function
directly.
This allows to remove the gettimeofday fallback as it now uses the
clock_gettime() fallback and does the nanoseconds to microseconds
conversion in the same way as it does when the vclock is functional. It
does not make a difference whether the division by 1000 happens in the
kernel fallback or in userspace.
Generates way better code and gains a few cycles back.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 81 +--
1 file changed, 21 insertions(+), 60 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -48,16 +48,6 @@ notrace static long vdso_fallback_gettim
return ret;
}
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
- long ret;
-
- asm("syscall" : "=a" (ret) :
- "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
- return ret;
-}
-
-
#else
notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
@@ -75,21 +65,6 @@ notrace static long vdso_fallback_gettim
return ret;
}
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
- long ret;
-
- asm(
- "mov %%ebx, %%edx \n"
- "mov %2, %%ebx \n"
- "call __kernel_vsyscall \n"
- "mov %%edx, %%ebx \n"
- : "=a" (ret)
- : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
- : "memory", "edx");
- return ret;
-}
-
#endif
#ifdef CONFIG_PARAVIRT_CLOCK
@@ -98,7 +73,7 @@ static notrace const struct pvclock_vsys
return (const struct pvclock_vsyscall_time_info *)_page;
}
-static notrace u64 vread_pvclock(int *mode)
+static notrace u64 vread_pvclock(void)
{
const struct pvclock_vcpu_time_info *pvti = _pvti0()->pvti;
u64 ret;
@@ -130,10 +105,8 @@ static notrace u64 vread_pvclock(int *mo
do {
version = pvclock_read_begin(pvti);
- if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
- *mode = VCLOCK_NONE;
- return 0;
- }
+ if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT)))
+ return U64_MAX;
ret = __pvclock_read_cycles(pvti, rdtsc_ordered());
} while (pvclock_read_retry(pvti, version));
@@ -148,17 +121,12 @@ static notrace u64 vread_pvclock(int *mo
}
#endif
#ifdef CONFIG_HYPERV_TSCPAGE
-static notrace u64 vread_hvclock(int *mode)
+static notrace u64 vread_hvclock(void)
{
const struct ms_hyperv_tsc_page *tsc_pg =
(const struct ms_hyperv_tsc_page *)_page;
- u64 current_tick = hv_read_tsc_page(tsc_pg);
-
- if (current_tick != U64_MAX)
- return current_tick;
- *mode = VCLOCK_NONE;
- return 0;
+ return hv_read_tsc_page(tsc_pg);
}
#endif
@@ -182,47 +150,42 @@ notrace static u64 vread_tsc(void)
return last;
}
-notrace static inline u64 vgetsns(int *mode)
+notrace static inline u64 vgetcyc(int mode)
{
- u64 v;
- cycles_t cycles;
-
- if (gtod->vclock_mode == VCLOCK_TSC)
- cycles = vread_tsc();
+ if (mode == VCLOCK_TSC)
+ return vread_tsc();
#ifdef CONFIG_PARAVIRT_CLOCK
- else if (gtod->vclock_mode == VCLOCK_PVCLOCK)
- cycles = vread_pvclock(mode);
+ else if (mode == VCLOCK_PVCLOCK)
+ return vread_pvclock();
#endif
#ifdef CONFIG_HYPERV_TSCPAGE
- else if (gtod->vclock_mode == VCLOCK_HVCLOCK)
- cycles = vread_hvclock(mode);
+ else if (mode == VCLOCK_HVCLOCK)
+ return vread_hvclock();
#endif
- else
- return 0;
- v = cycles - gtod->cycle_last;
- return v * gtod->mult;
+ return U64_MAX;
}
notrace static int do_hres(clockid_t clk, struct timespec *ts)
{
struct vgtod_ts *base = >basetime[clk];
unsigned int seq;
- int mode;
- u64 ns;
+ u64 cycles, ns;
do {
seq = gtod_read_begin(gtod);
- mode = gtod->vclock_mode;
ts->tv_sec = base->sec;
ns = base->nsec;
- ns += vgetsns();
+ cycles = vgetcyc(gtod->vclock_mode);
+ if (unlikely((s64)cycles < 0))
+ return
[patch V2 10/11] x86/vdso: Move cycle_last handling into the caller
Dereferencing gtod->cycle_last all over the place and foing the cycles <
last comparison in the vclock read functions generates horrible code. Doing
it at the call site is much better and gains a few cycles both for TSC and
pvclock.
Caveat: This adds the comparison to the hyperv vclock as well, but I have
no way to test that.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 39 ++-
1 file changed, 7 insertions(+), 32 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -76,9 +76,8 @@ static notrace const struct pvclock_vsys
static notrace u64 vread_pvclock(void)
{
const struct pvclock_vcpu_time_info *pvti = _pvti0()->pvti;
- u64 ret;
- u64 last;
u32 version;
+ u64 ret;
/*
* Note: The kernel and hypervisor must guarantee that cpu ID
@@ -111,13 +110,7 @@ static notrace u64 vread_pvclock(void)
ret = __pvclock_read_cycles(pvti, rdtsc_ordered());
} while (pvclock_read_retry(pvti, version));
- /* refer to vread_tsc() comment for rationale */
- last = gtod->cycle_last;
-
- if (likely(ret >= last))
- return ret;
-
- return last;
+ return ret;
}
#endif
#ifdef CONFIG_HYPERV_TSCPAGE
@@ -130,30 +123,10 @@ static notrace u64 vread_hvclock(void)
}
#endif
-notrace static u64 vread_tsc(void)
-{
- u64 ret = (u64)rdtsc_ordered();
- u64 last = gtod->cycle_last;
-
- if (likely(ret >= last))
- return ret;
-
- /*
-* GCC likes to generate cmov here, but this branch is extremely
-* predictable (it's just a function of time and the likely is
-* very likely) and there's a data dependence, so force GCC
-* to generate a branch instead. I don't barrier() because
-* we don't actually need a barrier, and if this function
-* ever gets inlined it will generate worse code.
-*/
- asm volatile ("");
- return last;
-}
-
notrace static inline u64 vgetcyc(int mode)
{
if (mode == VCLOCK_TSC)
- return vread_tsc();
+ return (u64)rdtsc_ordered();
#ifdef CONFIG_PARAVIRT_CLOCK
else if (mode == VCLOCK_PVCLOCK)
return vread_pvclock();
@@ -168,17 +141,19 @@ notrace static inline u64 vgetcyc(int mo
notrace static int do_hres(clockid_t clk, struct timespec *ts)
{
struct vgtod_ts *base = >basetime[clk];
+ u64 cycles, last, ns;
unsigned int seq;
- u64 cycles, ns;
do {
seq = gtod_read_begin(gtod);
ts->tv_sec = base->sec;
ns = base->nsec;
+ last = gtod->cycle_last;
cycles = vgetcyc(gtod->vclock_mode);
if (unlikely((s64)cycles < 0))
return vdso_fallback_gettime(clk, ts);
- ns += (cycles - gtod->cycle_last) * gtod->mult;
+ if (cycles > last)
+ ns += (cycles - last) * gtod->mult;
ns >>= gtod->shift;
} while (unlikely(gtod_read_retry(gtod, seq)));
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 05/11] x86/vdso: Introduce and use vgtod_ts
It's desired to support more clocks in the VDSO, e.g. CLOCK_TAI. This
results either in indirect calls due to the larger switch case, which then
requires retpolines or when the compiler is forced to avoid jump tables it
results in even more conditionals.
To avoid both variants which are bad for performance the high resolution
functions and the coarse grained functions will be collapsed into one for
each. That requires to store the clock specific base time in an array.
Introcude struct vgtod_ts for storage and convert the data store, the
update function and the individual clock functions over to use it.
The new storage does not longer use gtod_long_t for seconds depending on 32
or 64 bit compile because this needs to be the full 64bit value even for
32bit when a Y2038 function is added. No point in keeping the distinction
alive in the internal representation.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c| 24 +--
arch/x86/entry/vsyscall/vsyscall_gtod.c | 51
arch/x86/include/asm/vgtod.h| 36 --
3 files changed, 61 insertions(+), 50 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -206,6 +206,7 @@ notrace static inline u64 vgetsns(int *m
/* Code size doesn't matter (vdso is 4k anyway) and this is faster. */
notrace static int __always_inline do_realtime(struct timespec *ts)
{
+ struct vgtod_ts *base = >basetime[CLOCK_REALTIME];
unsigned int seq;
u64 ns;
int mode;
@@ -213,8 +214,8 @@ notrace static int __always_inline do_re
do {
seq = gtod_read_begin(gtod);
mode = gtod->vclock_mode;
- ts->tv_sec = gtod->wall_time_sec;
- ns = gtod->wall_time_snsec;
+ ts->tv_sec = base->sec;
+ ns = base->nsec;
ns += vgetsns();
ns >>= gtod->shift;
} while (unlikely(gtod_read_retry(gtod, seq)));
@@ -227,6 +228,7 @@ notrace static int __always_inline do_re
notrace static int __always_inline do_monotonic(struct timespec *ts)
{
+ struct vgtod_ts *base = >basetime[CLOCK_MONOTONIC];
unsigned int seq;
u64 ns;
int mode;
@@ -234,8 +236,8 @@ notrace static int __always_inline do_mo
do {
seq = gtod_read_begin(gtod);
mode = gtod->vclock_mode;
- ts->tv_sec = gtod->monotonic_time_sec;
- ns = gtod->monotonic_time_snsec;
+ ts->tv_sec = base->sec;
+ ns = base->nsec;
ns += vgetsns();
ns >>= gtod->shift;
} while (unlikely(gtod_read_retry(gtod, seq)));
@@ -248,21 +250,25 @@ notrace static int __always_inline do_mo
notrace static void do_realtime_coarse(struct timespec *ts)
{
+ struct vgtod_ts *base = >basetime[CLOCK_REALTIME_COARSE];
unsigned int seq;
+
do {
seq = gtod_read_begin(gtod);
- ts->tv_sec = gtod->wall_time_coarse_sec;
- ts->tv_nsec = gtod->wall_time_coarse_nsec;
+ ts->tv_sec = base->sec;
+ ts->tv_nsec = base->nsec;
} while (unlikely(gtod_read_retry(gtod, seq)));
}
notrace static void do_monotonic_coarse(struct timespec *ts)
{
+ struct vgtod_ts *base = >basetime[CLOCK_MONOTONIC_COARSE];
unsigned int seq;
+
do {
seq = gtod_read_begin(gtod);
- ts->tv_sec = gtod->monotonic_time_coarse_sec;
- ts->tv_nsec = gtod->monotonic_time_coarse_nsec;
+ ts->tv_sec = base->sec;
+ ts->tv_nsec = base->nsec;
} while (unlikely(gtod_read_retry(gtod, seq)));
}
@@ -318,7 +324,7 @@ int gettimeofday(struct timeval *, struc
notrace time_t __vdso_time(time_t *t)
{
/* This is atomic on x86 so we don't need any locks. */
- time_t result = READ_ONCE(gtod->wall_time_sec);
+ time_t result = READ_ONCE(gtod->basetime[CLOCK_REALTIME].sec);
if (t)
*t = result;
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -31,6 +31,8 @@ void update_vsyscall(struct timekeeper *
{
int vclock_mode = tk->tkr_mono.clock->archdata.vclock_mode;
struct vsyscall_gtod_data *vdata = _gtod_data;
+ struct vgtod_ts *base;
+ u64 nsec;
/* Mark the new vclock used. */
BUILD_BUG_ON(VCLOCK_MAX >= 32);
@@ -45,34 +47,33 @@ void update_vsyscall(struct timekeeper *
vdata->mult = tk->tkr_mono.mult;
vdata->shift= tk->tkr_mono.shift;
- vdata->wall_time_sec= tk->xtime_sec;
- vdata->wall_time_snsec = tk->tkr_mono.xtime_nsec;
-
- vdata->monotonic_time_sec = tk->xtime_sec
- + tk->wall_to_monotonic.tv_sec;
- vdata->monotonic_time_snsec
[patch V2 08/11] x86/vdso: Replace the clockid switch case
Now that the time getter functions use the clockid as index into the
storage array for the base time access, the switch case can be replaced.
- Check for clockid >= MAX_CLOCKS and for negative clockid (CPU/FD) first
and call the fallback function right away.
- After establishing that clockid is < MAX_CLOCKS, convert the clockid to a
bitmask
- Check for the supported high resolution and coarse functions by anding
the bitmask of supported clocks and check whether a bit is set.
This completely avoids jump tables, reduces the number of conditionals and
makes the VDSO extensible for other clock ids.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 38 ---
1 file changed, 18 insertions(+), 20 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -239,29 +239,27 @@ notrace static void do_coarse(clockid_t
notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
{
- switch (clock) {
- case CLOCK_REALTIME:
- if (do_hres(CLOCK_REALTIME, ts) == VCLOCK_NONE)
- goto fallback;
- break;
- case CLOCK_MONOTONIC:
- if (do_hres(CLOCK_MONOTONIC, ts) == VCLOCK_NONE)
- goto fallback;
- break;
- case CLOCK_REALTIME_COARSE:
- do_coarse(CLOCK_REALTIME_COARSE, ts);
- break;
- case CLOCK_MONOTONIC_COARSE:
- do_coarse(CLOCK_MONOTONIC_COARSE, ts);
- break;
- default:
- goto fallback;
- }
+ unsigned int msk;
+
+ /* Sort out negative (CPU/FD) and invalid clocks */
+ if (unlikely((unsigned int) clock >= MAX_CLOCKS))
+ return vdso_fallback_gettime(clock, ts);
- return 0;
-fallback:
+ /*
+* Convert the clockid to a bitmask and use it to check which
+* clocks are handled in the VDSO directly.
+*/
+ msk = 1U << clock;
+ if (likely(msk & VGTOD_HRES)) {
+ if (do_hres(clock, ts) != VCLOCK_NONE)
+ return 0;
+ } else if (msk & VGTOD_COARSE) {
+ do_coarse(clock, ts);
+ return 0;
+ }
return vdso_fallback_gettime(clock, ts);
}
+
int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 01/11] clocksource: Provide clocksource_arch_init()
Architectures have extra archdata in the clocksource, e.g. for VDSO
support. There are no sanity checks or general initializations for this
available. Add support for that.
Signed-off-by: Thomas Gleixner
---
include/linux/clocksource.h |5 +
kernel/time/Kconfig |4
kernel/time/clocksource.c |2 ++
3 files changed, 11 insertions(+)
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -241,6 +241,11 @@ static inline void __clocksource_update_
__clocksource_update_freq_scale(cs, 1000, khz);
}
+#ifdef CONFIG_ARCH_CLOCKSOURCE_INIT
+extern void clocksource_arch_init(struct clocksource *cs);
+#else
+static inline void clocksource_arch_init(struct clocksource *cs) { }
+#endif
extern int timekeeping_notify(struct clocksource *clock);
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -12,6 +12,10 @@ config CLOCKSOURCE_WATCHDOG
config ARCH_CLOCKSOURCE_DATA
bool
+# Architecture has extra clocksource init called from registration
+config ARCH_CLOCKSOURCE_INIT
+ bool
+
# Clocksources require validation of the clocksource against the last
# cycle update - x86/TSC misfeature
config CLOCKSOURCE_VALIDATE_LAST_CYCLE
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -937,6 +937,8 @@ int __clocksource_register_scale(struct
{
unsigned long flags;
+ clocksource_arch_init(cs);
+
/* Initialize mult/shift and max_idle_ns */
__clocksource_update_freq_scale(cs, scale, freq);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 07/11] x86/vdso: Collapse coarse functions
do_realtime_coarse() and do_monotonic_coarse() are now the same except for
the storage array index. Hand the index in as an argument and collapse the
functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -225,21 +225,9 @@ notrace static int do_hres(clockid_t clk
return mode;
}
-notrace static void do_realtime_coarse(struct timespec *ts)
+notrace static void do_coarse(clockid_t clk, struct timespec *ts)
{
- struct vgtod_ts *base = >basetime[CLOCK_REALTIME_COARSE];
- unsigned int seq;
-
- do {
- seq = gtod_read_begin(gtod);
- ts->tv_sec = base->sec;
- ts->tv_nsec = base->nsec;
- } while (unlikely(gtod_read_retry(gtod, seq)));
-}
-
-notrace static void do_monotonic_coarse(struct timespec *ts)
-{
- struct vgtod_ts *base = >basetime[CLOCK_MONOTONIC_COARSE];
+ struct vgtod_ts *base = >basetime[clk];
unsigned int seq;
do {
@@ -261,10 +249,10 @@ notrace int __vdso_clock_gettime(clockid
goto fallback;
break;
case CLOCK_REALTIME_COARSE:
- do_realtime_coarse(ts);
+ do_coarse(CLOCK_REALTIME_COARSE, ts);
break;
case CLOCK_MONOTONIC_COARSE:
- do_monotonic_coarse(ts);
+ do_coarse(CLOCK_MONOTONIC_COARSE, ts);
break;
default:
goto fallback;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 02/11] x86/time: Implement clocksource_arch_init()
Runtime validate the VCLOCK_MODE in clocksource::archdata and disable
VCLOCK if invalid, which disables the VDSO but keeps the system running.
Signed-off-by: Thomas Gleixner
---
V2: Fix the VCLOCK_MAX check
arch/x86/Kconfig |1 +
arch/x86/kernel/time.c | 16
2 files changed, 17 insertions(+)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -48,6 +48,7 @@ config X86
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ANON_INODES
select ARCH_CLOCKSOURCE_DATA
+ select ARCH_CLOCKSOURCE_INIT
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_DEBUG_VIRTUAL
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -10,6 +10,7 @@
*
*/
+#include
#include
#include
#include
@@ -105,3 +106,18 @@ void __init time_init(void)
{
late_time_init = x86_late_time_init;
}
+
+/*
+ * Sanity check the vdso related archdata content.
+ */
+void clocksource_arch_init(struct clocksource *cs)
+{
+ if (cs->archdata.vclock_mode == VCLOCK_NONE)
+ return;
+
+ if (cs->archdata.vclock_mode > VCLOCK_MAX) {
+ pr_warn("clocksource %s registered with invalid vclock_mode %d.
Disabling vclock.\n",
+ cs->name, cs->archdata.vclock_mode);
+ cs->archdata.vclock_mode = VCLOCK_NONE;
+ }
+}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 04/11] x86/vdso: Use unsigned int consistently for vsyscall_gtod_data::seq
The sequence count in vgtod_data is unsigned int, but the call sites use
unsigned long, which is a pointless exercise. Fix the call sites and
replace 'unsigned' with unsinged 'int' while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |8
arch/x86/include/asm/vgtod.h | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -206,7 +206,7 @@ notrace static inline u64 vgetsns(int *m
/* Code size doesn't matter (vdso is 4k anyway) and this is faster. */
notrace static int __always_inline do_realtime(struct timespec *ts)
{
- unsigned long seq;
+ unsigned int seq;
u64 ns;
int mode;
@@ -227,7 +227,7 @@ notrace static int __always_inline do_re
notrace static int __always_inline do_monotonic(struct timespec *ts)
{
- unsigned long seq;
+ unsigned int seq;
u64 ns;
int mode;
@@ -248,7 +248,7 @@ notrace static int __always_inline do_mo
notrace static void do_realtime_coarse(struct timespec *ts)
{
- unsigned long seq;
+ unsigned int seq;
do {
seq = gtod_read_begin(gtod);
ts->tv_sec = gtod->wall_time_coarse_sec;
@@ -258,7 +258,7 @@ notrace static void do_realtime_coarse(s
notrace static void do_monotonic_coarse(struct timespec *ts)
{
- unsigned long seq;
+ unsigned int seq;
do {
seq = gtod_read_begin(gtod);
ts->tv_sec = gtod->monotonic_time_coarse_sec;
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -15,9 +15,9 @@ typedef unsigned long gtod_long_t;
* so be carefull by modifying this structure.
*/
struct vsyscall_gtod_data {
- unsigned seq;
+ unsigned int seq;
- int vclock_mode;
+ int vclock_mode;
u64 cycle_last;
u64 mask;
u32 mult;
@@ -44,9 +44,9 @@ static inline bool vclock_was_used(int v
return READ_ONCE(vclocks_used) & (1 << vclock);
}
-static inline unsigned gtod_read_begin(const struct vsyscall_gtod_data *s)
+static inline unsigned int gtod_read_begin(const struct vsyscall_gtod_data *s)
{
- unsigned ret;
+ unsigned int ret;
repeat:
ret = READ_ONCE(s->seq);
@@ -59,7 +59,7 @@ static inline unsigned gtod_read_begin(c
}
static inline int gtod_read_retry(const struct vsyscall_gtod_data *s,
- unsigned start)
+ unsigned int start)
{
smp_rmb();
return unlikely(s->seq != start);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch V2 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing maze. This series takes a different approach by consolidating the almost identical functions into one implementation for high resolution clocks and one for the coarse grained clock ids by storing the base data for each clock id in an array which is indexed by the clock id. This completely eliminates the switch case and allows further simplifications of the code base, which at the end all together gain a few cycles performance or at least stay on par with todays code. The resulting performance depends heavily on the micro architecture and the compiler. Changes vs. V1: - Fix the VCLOCK_MAX sanity check - Remove the magic clock masking and extend the storage array Thanks, tglx 8<--- arch/x86/Kconfig|1 arch/x86/entry/vdso/vclock_gettime.c| 199 arch/x86/entry/vsyscall/vsyscall_gtod.c | 55 arch/x86/include/asm/vgtod.h| 42 +++--- arch/x86/kernel/time.c | 22 +++ include/linux/clocksource.h |5 kernel/time/Kconfig |4 kernel/time/clocksource.c |2 8 files changed, 140 insertions(+), 190 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
On Fri, 14 Sep 2018, Arnd Bergmann wrote: > On Fri, Sep 14, 2018 at 2:52 PM Thomas Gleixner wrote: > A couple of architectures (s390, ia64, riscv, powerpc, arm64) > implement the vdso as assembler code at the moment, so they > won't be as easy to consolidate (other than outright replacing all > the code). > > The other five: > arch/x86/entry/vdso/vclock_gettime.c > arch/sparc/vdso/vclock_gettime.c > arch/nds32/kernel/vdso/gettimeofday.c > arch/mips/vdso/gettimeofday.c > arch/arm/vdso/vgettimeofday.c > > are basically all minor variations of the same code base and could be > consolidated to some degree. > Any suggestions here? Should we plan to do that consolitdation based on > your new version, or just add clock_gettime64 in arm32 and x86-32, and then > be done with it? The other ones will obviously still be fast for 32-bit time_t > and will have a working non-vdso sys_clock_getttime64(). In principle consolidating all those implementations should be possible to some extent and probably worthwhile. What's arch specific are the actual accessors to the hardware clocks. > I also wonder about clock_getres(): half the architectures seem to implement > it in vdso, but notably arm32 and x86 don't, and I had not expected it to be > performance critical given that the result is easily cached in user space. getres() is not really performance critical, but adding it does not create a huge problem either. Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/10] staging: gasket: page_table: use total_entries for max ext lvl0 page idx
From: Nick Ewalt
The maximum number of entries in the page table is configurable at
initialization time and should be used in gasket_extended_lvl0_page_idx.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index 779ad2f23ef9b..8364b49f147c2 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -562,7 +562,7 @@ static ulong gasket_extended_lvl0_page_idx(struct
gasket_page_table *pg_tbl,
ulong dev_addr)
{
return (dev_addr >> GASKET_EXTENDED_LVL0_SHIFT) &
- ((1 << GASKET_EXTENDED_LVL0_WIDTH) - 1);
+ (pg_tbl->config.total_entries - 1);
}
/*
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/10] staging: gasket: Kconfig: describe Apex as an Edge TPU device
From: Todd Poynor Add a brief description and URL for more information on the Apex device, an Edge TPU (Tensorflow Processing Unit) machine learning accelerator. Signed-off-by: Todd Poynor --- drivers/staging/gasket/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/gasket/Kconfig b/drivers/staging/gasket/Kconfig index 970e299046c37..e82b85541f7ef 100644 --- a/drivers/staging/gasket/Kconfig +++ b/drivers/staging/gasket/Kconfig @@ -14,8 +14,9 @@ config STAGING_APEX_DRIVER tristate "Apex Driver" depends on STAGING_GASKET_FRAMEWORK help - This driver supports the Apex device. Say Y if you want to - include this driver in the kernel. + This driver supports the Apex Edge TPU device. See + https://cloud.google.com/edge-tpu/ for more information. + Say Y if you want to include this driver in the kernel. To compile this driver as a module, choose M here. The module will be called "apex". -- 2.19.0.397.gdd90340f6a-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 06/10] staging: gasket: page_table: don't unmap coherent pages
From: Nick Ewalt
Only call dma_unmap_page if there was an associated dma_map_page call.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index 8fe27e7d1b53c..33d98043953a5 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -610,7 +610,7 @@ static void gasket_perform_unmapping(struct
gasket_page_table *pg_tbl,
/* release the address from the driver, */
if (ptes[i].status == PTE_INUSE) {
- if (ptes[i].dma_addr) {
+ if (ptes[i].page && ptes[i].dma_addr) {
dma_unmap_page(pg_tbl->device, ptes[i].dma_addr,
PAGE_SIZE, DMA_BIDIRECTIONAL);
}
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/10] staging: gasket: fix data page unmap DMA direction
From: Nick Ewalt
The DMA direction supplied to dma_unmap_page should match the
corresponding dma_map_page call, which is mapped bi-directional.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index e86bdc5fc79d2..8fe27e7d1b53c 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -612,7 +612,7 @@ static void gasket_perform_unmapping(struct
gasket_page_table *pg_tbl,
if (ptes[i].status == PTE_INUSE) {
if (ptes[i].dma_addr) {
dma_unmap_page(pg_tbl->device, ptes[i].dma_addr,
- PAGE_SIZE, DMA_FROM_DEVICE);
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
}
if (gasket_release_page(ptes[i].page))
--pg_tbl->num_active_pages;
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/10] staging: gasket: Apex uncloaks, plus fixes
From: Todd Poynor Add a description of the Gasket framework device Apex (it's a Google Edge TPU machine learning accelerator soon to be released), plus a handful of fixes. Nick Ewalt (7): staging: gasket: fix DMA direction for extended page tables staging: gasket: fix data page unmap DMA direction staging: gasket: page_table: don't unmap coherent pages staging: gasket: fix gasket_free_coherent_memory metadata frees staging: gasket: cleanup if dma_map_page fails in gasket_perform_mapping staging: gasket: page_table: use total_entries for max ext lvl0 page idx staging: gasket: page_table: handle failed dma_map_page Todd Poynor (3): staging: gasket: Kconfig: describe Apex as an Edge TPU device staging: gasket: interrupt: remove PCI-MSIX-specific status check staging: gasket: page table: use GFP_KERNEL for dma_alloc_coherent drivers/staging/gasket/Kconfig | 5 +- drivers/staging/gasket/gasket_interrupt.c | 5 -- drivers/staging/gasket/gasket_page_table.c | 61 +++--- 3 files changed, 45 insertions(+), 26 deletions(-) -- 2.19.0.397.gdd90340f6a-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/10] staging: gasket: page_table: handle failed dma_map_page
From: Nick Ewalt
Handle dma_map_page failing in gasket_alloc_extended_subtable: free
memory, don't add invalid page table entry.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index 8364b49f147c2..964146f0df526 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -902,6 +902,17 @@ static int gasket_alloc_extended_subtable(struct
gasket_page_table *pg_tbl,
/* Map the page into DMA space. */
pte->dma_addr = dma_map_page(pg_tbl->device, pte->page, 0, PAGE_SIZE,
DMA_TO_DEVICE);
+ if (dma_mapping_error(pg_tbl->device, pte->dma_addr)) {
+ dev_dbg(pg_tbl->device,
+ "%s: fail to map page [pfn %lx phys %llx]\n",
+ __func__, page_to_pfn(pte->page),
+ page_to_phys(pte->page));
+
+ free_page(page_addr);
+ vfree(pte->sublevel);
+ memset(pte, 0, sizeof(struct gasket_page_table_entry));
+ return -ENOMEM;
+ }
/* make the addresses available to the device */
dma_addr = (pte->dma_addr + pte->offset) | GASKET_VALID_SLOT_FLAG;
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/10] staging: gasket: fix DMA direction for extended page tables
From: Nick Ewalt Extended page tables should be mapped as DMA_TO_DEVICE, not bi-directional. Signed-off-by: Nick Ewalt Signed-off-by: Todd Poynor --- drivers/staging/gasket/gasket_page_table.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/gasket/gasket_page_table.c b/drivers/staging/gasket/gasket_page_table.c index 71b77da2e18ca..e86bdc5fc79d2 100644 --- a/drivers/staging/gasket/gasket_page_table.c +++ b/drivers/staging/gasket/gasket_page_table.c @@ -320,7 +320,7 @@ static void gasket_free_extended_subtable(struct gasket_page_table *pg_tbl, if (pte->dma_addr) dma_unmap_page(pg_tbl->device, pte->dma_addr, PAGE_SIZE, - DMA_BIDIRECTIONAL); + DMA_TO_DEVICE); vfree(pte->sublevel); @@ -894,7 +894,7 @@ static int gasket_alloc_extended_subtable(struct gasket_page_table *pg_tbl, /* Map the page into DMA space. */ pte->dma_addr = dma_map_page(pg_tbl->device, pte->page, 0, PAGE_SIZE, -DMA_BIDIRECTIONAL); +DMA_TO_DEVICE); /* make the addresses available to the device */ dma_addr = (pte->dma_addr + pte->offset) | GASKET_VALID_SLOT_FLAG; -- 2.19.0.397.gdd90340f6a-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/10] staging: gasket: cleanup if dma_map_page fails in gasket_perform_mapping
From: Nick Ewalt
Previously pages would have never been unmapped in this case.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 33 +-
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index c1ce8f984f8e0..779ad2f23ef9b 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -433,6 +433,19 @@ static int is_coherent(struct gasket_page_table *pg_tbl,
ulong host_addr)
return min <= host_addr && host_addr < max;
}
+/* Safely return a page to the OS. */
+static bool gasket_release_page(struct page *page)
+{
+ if (!page)
+ return false;
+
+ if (!PageReserved(page))
+ SetPageDirty(page);
+ put_page(page);
+
+ return true;
+}
+
/*
* Get and map last level page table buffers.
*
@@ -500,6 +513,13 @@ static int gasket_perform_mapping(struct gasket_page_table
*pg_tbl,
(unsigned long long)ptes[i].dma_addr,
(void *)page_to_pfn(page),
(void *)page_to_phys(page));
+
+ /* clean up */
+ if (gasket_release_page(ptes[i].page))
+ --pg_tbl->num_active_pages;
+
+ memset([i], 0,
+ sizeof(struct gasket_page_table_entry));
return -1;
}
}
@@ -571,19 +591,6 @@ static int gasket_alloc_simple_entries(struct
gasket_page_table *pg_tbl,
return 0;
}
-/* Safely return a page to the OS. */
-static bool gasket_release_page(struct page *page)
-{
- if (!page)
- return false;
-
- if (!PageReserved(page))
- SetPageDirty(page);
- put_page(page);
-
- return true;
-}
-
/*
* Unmap and release mapped pages.
* The page table mutex must be held by the caller.
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/10] staging: gasket: fix gasket_free_coherent_memory metadata frees
From: Nick Ewalt Free gasket_coherent_page_entries metadata memory, update data structures accordingly. Signed-off-by: Nick Ewalt Signed-off-by: Todd Poynor --- drivers/staging/gasket/gasket_page_table.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/gasket/gasket_page_table.c b/drivers/staging/gasket/gasket_page_table.c index 33d98043953a5..c1ce8f984f8e0 100644 --- a/drivers/staging/gasket/gasket_page_table.c +++ b/drivers/staging/gasket/gasket_page_table.c @@ -1353,6 +1353,11 @@ int gasket_free_coherent_memory(struct gasket_dev *gasket_dev, u64 size, gasket_dev->coherent_buffer.virt_base = NULL; gasket_dev->coherent_buffer.phys_base = 0; } + + kfree(gasket_dev->page_table[index]->coherent_pages); + gasket_dev->page_table[index]->coherent_pages = NULL; + gasket_dev->page_table[index]->num_coherent_pages = 0; + return 0; } -- 2.19.0.397.gdd90340f6a-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/10] staging: gasket: page table: use GFP_KERNEL for dma_alloc_coherent
From: Todd Poynor Flags should be specified for dma_alloc_coherent() call. Use GFP_KERNEL, it's fine to sleep here. Signed-off-by: Todd Poynor --- drivers/staging/gasket/gasket_page_table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/gasket/gasket_page_table.c b/drivers/staging/gasket/gasket_page_table.c index 53492f4fad6aa..71b77da2e18ca 100644 --- a/drivers/staging/gasket/gasket_page_table.c +++ b/drivers/staging/gasket/gasket_page_table.c @@ -1287,7 +1287,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev *gasket_dev, u64 size, return -EINVAL; mem = dma_alloc_coherent(gasket_get_device(gasket_dev), -num_pages * PAGE_SIZE, , 0); +num_pages * PAGE_SIZE, , GFP_KERNEL); if (!mem) goto nomem; -- 2.19.0.397.gdd90340f6a-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/10] staging: gasket: interrupt: remove PCI-MSIX-specific status check
From: Todd Poynor
Devices not using MSIX don't use the msix_initialized field, so don't
require it to be set in the interrupt system status check. The general
check for interrupts configured that follows can cover both MSIX and
device-managed interrupts.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_interrupt.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/gasket/gasket_interrupt.c
b/drivers/staging/gasket/gasket_interrupt.c
index 2cd262be65ca0..49d47afad64fa 100644
--- a/drivers/staging/gasket/gasket_interrupt.c
+++ b/drivers/staging/gasket/gasket_interrupt.c
@@ -478,11 +478,6 @@ int gasket_interrupt_system_status(struct gasket_dev
*gasket_dev)
return GASKET_STATUS_DEAD;
}
- if (!gasket_dev->interrupt_data->msix_configured) {
- dev_dbg(gasket_dev->dev, "Interrupt not initialized\n");
- return GASKET_STATUS_LAMED;
- }
-
if (gasket_dev->interrupt_data->num_configured !=
gasket_dev->interrupt_data->num_interrupts) {
dev_dbg(gasket_dev->dev,
--
2.19.0.397.gdd90340f6a-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling
Hi Stefan, On 17/09/2018 12:39, Stefan Wahren wrote: > Hi Phil, > > Am 17.09.2018 um 10:22 schrieb Phil Elwell: >> Both sides of the VCHIQ communications mechanism need to agree on the cache >> line size. Using an incorrect value can lead to data corruption, but having >> the >> two sides using different values is usually worse. >> >> In the absence of an obvious convenient run-time method to determine the >> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a >> Device Tree property, written by the firmware, to configure the kernel >> driver. >> This method was vetoed during the upstreaming process, so a fixed value of 32 >> was used instead, and some corruptions ensued. This is take 2 at arriving at >> the correct value. >> >> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with >> a 64-byte cache line. Document the new string in the binding, and use it on >> the appropriate platforms. >> >> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg" >> declaration for the device node, but it doubles as an indication to the >> Raspberry Pi firmware that the kernel driver is running a recent kernel >> driver >> that chooses the correct value. As such it would help if the DT patches are >> not merged before the driver patch. >> >> v3: Builds without errors, tested on multiple Raspberry Pi models. >> v2: Replaced ARM-specific logic used to determine cache line size with >> a new compatible string for BCM2836 and BCM2837. >> >> Phil Elwell (4): >> staging/vc04_services: Use correct cache line size >> dt-bindings: soc: Document "brcm,bcm2836-vchiq" >> ARM: dts: bcm283x: Correct vchiq compatible string >> ARM: dts: bcm283x: Correct mailbox register sizes > > since my pull requests are out, would it be okay to apply patch #1 for > 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with > these patches)? Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me. Phil ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling
Hi Phil, Am 17.09.2018 um 10:22 schrieb Phil Elwell: > Both sides of the VCHIQ communications mechanism need to agree on the cache > line size. Using an incorrect value can lead to data corruption, but having > the > two sides using different values is usually worse. > > In the absence of an obvious convenient run-time method to determine the > correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a > Device Tree property, written by the firmware, to configure the kernel driver. > This method was vetoed during the upstreaming process, so a fixed value of 32 > was used instead, and some corruptions ensued. This is take 2 at arriving at > the correct value. > > Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with > a 64-byte cache line. Document the new string in the binding, and use it on > the appropriate platforms. > > The final patch is a (seemingly cosmetic) correction of the Device Tree "reg" > declaration for the device node, but it doubles as an indication to the > Raspberry Pi firmware that the kernel driver is running a recent kernel driver > that chooses the correct value. As such it would help if the DT patches are > not merged before the driver patch. > > v3: Builds without errors, tested on multiple Raspberry Pi models. > v2: Replaced ARM-specific logic used to determine cache line size with > a new compatible string for BCM2836 and BCM2837. > > Phil Elwell (4): > staging/vc04_services: Use correct cache line size > dt-bindings: soc: Document "brcm,bcm2836-vchiq" > ARM: dts: bcm283x: Correct vchiq compatible string > ARM: dts: bcm283x: Correct mailbox register sizes since my pull requests are out, would it be okay to apply patch #1 for 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with these patches)? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops
> = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/19] mtd: rawnand: API cleanup (2nd batch)
On Sat, 15 Sep 2018 19:54:40 +0200
Miquel Raynal wrote:
> Hi Boris,
>
> Boris Brezillon wrote on Fri, 7 Sep 2018
> 00:38:32 +0200:
>
> > Hello,
> >
> > This is the 2nd batch of API cleanup patches. This time we move
> > deprecated hooks/fields to the nand_legacy struct, and then move some
> > of the code found in nand_base.c into separate source/header files.
> >
> > With this new organization, new comers should more easily identify the
> > bits they can use in their NAND controller drivers and those that are
> > only meant for core code. It also shrink a bit nand_base.c which was
> > over 6000 lines of code.
> >
> > Note that existing coding style issues (reported by checkpatch) in arch
> > or driver code are intentionally not fixed to keep the series focused
> > on the API/core cleanup.
> >
> > Regards,
> >
> > Boris
> >
> > Boris Brezillon (19):
> > mtd: rawnand: Leave chip->IO_ADDR_{R,W} to NULL when unused
> > mtd: rawnand: Create a legacy struct and move ->IO_ADDR_{R,W} there
> > mtd: rawnand: Deprecate ->{read,write}_{byte,buf}() hooks
> > mtd: rawnand: Deprecate ->cmd_ctrl() and ->cmdfunc()
> > mtd: rawnand: Deprecate ->dev_ready() and ->waitfunc()
> > mtd: rawnand: Deprecate ->block_{bad,markbad}() hooks
> > mtd: rawnand: Deprecate ->erase()
> > mtd: rawnand: Deprecate ->{set,get}_features() hooks
> > mtd: rawnand: Deprecate ->chip_delay
> > mtd: rawnand: Move function prototypes after struct declarations
> > mtd: rawnand: Get rid of nand_flash_dev forward declation
> > mtd: rawnand: Get rid of the duplicate nand_chip forward declaration
> > mtd: rawnand: Get rid of a few unused definitions
> > mtd: rawnand: Move platform_nand_xxx definitions out of rawnand.h
> > mtd: rawnand: Inline onfi_get_async_timing_mode()
> > mtd: rawnand: Keep all internal stuff private
> > mtd: rawnand: Move legacy code to nand_legacy.c
> > mtd: rawnand: Move ONFI code to nand_onfi.c
> > mtd: rawnand: Move JEDEC code to nand_jedec.c
> >
> > Documentation/driver-api/mtdnand.rst | 30 +-
> > arch/arm/mach-ep93xx/snappercl15.c |8 +-
> > arch/arm/mach-ep93xx/ts72xx.c|9 +-
> > arch/arm/mach-imx/mach-qong.c|6 +-
> > arch/arm/mach-ixp4xx/ixdp425-setup.c |2 +-
> > arch/arm/mach-omap1/board-fsample.c |3 +-
> > arch/arm/mach-omap1/board-h2.c |3 +-
> > arch/arm/mach-omap1/board-h3.c |2 +-
> > arch/arm/mach-omap1/board-nand.c |2 +-
> > arch/arm/mach-omap1/board-perseus2.c |3 +-
> > arch/arm/mach-orion5x/ts78xx-setup.c |9 +-
> > arch/arm/mach-pxa/balloon3.c |5 +-
> > arch/arm/mach-pxa/em-x270.c |9 +-
> > arch/arm/mach-pxa/palmtx.c |5 +-
> > arch/mips/alchemy/devboards/db1200.c |9 +-
> > arch/mips/alchemy/devboards/db1300.c |9 +-
> > arch/mips/alchemy/devboards/db1550.c |9 +-
> > arch/mips/netlogic/xlr/platform-flash.c |3 +-
> > arch/mips/pnx833x/common/platform.c |5 +-
> > arch/mips/rb532/devices.c|5 +-
> > arch/sh/boards/mach-migor/setup.c|8 +-
> > drivers/mtd/nand/raw/Makefile|4 +-
> > drivers/mtd/nand/raw/ams-delta.c | 22 +-
> > drivers/mtd/nand/raw/atmel/nand-controller.c | 22 +-
> > drivers/mtd/nand/raw/au1550nd.c | 43 +-
> > drivers/mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c | 22 +-
> > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 15 +-
> > drivers/mtd/nand/raw/cafe_nand.c | 22 +-
> > drivers/mtd/nand/raw/cmx270_nand.c | 28 +-
> > drivers/mtd/nand/raw/cs553x_nand.c | 42 +-
> > drivers/mtd/nand/raw/davinci_nand.c | 34 +-
> > drivers/mtd/nand/raw/denali.c| 23 +-
> > drivers/mtd/nand/raw/diskonchip.c| 50 +-
> > drivers/mtd/nand/raw/fsl_elbc_nand.c | 18 +-
> > drivers/mtd/nand/raw/fsl_ifc_nand.c | 24 +-
> > drivers/mtd/nand/raw/fsl_upm.c | 30 +-
> > drivers/mtd/nand/raw/fsmc_nand.c |1 -
> > drivers/mtd/nand/raw/gpio.c | 16 +-
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 22 +-
> > drivers/mtd/nand/raw/hisi504_nand.c | 18 +-
> > drivers/mtd/nand/raw/internals.h | 114 ++
> > drivers/mtd/nand/raw/jz4740_nand.c | 14 +-
> > drivers/mtd/nand/raw/jz4780_nand.c | 10 +-
> > drivers/mtd/nand/raw/lpc32xx_mlc.c | 12 +-
> > drivers/mtd/nand/raw/lpc32xx_slc.c | 26 +-
> > drivers/mtd/nand/raw/mpc5121_nfc.c | 14 +-
> > drivers/mtd/nand/raw/mtk_nand.c
[PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"
"brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure correct operation. Signed-off-by: Phil Elwell Acked-by: Stefan Wahren --- Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt index 8dd7b3a..f331316 100644 --- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt @@ -2,7 +2,8 @@ Broadcom VCHIQ firmware services Required properties: -- compatible: Should be "brcm,bcm2835-vchiq" +- compatible: Should be "brcm,bcm2835-vchiq" on BCM2835, otherwise + "brcm,bcm2836-vchiq". - reg: Physical base address and length of the doorbell register pair - interrupts: The interrupt number See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/4] ARM: dts: bcm283x: Correct mailbox register sizes
The size field in a Device Tree "reg" property is encoded in bytes, not
words.
Fixes: 614fa22119d6 ("ARM: dts: bcm2835: Add VCHIQ node to the Raspberry Pi
boards. (v3)")
Signed-off-by: Phil Elwell
Acked-by: Stefan Wahren
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 215d8cc..29f970f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -32,7 +32,7 @@
vchiq: mailbox@7e00b840 {
compatible = "brcm,bcm2835-vchiq";
- reg = <0x7e00b840 0xf>;
+ reg = <0x7e00b840 0x3c>;
interrupts = <0 2>;
};
};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 3/4] ARM: dts: bcm283x: Correct vchiq compatible string
To allow VCHIQ to determine the correct cache line size, use the new
"brcm,bcm2836-vchiq" compatible string on BCM2836 and BCM2837.
Signed-off-by: Phil Elwell
Acked-by: Stefan Wahren
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +-
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 2 +-
arch/arm/boot/dts/bcm2836-rpi.dtsi | 6 ++
arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +-
arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi | 2 +-
6 files changed, 11 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index cb2d6d7..215d8cc 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -30,7 +30,7 @@
#power-domain-cells = <1>;
};
- mailbox@7e00b840 {
+ vchiq: mailbox@7e00b840 {
compatible = "brcm,bcm2835-vchiq";
reg = <0x7e00b840 0xf>;
interrupts = <0 2>;
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 2fef70a..ac4408b 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
#include "bcm2836.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi
b/arch/arm/boot/dts/bcm2836-rpi.dtsi
new file mode 100644
index 000..c4c858b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "bcm2835-rpi.dtsi"
+
+ {
+ compatible = "brcm,bcm2836-vchiq", "brcm,bcm2835-vchiq";
+};
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
index 4adb85e..eca36e3 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
#include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
#include "bcm283x-rpi-lan7515.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index c318bcb..a0ba0f6 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
#include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
diff --git a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
index 7b7ab6a..4a89a18 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
+++ b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
#include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
/ {
memory {
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/4] staging/vc04_services: Use correct cache line size
Use the compatible string in the DTB to select the correct cache line
size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837.
Signed-off-by: Phil Elwell
---
.../interface/vchiq_arm/vchiq_2835_arm.c | 4 ++-
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 35 +++---
.../vc04_services/interface/vchiq_arm/vchiq_arm.h | 5
3 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index e767209..83d740f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -109,7 +109,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
{
struct device *dev = >dev;
- struct rpi_firmware *fw = platform_get_drvdata(pdev);
+ struct vchiq_drvdata *drvdata = platform_get_drvdata(pdev);
+ struct rpi_firmware *fw = drvdata->fw;
VCHIQ_SLOT_ZERO_T *vchiq_slot_zero;
struct resource *res;
void *slot_mem;
@@ -127,6 +128,7 @@ int vchiq_platform_init(struct platform_device *pdev,
VCHIQ_STATE_T *state)
if (err < 0)
return err;
+ g_cache_line_size = drvdata->cache_line_size;
g_fragments_size = 2 * g_cache_line_size;
/* Allocate space for the channels in coherent memory */
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index bc05c69..ea78937 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -170,6 +170,14 @@ static struct device *vchiq_dev;
static DEFINE_SPINLOCK(msg_queue_spinlock);
static struct platform_device *bcm2835_camera;
+static struct vchiq_drvdata bcm2835_drvdata = {
+ .cache_line_size = 32,
+};
+
+static struct vchiq_drvdata bcm2836_drvdata = {
+ .cache_line_size = 64,
+};
+
static const char *const ioctl_names[] = {
"CONNECT",
"SHUTDOWN",
@@ -3573,12 +3581,25 @@ void vchiq_platform_conn_state_changed(VCHIQ_STATE_T
*state,
}
}
+static const struct of_device_id vchiq_of_match[] = {
+ { .compatible = "brcm,bcm2835-vchiq", .data = _drvdata },
+ { .compatible = "brcm,bcm2836-vchiq", .data = _drvdata },
+ {},
+};
+MODULE_DEVICE_TABLE(of, vchiq_of_match);
+
static int vchiq_probe(struct platform_device *pdev)
{
struct device_node *fw_node;
- struct rpi_firmware *fw;
+ const struct of_device_id *of_id;
+ struct vchiq_drvdata *drvdata;
int err;
+ of_id = of_match_node(vchiq_of_match, pdev->dev.of_node);
+ drvdata = (struct vchiq_drvdata *)of_id->data;
+ if (!drvdata)
+ return -EINVAL;
+
fw_node = of_find_compatible_node(NULL, NULL,
"raspberrypi,bcm2835-firmware");
if (!fw_node) {
@@ -3586,12 +3607,12 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
- fw = rpi_firmware_get(fw_node);
+ drvdata->fw = rpi_firmware_get(fw_node);
of_node_put(fw_node);
- if (!fw)
+ if (!drvdata->fw)
return -EPROBE_DEFER;
- platform_set_drvdata(pdev, fw);
+ platform_set_drvdata(pdev, drvdata);
err = vchiq_platform_init(pdev, _state);
if (err != 0)
@@ -3661,12 +3682,6 @@ static int vchiq_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id vchiq_of_match[] = {
- { .compatible = "brcm,bcm2835-vchiq", },
- {},
-};
-MODULE_DEVICE_TABLE(of, vchiq_of_match);
-
static struct platform_driver vchiq_driver = {
.driver = {
.name = "bcm2835_vchiq",
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
index 40bb0c6..2f3ebc9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
@@ -123,6 +123,11 @@ typedef struct vchiq_arm_state_struct {
} VCHIQ_ARM_STATE_T;
+struct vchiq_drvdata {
+ const unsigned int cache_line_size;
+ struct rpi_firmware *fw;
+};
+
extern int vchiq_arm_log_level;
extern int vchiq_susp_log_level;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/4] Improve VCHIQ cache line size handling
Both sides of the VCHIQ communications mechanism need to agree on the cache line size. Using an incorrect value can lead to data corruption, but having the two sides using different values is usually worse. In the absence of an obvious convenient run-time method to determine the correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a Device Tree property, written by the firmware, to configure the kernel driver. This method was vetoed during the upstreaming process, so a fixed value of 32 was used instead, and some corruptions ensued. This is take 2 at arriving at the correct value. Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with a 64-byte cache line. Document the new string in the binding, and use it on the appropriate platforms. The final patch is a (seemingly cosmetic) correction of the Device Tree "reg" declaration for the device node, but it doubles as an indication to the Raspberry Pi firmware that the kernel driver is running a recent kernel driver that chooses the correct value. As such it would help if the DT patches are not merged before the driver patch. v3: Builds without errors, tested on multiple Raspberry Pi models. v2: Replaced ARM-specific logic used to determine cache line size with a new compatible string for BCM2836 and BCM2837. Phil Elwell (4): staging/vc04_services: Use correct cache line size dt-bindings: soc: Document "brcm,bcm2836-vchiq" ARM: dts: bcm283x: Correct vchiq compatible string ARM: dts: bcm283x: Correct mailbox register sizes .../bindings/soc/bcm/brcm,bcm2835-vchiq.txt| 3 +- arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 +-- arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 2 +- arch/arm/boot/dts/bcm2836-rpi.dtsi | 6 arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 2 +- arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +- arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi | 2 +- .../interface/vchiq_arm/vchiq_2835_arm.c | 4 ++- .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 35 +++--- .../vc04_services/interface/vchiq_arm/vchiq_arm.h | 5 10 files changed, 47 insertions(+), 18 deletions(-) create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: vmbus: include header for get_irq_regs()
On 2018-09-15 23:26:53 [+], Michael Kelley (EOSG) wrote: > From Sebastian Andrzej Siewior Sent: Thursday, August 30, 2018 12:55 AM > > > > On !RT the header file get_irq_regs() gets pulled in via other header > > files. On > > RT it does not and the build fails: > > > > drivers/hv/vmbus_drv.c:975 implicit declaration of function > > ‘get_irq_regs’ [- > > Werror=implicit-function-declaration] > > drivers/hv/hv.c:115 implicit declaration of function ‘get_irq_regs’ > > [-Werror=implicit- > > function-declaration] > > > > Add the header file for get_irq_regs() in a common header so it used by > > vmbus_drv.c by hv.c for their get_irq_regs() usage. > > > > get_irq_regs() is not used explicitly in either vmbus_drv.c or in hv.c. And I > couldn't make the line numbers in the errors above line up with anything > in the source code that might be implicitly using get_irq_regs(). Is it the > calls to add_interrupt_randomness()? Did you figure out > exactly what line of code is causing the compile error? The line mentioned in the patch, is correct. I just figured out that function is added as part preempt-RT. > I'm wondering whether adding the #include of irq.h into hyperv_vmbus.h > is really the right solution. More correct might be to have the file where > get_irq_regs() is actually used to #include irq_regs.h. nah, leave it. I'm sorry, that I haven't seen it earlier. I will submit a complete patch once I get there. It popped during a stable update so I assumed it was something that came via stable but it actually was there the whole time. Again, sorry for the noise. > Michael Sebastian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock
Am 03.09.18 um 02:36 schrieb Rashmica:
> Hi David,
>
>
> On 21/08/18 20:44, David Hildenbrand wrote:
>
>> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
>> fix concurrent memory hot-add deadlock"), which tried to fix a possible
>> lock inversion reported and discussed in [1] due to the two locks
>> a) device_lock()
>> b) mem_hotplug_lock
>>
>> While add_memory() first takes b), followed by a) during
>> bus_probe_device(), onlining of memory from user space first took b),
>> followed by a), exposing a possible deadlock.
>
> Do you mean "onlining of memory from user space first took a),
> followed by b)"?
Very right, thanks.
>
>> In [1], and it was decided to not make use of device_hotplug_lock, but
>> rather to enforce a locking order.
>>
>> The problems I spotted related to this:
>>
>> 1. Memory block device attributes: While .state first calls
>>mem_hotplug_begin() and the calls device_online() - which takes
>>device_lock() - .online does no longer call mem_hotplug_begin(), so
>>effectively calls online_pages() without mem_hotplug_lock.
>>
>> 2. device_online() should be called under device_hotplug_lock, however
>>onlining memory during add_memory() does not take care of that.
>>
>> In addition, I think there is also something wrong about the locking in
>>
>> 3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages()
>>without locks. This was introduced after 30467e0b3be. And skimming over
>>the code, I assume it could need some more care in regards to locking
>>(e.g. device_online() called without device_hotplug_lock - but I'll
>>not touch that for now).
>
> Can you mention that you fixed this in later patches?
Sure!
>
>
> The series looks good to me. Feel free to add my reviewed-by:
>
> Reviewed-by: Rashmica Gupta
>
Thanks, r-b only for this patch or all of the series?
--
Thanks,
David / dhildenb
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
REF:- INSTRUCTION TO CREDIT YOUR ACCOUNT WITH THE SUM OF (US$10Million)149.56.201.188
NATWEST BANK PLC, 10 Southwark Street , London Bridge , London - UK SE1 1TT RC: 121878 Our Ref: NTB/WESTMIN/INTER-15 Your Ref: Affidavit: AFX 076GD7B24 Tell=+447035969549 Fax+448435643403 REF:- INSTRUCTION TO CREDIT YOUR ACCOUNT WITH THE SUM OF (US$10Million) This is the second time we are notifying you about this said fund. After due vetting and evaluation of your file that Was sent to us by the Nigerian Government in conjunction with the Ministry of Finance and Central Bank of the Federal Republic of Nigeria. This bank has an instruction to see to the immediate release of the sum of (US$10Million) of your claim that has been holding since is transferred into your bank Account from their Domiciliary Account with this bank. We were meant to understand from our findings that you have been going through hard ways by Paying a lot of charges to see to the release of your fund (US$10Million), Which has been the handwork of some miscreant elements from that Country. We advise that you stop further communication with any correspondence from any bank, or anywhere Concerning your funds as you will receive your fund from this bank if you follow our instruction. Do not go through anybody again but through this Bank if you really want your fund. Finally, you are advice to re-confirm these to us, Your Full Name, Contact address, Occupation Telephone and Fax Number for easy communication. We need your second email gmail or hotmail for security and private reasons. Yours sincerely, Mr Anthony M. Smith Head Of Account Department, NatWest Bank, London United Kingdom. Here is my private! Email address (michaelsm...@post.cz) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
