* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Jonathan Cameron @ 2019-08-22 10:29 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm, Mark Rutland,
linux-kernel, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, James Morse,
Paolo Bonzini, Julien Thierry
In-Reply-To: <20190821153656.33429-5-steven.price@arm.com>
On Wed, 21 Aug 2019 16:36:50 +0100
Steven Price <steven.price@arm.com> wrote:
> kvm_put_guest() is analogous to put_user() - it writes a single value to
> the guest physical address. The implementation is built upon put_user()
> and so it has the same single copy atomic properties.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> include/linux/kvm_host.h | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index fcb46b3374c6..e154a1897e20 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -746,6 +746,30 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
> unsigned long len);
> int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
> gpa_t gpa, unsigned long len);
> +
> +#define __kvm_put_guest(kvm, gfn, offset, value, type) \
> +({ \
> + unsigned long __addr = gfn_to_hva(kvm, gfn); \
> + type __user *__uaddr = (type __user *)(__addr + offset); \
> + int __ret = 0; \
Why initialize __ret?
> + \
> + if (kvm_is_error_hva(__addr)) \
> + __ret = -EFAULT; \
> + else \
> + __ret = put_user(value, __uaddr); \
> + if (!__ret) \
> + mark_page_dirty(kvm, gfn); \
> + __ret; \
> +})
> +
> +#define kvm_put_guest(kvm, gpa, value, type) \
> +({ \
> + gpa_t __gpa = gpa; \
> + struct kvm *__kvm = kvm; \
> + __kvm_put_guest(__kvm, __gpa >> PAGE_SHIFT, \
> + offset_in_page(__gpa), (value), type); \
> +})
> +
> int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int offset, int len);
> int kvm_clear_guest(struct kvm *kvm, gpa_t gpa, unsigned long len);
> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
^ permalink raw reply
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Steven Price @ 2019-08-22 10:37 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, linux-kernel, Russell King,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190822112930.000052db@huawei.com>
On 22/08/2019 11:29, Jonathan Cameron wrote:
> On Wed, 21 Aug 2019 16:36:50 +0100
> Steven Price <steven.price@arm.com> wrote:
>
>> kvm_put_guest() is analogous to put_user() - it writes a single value to
>> the guest physical address. The implementation is built upon put_user()
>> and so it has the same single copy atomic properties.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> include/linux/kvm_host.h | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index fcb46b3374c6..e154a1897e20 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -746,6 +746,30 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
>> unsigned long len);
>> int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
>> gpa_t gpa, unsigned long len);
>> +
>> +#define __kvm_put_guest(kvm, gfn, offset, value, type) \
>> +({ \
>> + unsigned long __addr = gfn_to_hva(kvm, gfn); \
>> + type __user *__uaddr = (type __user *)(__addr + offset); \
>> + int __ret = 0; \
>
> Why initialize __ret?
Good question. Actually looking at this again if I reorder this to be
pessimistic I can make it shorter:
int __ret = -EFAULT;
if (!kvm_is_error_hva(__addr))
__ret = put_user(value, __uaddr);
if (!__ret)
mark_page_dirty(kvm, gfn);
__ret;
Thanks for taking a look.
Steve
>> + \
>> + if (kvm_is_error_hva(__addr)) \
>> + __ret = -EFAULT; \
>> + else \
>> + __ret = put_user(value, __uaddr); \
>> + if (!__ret) \
>> + mark_page_dirty(kvm, gfn); \
>> + __ret; \
>> +})
>> +
>> +#define kvm_put_guest(kvm, gpa, value, type) \
>> +({ \
>> + gpa_t __gpa = gpa; \
>> + struct kvm *__kvm = kvm; \
>> + __kvm_put_guest(__kvm, __gpa >> PAGE_SHIFT, \
>> + offset_in_page(__gpa), (value), type); \
>> +})
>> +
>> int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int offset, int len);
>> int kvm_clear_guest(struct kvm *kvm, gpa_t gpa, unsigned long len);
>> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH v3 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Jonathan Cameron @ 2019-08-22 10:39 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm, Mark Rutland,
linux-kernel, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, James Morse,
Paolo Bonzini, Julien Thierry
In-Reply-To: <20190821153656.33429-6-steven.price@arm.com>
On Wed, 21 Aug 2019 16:36:51 +0100
Steven Price <steven.price@arm.com> wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space. The hypervisor then updates the shared structure using
> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
> reporting the stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
One totally trivial comment inline... Feel free to ignore :)
> ---
> arch/arm/include/asm/kvm_host.h | 20 +++++++++
> arch/arm64/include/asm/kvm_host.h | 25 +++++++++++-
> arch/arm64/kvm/Kconfig | 1 +
> include/linux/kvm_types.h | 2 +
> virt/kvm/arm/arm.c | 10 +++++
> virt/kvm/arm/hypercalls.c | 3 ++
> virt/kvm/arm/pvtime.c | 67 +++++++++++++++++++++++++++++++
> 7 files changed, 127 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 369b5d2d54bf..47d2ced99421 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -39,6 +39,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -329,6 +330,25 @@ static inline int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return SMCCC_RET_NOT_SUPPORTED;
> }
>
> +static inline int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + return SMCCC_RET_NOT_SUPPORTED;
> +}
> +
> +static inline int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void kvm_pvtime_init_vm(struct kvm_arch *kvm_arch)
> +{
> +}
> +
> +static inline bool kvm_is_pvtime_enabled(struct kvm_arch *kvm_arch)
> +{
> + return false;
> +}
> +
> void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 583b3639062a..b6fa7beffd8a 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -83,6 +84,11 @@ struct kvm_arch {
>
> /* Mandated version of PSCI */
> u32 psci_version;
> +
> + struct kvm_arch_pvtime {
> + gpa_t st_base;
> + u64 st_size;
> + } pvtime;
> };
>
> #define KVM_NR_MEM_OBJS 40
> @@ -338,8 +344,13 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
> * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + } steal;
> +};
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> @@ -479,6 +490,18 @@ int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
> +
> +static inline void kvm_pvtime_init_vm(struct kvm_arch *kvm_arch)
> +{
> + kvm_arch->pvtime.st_base = GPA_INVALID;
> +}
> +
> +static inline bool kvm_is_pvtime_enabled(struct kvm_arch *kvm_arch)
> +{
> + return (kvm_arch->pvtime.st_base != GPA_INVALID);
> +}
>
> void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -35,6 +35,8 @@ typedef unsigned long gva_t;
> typedef u64 gpa_t;
> typedef u64 gfn_t;
>
> +#define GPA_INVALID (~(gpa_t)0)
> +
> typedef unsigned long hva_t;
> typedef u64 hpa_t;
> typedef u64 hfn_t;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 35a069815baf..5e8343e2dd62 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -40,6 +40,10 @@
> #include <asm/kvm_coproc.h>
> #include <asm/sections.h>
>
> +#include <kvm/arm_hypercalls.h>
> +#include <kvm/arm_pmu.h>
> +#include <kvm/arm_psci.h>
> +
> #ifdef REQUIRES_VIRT
> __asm__(".arch_extension virt");
> #endif
> @@ -135,6 +139,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = vgic_present ?
> kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
>
> + kvm_pvtime_init_vm(&kvm->arch);
> return ret;
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> @@ -379,6 +384,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vcpu_load_sysregs(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> + if (kvm_is_pvtime_enabled(&vcpu->kvm->arch))
> + kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
>
> if (single_task_running())
> vcpu_clear_wfe_traps(vcpu);
> @@ -644,6 +651,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> * that a VCPU sees new virtual interrupts.
> */
> kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> +
> + if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
> + kvm_update_stolen_time(vcpu, false);
> }
> }
>
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index 63ae629c466a..ac678eabf15f 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -56,6 +56,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_HV_PV_FEATURES:
> val = kvm_hypercall_pv_features(vcpu);
> break;
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + val = kvm_hypercall_stolen_time(vcpu);
> + break;
> default:
> return kvm_psci_call(vcpu);
> }
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index 6201d71cb1f8..28603689f6e0 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -3,8 +3,51 @@
>
> #include <linux/arm-smccc.h>
>
> +#include <asm/pvclock-abi.h>
> +
> #include <kvm/arm_hypercalls.h>
>
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
> + u64 steal;
> + u64 steal_le;
> + u64 offset;
> + int idx;
> + const int stride = sizeof(struct pvclock_vcpu_stolen_time);
> +
> + if (pvtime->st_base == GPA_INVALID)
> + return -ENOTSUPP;
> +
> + /* Let's do the local bookkeeping */
> + steal = vcpu->arch.steal.steal;
> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> + vcpu->arch.steal.steal = steal;
> +
> + offset = stride * kvm_vcpu_get_idx(vcpu);
> +
> + if (unlikely(offset + stride > pvtime->st_size))
> + return -EINVAL;
> +
> + steal_le = cpu_to_le64(steal);
> + idx = srcu_read_lock(&kvm->srcu);
> + if (init) {
> + struct pvclock_vcpu_stolen_time init_values = {
> + .revision = 0,
> + .attributes = 0
> + };
> + kvm_write_guest(kvm, pvtime->st_base + offset, &init_values,
> + sizeof(init_values));
> + }
> + offset += offsetof(struct pvclock_vcpu_stolen_time, stolen_time);
> + kvm_put_guest(kvm, pvtime->st_base + offset, steal_le, u64);
> + srcu_read_unlock(&kvm->srcu, idx);
> +
> + return 0;
> +}
> +
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> u32 feature = smccc_get_arg1(vcpu);
> @@ -12,6 +55,7 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
>
> switch (feature) {
> case ARM_SMCCC_HV_PV_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> val = SMCCC_RET_SUCCESS;
> break;
> }
> @@ -19,3 +63,26 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return val;
> }
>
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + u64 ret;
> + int err;
> +
> + /*
> + * Start counting stolen time from the time the guest requests
> + * the feature enabled.
> + */
> + vcpu->arch.steal.steal = 0;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> +
> + err = kvm_update_stolen_time(vcpu, true);
> +
> + if (err)
> + ret = SMCCC_RET_NOT_SUPPORTED;
Trivial by why not
return SMCCC_RET_NOT_SUPPORTED;
return vcpu->kvm->arch.pvtime.st_base +
...
Drops the indentation a bit and puts the error handling out of
line which is slightly nicer to read (to my eyes).
> + else
> + ret = vcpu->kvm->arch.pvtime.st_base +
> + (sizeof(struct pvclock_vcpu_stolen_time) *
> + kvm_vcpu_get_idx(vcpu));
> +
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH v4] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-22 10:44 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland, Masami Hiramatsu,
Ingo Molnar, Peter Zijlstra, Steven Rostedt, Thomas Gleixner,
Will Deacon
In-Reply-To: <1566468150.x8u1577wgh.naveen@linux.ibm.com>
On Thu, 22 Aug 2019 15:52:05 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
>
> Jisheng Zhang wrote:
> > Hi,
> >
> > On Thu, 22 Aug 2019 12:23:58 +0530
> > "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> >> Jisheng Zhang wrote:
> ...
> >> > +/* Ftrace callback handler for kprobes -- called under preepmt
> >> > disabed */
> >> > +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> >> > + struct ftrace_ops *ops, struct pt_regs *regs)
> >> > +{
> >> > + struct kprobe *p;
> >> > + struct kprobe_ctlblk *kcb;
> >> > +
> >> > + /* Preempt is disabled by ftrace */
> >> > + p = get_kprobe((kprobe_opcode_t *)ip);
> >> > + if (unlikely(!p) || kprobe_disabled(p))
> >> > + return;
> >> > +
> >> > + kcb = get_kprobe_ctlblk();
> >> > + if (kprobe_running()) {
> >> > + kprobes_inc_nmissed_count(p);
> >> > + } else {
> >> > + unsigned long orig_ip = instruction_pointer(regs);
> >> > + /* Kprobe handler expects regs->pc = pc + 4 as breakpoint hit */
> >> > + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> >>
> >> Just want to make sure that you've confirmed that this is what happens
> >> with a regular trap/brk based kprobe on ARM64. The reason for setting
> >> the instruction pointer here is to ensure that it is set to the same
> >> value as would be set if there was a trap/brk instruction at the ftrace
> >> location. This ensures that the kprobe pre handler sees the same value
> >> regardless.
> >
> > Due to the arm64's DYNAMIC_FTRACE_WITH_REGS implementation, the code itself
> > is correct. But this doesn't look like "there was a trap instruction at
> > the ftrace location".
> >
> > W/O KPROBE_ON_FTRACE:
> >
> > foo:
> > 00 insA
> > 04 insB
> > 08 insC
> >
> > kprobe's pre_handler() will see pc points to 00.
>
> In this case, the probe will be placed at foo+0x00, so pre_handler()
> seeing that address in pt_regs is correct behavior - as long as arm64
> 'brk' instruction causes an exception with the instruction pointer set
Yep, confirmed with regular trap/brk based kprobes, I do see PC set to
the "brk" instruction.
> *to* the 'brk' instruction. This is similar to how powerpc 'trap' works.
> However, x86 'int3' causes an exception *after* execution of the
> instruction.
Got it. I understand where's the comment "expects regs->pc = pc + 1" from.
>
> >
> > W/ KPROBE_ON_FTRACE:
> >
> > foo:
> > 00 lr saver
> > 04 nop // will be modified to ftrace call ins when KPROBE is armed
> > 08 insA
> > 0c insB
>
> In this case, if user asks for a probe to be placed at 'foo', we will
> choose foo+0x04 and from that point on, the behavior should reflect that
> a kprobe was placed at foo+0x04. In particular, the pre_handler() should
> see foo+0x04 in pt_regs. The post_handler() would then see foo+0x08.
>
> >
> > later, kprobe_ftrace_handler() will see pc points to 04, so pc + 4 will
> > point to 08 the same as the one w/o KPROBE_ON_FTRACE.
>
> I didn't mean to compare regular trap/brk based kprobes with
> KPROBES_ON_FTRACE. The only important aspect is that the handlers see
> consistent pt_regs in both cases, depending on where the kprobe was
> placed. Choosing a different address/offset to place a kprobe during its
> registration is an orthogonal aspect.
Indeed, previously, I want to let the PC point to the same instruction, it
seems I misunderstood the "consistent" meaning.
>
> >
> > It seems I need to fix the comment.
>
> Given your explanation above, I think you can simply drop the first
> adjustment to the instruction pointer before the pre handler invocation.
> The rest of the code looks fine.
>
>
Yep, thanks a lot. Will send out a new version soon.
^ permalink raw reply
* Re: [PATCH v3 07/10] KVM: arm64: Provide a PV_TIME device to user space
From: Jonathan Cameron @ 2019-08-22 10:57 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm, Mark Rutland,
linux-kernel, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, James Morse,
Paolo Bonzini, Julien Thierry
In-Reply-To: <20190821153656.33429-8-steven.price@arm.com>
On Wed, 21 Aug 2019 16:36:53 +0100
Steven Price <steven.price@arm.com> wrote:
> Allow user space to inform the KVM host where in the physical memory
> map the paravirtualized time structures should be located.
>
> A device is created which provides the base address of an array of
> Stolen Time (ST) structures, one for each VCPU. There must be (64 *
> total number of VCPUs) bytes of memory available at this location.
>
> The address is given in terms of the physical address visible to
> the guest and must be page aligned. The guest will discover the address
> via a hypercall.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
Hi Steven,
One general question inline. I'm not particularly familiar with this area
of the kernel, so maybe I'm missing something obvious, but having
.destroy free the kvm_device which wasn't created in .create seems
'unusual'.
Otherwise, FWIW looks good to me.
Jonathan
> ---
> arch/arm/include/asm/kvm_host.h | 4 ++
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/include/uapi/asm/kvm.h | 8 +++
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/arm.c | 1 +
> virt/kvm/arm/pvtime.c | 94 +++++++++++++++++++++++++++++++
> 6 files changed, 110 insertions(+)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 47d2ced99421..b6c8dbc0556b 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -325,6 +325,10 @@ static inline int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> +static inline void kvm_pvtime_init(void)
> +{
> +}
> +
> static inline int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> return SMCCC_RET_NOT_SUPPORTED;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index b6fa7beffd8a..7b2147f62c16 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -489,6 +489,7 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
> int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> +void kvm_pvtime_init(void);
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a507716ae2f..209c4de67306 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -367,6 +367,14 @@ struct kvm_vcpu_events {
> #define KVM_PSCI_RET_INVAL PSCI_RET_INVALID_PARAMS
> #define KVM_PSCI_RET_DENIED PSCI_RET_DENIED
>
> +/* Device Control API: PV_TIME */
> +#define KVM_DEV_ARM_PV_TIME_REGION 0
> +#define KVM_DEV_ARM_PV_TIME_ST 0
> +struct kvm_dev_arm_st_region {
> + __u64 gpa;
> + __u64 size;
> +};
> +
> #endif
>
> #endif /* __ARM_KVM_H__ */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 5e3f12d5359e..265156a984f2 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1222,6 +1222,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_ARM_VGIC_ITS KVM_DEV_TYPE_ARM_VGIC_ITS
> KVM_DEV_TYPE_XIVE,
> #define KVM_DEV_TYPE_XIVE KVM_DEV_TYPE_XIVE
> + KVM_DEV_TYPE_ARM_PV_TIME,
> +#define KVM_DEV_TYPE_ARM_PV_TIME KVM_DEV_TYPE_ARM_PV_TIME
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 5e8343e2dd62..bfb5a842e6ab 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1494,6 +1494,7 @@ static int init_subsystems(void)
>
> kvm_perf_init();
> kvm_coproc_table_init();
> + kvm_pvtime_init();
>
> out:
> on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index 28603689f6e0..3e55c1fb6a49 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -2,7 +2,9 @@
> // Copyright (C) 2019 Arm Ltd.
>
> #include <linux/arm-smccc.h>
> +#include <linux/kvm_host.h>
>
> +#include <asm/kvm_mmu.h>
> #include <asm/pvclock-abi.h>
>
> #include <kvm/arm_hypercalls.h>
> @@ -86,3 +88,95 @@ int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
>
> return ret;
> }
> +
> +static int kvm_arm_pvtime_create(struct kvm_device *dev, u32 type)
> +{
> + return 0;
> +}
> +
> +static void kvm_arm_pvtime_destroy(struct kvm_device *dev)
> +{
> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> +
> + pvtime->st_base = GPA_INVALID;
> + kfree(dev);
Nothing to do with your patch as such... All users do the same.
This seems miss balanced. Why do we need to free the device by hand
when we didn't create it in the create function? I appreciate
the comments say this is needed, but as far as I can see every
single callback does kfree(dev) at the end which seems an
odd thing to do.
> +}
> +
> +static int kvm_arm_pvtime_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + struct kvm *kvm = dev->kvm;
> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
> + u64 __user *user = (u64 __user *)attr->addr;
> + struct kvm_dev_arm_st_region region;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_REGION:
> + if (copy_from_user(®ion, user, sizeof(region)))
> + return -EFAULT;
> + if (region.gpa & ~PAGE_MASK)
> + return -EINVAL;
> + if (region.size & ~PAGE_MASK)
> + return -EINVAL;
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + if (pvtime->st_base != GPA_INVALID)
> + return -EEXIST;
> + pvtime->st_base = region.gpa;
> + pvtime->st_size = region.size;
> + return 0;
> + }
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pvtime_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> + u64 __user *user = (u64 __user *)attr->addr;
> + struct kvm_dev_arm_st_region region;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_REGION:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + region.gpa = pvtime->st_base;
> + region.size = pvtime->st_size;
> + if (copy_to_user(user, ®ion, sizeof(region)))
> + return -EFAULT;
> + return 0;
> + }
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pvtime_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_REGION:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + return 0;
> + }
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static const struct kvm_device_ops pvtime_ops = {
> + "Arm PV time",
> + .create = kvm_arm_pvtime_create,
> + .destroy = kvm_arm_pvtime_destroy,
> + .set_attr = kvm_arm_pvtime_set_attr,
> + .get_attr = kvm_arm_pvtime_get_attr,
> + .has_attr = kvm_arm_pvtime_has_attr
> +};
> +
> +void kvm_pvtime_init(void)
> +{
> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
> +}
^ permalink raw reply
* Re: [PATCH v3 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Steven Price @ 2019-08-22 11:00 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, linux-kernel, Russell King,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190822113942.0000701f@huawei.com>
On 22/08/2019 11:39, Jonathan Cameron wrote:
> On Wed, 21 Aug 2019 16:36:51 +0100
> Steven Price <steven.price@arm.com> wrote:
>
>> Implement the service call for configuring a shared structure between a
>> VCPU and the hypervisor in which the hypervisor can write the time
>> stolen from the VCPU's execution time by other tasks on the host.
>>
>> The hypervisor allocates memory which is placed at an IPA chosen by user
>> space. The hypervisor then updates the shared structure using
>> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
>> reporting the stolen time in nanoseconds.
>>
>> Whenever stolen time is enabled by the guest, the stolen time counter is
>> reset.
>>
>> The stolen time itself is retrieved from the sched_info structure
>> maintained by the Linux scheduler code. We enable SCHEDSTATS when
>> selecting KVM Kconfig to ensure this value is meaningful.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>
> One totally trivial comment inline... Feel free to ignore :)
>
[...]
>> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
>> +{
>> + u64 ret;
>> + int err;
>> +
>> + /*
>> + * Start counting stolen time from the time the guest requests
>> + * the feature enabled.
>> + */
>> + vcpu->arch.steal.steal = 0;
>> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
>> +
>> + err = kvm_update_stolen_time(vcpu, true);
>> +
>> + if (err)
>> + ret = SMCCC_RET_NOT_SUPPORTED;
>
> Trivial by why not
> return SMCCC_RET_NOT_SUPPORTED;
>
> return vcpu->kvm->arch.pvtime.st_base +
> ...
> Drops the indentation a bit and puts the error handling out of
> line which is slightly nicer to read (to my eyes).
Yes that's a nice change - drops the extra "ret" variable too.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v3 07/10] KVM: arm64: Provide a PV_TIME device to user space
From: Steven Price @ 2019-08-22 11:11 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, linux-kernel, Russell King,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190822115722.00005aa7@huawei.com>
On 22/08/2019 11:57, Jonathan Cameron wrote:
> On Wed, 21 Aug 2019 16:36:53 +0100
> Steven Price <steven.price@arm.com> wrote:
>
>> Allow user space to inform the KVM host where in the physical memory
>> map the paravirtualized time structures should be located.
>>
>> A device is created which provides the base address of an array of
>> Stolen Time (ST) structures, one for each VCPU. There must be (64 *
>> total number of VCPUs) bytes of memory available at this location.
>>
>> The address is given in terms of the physical address visible to
>> the guest and must be page aligned. The guest will discover the address
>> via a hypercall.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>
> Hi Steven,
>
> One general question inline. I'm not particularly familiar with this area
> of the kernel, so maybe I'm missing something obvious, but having
> .destroy free the kvm_device which wasn't created in .create seems
> 'unusual'.
>
> Otherwise, FWIW looks good to me.
>
> Jonathan
>
[...]
>> +static void kvm_arm_pvtime_destroy(struct kvm_device *dev)
>> +{
>> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
>> +
>> + pvtime->st_base = GPA_INVALID;
>> + kfree(dev);
>
> Nothing to do with your patch as such... All users do the same.
>
> This seems miss balanced. Why do we need to free the device by hand
> when we didn't create it in the create function? I appreciate
> the comments say this is needed, but as far as I can see every
> single callback does kfree(dev) at the end which seems an
> odd thing to do.
Yes I think this is odd too - indeed when I initially wrote this I
missed off the kfree() call and had to track down the memory leak.
When I looked into potentially tiding this up I found some other
oddities, e.g. "kvm-xive" (arch/powerpc/kvm/book3s_xive.c) doesn't have
a destroy callback. But I can't see anything in the common code which
deals with that case. So I decided to just "go with the flow" at the
moment, since I don't understand how some of these existing devices work
(perhaps they are already broken?).
Steve
>> +}
>> +
>> +static int kvm_arm_pvtime_set_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + struct kvm *kvm = dev->kvm;
>> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
>> + u64 __user *user = (u64 __user *)attr->addr;
>> + struct kvm_dev_arm_st_region region;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PV_TIME_REGION:
>> + if (copy_from_user(®ion, user, sizeof(region)))
>> + return -EFAULT;
>> + if (region.gpa & ~PAGE_MASK)
>> + return -EINVAL;
>> + if (region.size & ~PAGE_MASK)
>> + return -EINVAL;
>> + switch (attr->attr) {
>> + case KVM_DEV_ARM_PV_TIME_ST:
>> + if (pvtime->st_base != GPA_INVALID)
>> + return -EEXIST;
>> + pvtime->st_base = region.gpa;
>> + pvtime->st_size = region.size;
>> + return 0;
>> + }
>> + break;
>> + }
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pvtime_get_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
>> + u64 __user *user = (u64 __user *)attr->addr;
>> + struct kvm_dev_arm_st_region region;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PV_TIME_REGION:
>> + switch (attr->attr) {
>> + case KVM_DEV_ARM_PV_TIME_ST:
>> + region.gpa = pvtime->st_base;
>> + region.size = pvtime->st_size;
>> + if (copy_to_user(user, ®ion, sizeof(region)))
>> + return -EFAULT;
>> + return 0;
>> + }
>> + break;
>> + }
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pvtime_has_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PV_TIME_REGION:
>> + switch (attr->attr) {
>> + case KVM_DEV_ARM_PV_TIME_ST:
>> + return 0;
>> + }
>> + break;
>> + }
>> + return -ENXIO;
>> +}
>> +
>> +static const struct kvm_device_ops pvtime_ops = {
>> + "Arm PV time",
>> + .create = kvm_arm_pvtime_create,
>> + .destroy = kvm_arm_pvtime_destroy,
>> + .set_attr = kvm_arm_pvtime_set_attr,
>> + .get_attr = kvm_arm_pvtime_get_attr,
>> + .has_attr = kvm_arm_pvtime_has_attr
>> +};
>> +
>> +void kvm_pvtime_init(void)
>> +{
>> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
>> +}
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH v4] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-22 11:20 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland, Masami Hiramatsu,
Ingo Molnar, Peter Zijlstra, Steven Rostedt, Thomas Gleixner,
Will Deacon
In-Reply-To: <20190822183254.1bb5576d@xhacker.debian>
Hi,
On Thu, 22 Aug 2019 18:32:54 +0800
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> On Thu, 22 Aug 2019 15:52:05 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> >
> >
> > Jisheng Zhang wrote:
> > > Hi,
> > >
> > > On Thu, 22 Aug 2019 12:23:58 +0530
> > > "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> > >> Jisheng Zhang wrote:
> > ...
> > >> > +/* Ftrace callback handler for kprobes -- called under preepmt
> > >> > disabed */
> > >> > +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> > >> > + struct ftrace_ops *ops, struct pt_regs *regs)
> > >> > +{
> > >> > + struct kprobe *p;
> > >> > + struct kprobe_ctlblk *kcb;
> > >> > +
> > >> > + /* Preempt is disabled by ftrace */
> > >> > + p = get_kprobe((kprobe_opcode_t *)ip);
> > >> > + if (unlikely(!p) || kprobe_disabled(p))
> > >> > + return;
> > >> > +
> > >> > + kcb = get_kprobe_ctlblk();
> > >> > + if (kprobe_running()) {
> > >> > + kprobes_inc_nmissed_count(p);
> > >> > + } else {
> > >> > + unsigned long orig_ip = instruction_pointer(regs);
> > >> > + /* Kprobe handler expects regs->pc = pc + 4 as breakpoint hit */
> > >> > + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> > >>
> > >> Just want to make sure that you've confirmed that this is what happens
> > >> with a regular trap/brk based kprobe on ARM64. The reason for setting
> > >> the instruction pointer here is to ensure that it is set to the same
> > >> value as would be set if there was a trap/brk instruction at the ftrace
> > >> location. This ensures that the kprobe pre handler sees the same value
> > >> regardless.
> > >
> > > Due to the arm64's DYNAMIC_FTRACE_WITH_REGS implementation, the code itself
> > > is correct. But this doesn't look like "there was a trap instruction at
> > > the ftrace location".
> > >
> > > W/O KPROBE_ON_FTRACE:
> > >
> > > foo:
> > > 00 insA
> > > 04 insB
> > > 08 insC
> > >
> > > kprobe's pre_handler() will see pc points to 00.
> >
> > In this case, the probe will be placed at foo+0x00, so pre_handler()
> > seeing that address in pt_regs is correct behavior - as long as arm64
> > 'brk' instruction causes an exception with the instruction pointer set
>
> Yep, confirmed with regular trap/brk based kprobes, I do see PC set to
> the "brk" instruction.
>
> > *to* the 'brk' instruction. This is similar to how powerpc 'trap' works.
> > However, x86 'int3' causes an exception *after* execution of the
> > instruction.
>
> Got it. I understand where's the comment "expects regs->pc = pc + 1" from.
>
> >
> > >
> > > W/ KPROBE_ON_FTRACE:
> > >
> > > foo:
> > > 00 lr saver
> > > 04 nop // will be modified to ftrace call ins when KPROBE is armed
> > > 08 insA
> > > 0c insB
> >
> > In this case, if user asks for a probe to be placed at 'foo', we will
> > choose foo+0x04 and from that point on, the behavior should reflect that
> > a kprobe was placed at foo+0x04. In particular, the pre_handler() should
> > see foo+0x04 in pt_regs. The post_handler() would then see foo+0x08.
> >
> > >
> > > later, kprobe_ftrace_handler() will see pc points to 04, so pc + 4 will
> > > point to 08 the same as the one w/o KPROBE_ON_FTRACE.
> >
> > I didn't mean to compare regular trap/brk based kprobes with
> > KPROBES_ON_FTRACE. The only important aspect is that the handlers see
> > consistent pt_regs in both cases, depending on where the kprobe was
> > placed. Choosing a different address/offset to place a kprobe during its
> > registration is an orthogonal aspect.
>
> Indeed, previously, I want to let the PC point to the same instruction, it
> seems I misunderstood the "consistent" meaning.
>
> >
> > >
> > > It seems I need to fix the comment.
> >
> > Given your explanation above, I think you can simply drop the first
> > adjustment to the instruction pointer before the pre handler invocation.
Just send out v5. But the first adjustment is modified as
instruction_pointer_set(regs, ip);
Because in entry of kprobe_ftrace_handler() pc/ip(the first parameter) points
to foo+0x4, while regs->pc points to foo+0x8. Based on your previous
explanation, I think we should instruction_pointer_set(regs, ip) to let the
pre_handler see foo+0x4
Thanks a lot for your help
^ permalink raw reply
* [PATCH v5] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-22 11:25 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Masami Hiramatsu, Naveen N. Rao
Cc: Thomas Gleixner, Peter Zijlstra, Steven Rostedt, Mark Rutland,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
eliminates the need for a trap, as well as the need to emulate or
single-step instructions.
Tested on berlin arm64 platform.
~ # mount -t debugfs debugfs /sys/kernel/debug/
~ # cd /sys/kernel/debug/
/sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
before the patch:
/sys/kernel/debug # cat kprobes/list
ffffff801009fe28 k _do_fork+0x0 [DISABLED]
after the patch:
/sys/kernel/debug # cat kprobes/list
ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
eliminates the need for a trap, as well as the need to emulate or
single-step instructions.
Applied after arm64 FTRACE_WITH_REGS:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674404.html
Changes since v4:
- correct reg->pc: probed on foo, then pre_handler see foo+0x4, while
post_handler see foo+0x8
Changes since v3:
- move kprobe_lookup_name() and arch_kprobe_on_func_entry to ftrace.c since
we only want to choose the ftrace entry for KPROBES_ON_FTRACE.
- only choose ftrace entry if (addr && !offset)
Changes since v2:
- remove patch1, make it a single cleanup patch
- remove "This patch" in the change log
- implement arm64's kprobe_lookup_name() and arch_kprobe_on_func_entry instead
of patching the common kprobes code
Changes since v1:
- make the kprobes/x86: use instruction_pointer and instruction_pointer_set
as patch1
- add Masami's ACK to patch1
- add some description about KPROBES_ON_FTRACE and why we need it on
arm64
- correct the log before the patch
- remove the consolidation patch, make it as TODO
- only adjust kprobe's addr when KPROBE_FLAG_FTRACE is set
- if KPROBES_ON_FTRACE, ftrace_call_adjust() the kprobe's addr before
calling ftrace_location()
- update the kprobes-on-ftrace/arch-support.txt in doc
.../debug/kprobes-on-ftrace/arch-support.txt | 2 +-
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/probes/Makefile | 1 +
arch/arm64/kernel/probes/ftrace.c | 83 +++++++++++++++++++
4 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kernel/probes/ftrace.c
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
index 68f266944d5f..e8358a38981c 100644
--- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
+++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -9,7 +9,7 @@
| alpha: | TODO |
| arc: | TODO |
| arm: | TODO |
- | arm64: | TODO |
+ | arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
| h8300: | TODO |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 663392d1eae2..928700f15e23 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -167,6 +167,7 @@ config ARM64
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+ select HAVE_KPROBES_ON_FTRACE
select HAVE_KRETPROBES
select HAVE_GENERIC_VDSO
select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
index 8e4be92e25b1..4020cfc66564 100644
--- a/arch/arm64/kernel/probes/Makefile
+++ b/arch/arm64/kernel/probes/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
simulate-insn.o
obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o \
simulate-insn.o
+obj-$(CONFIG_KPROBES_ON_FTRACE) += ftrace.o
diff --git a/arch/arm64/kernel/probes/ftrace.c b/arch/arm64/kernel/probes/ftrace.c
new file mode 100644
index 000000000000..9f80905f02fa
--- /dev/null
+++ b/arch/arm64/kernel/probes/ftrace.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Dynamic Ftrace based Kprobes Optimization
+ *
+ * Copyright (C) Hitachi Ltd., 2012
+ * Copyright (C) 2019 Jisheng Zhang <jszhang@kernel.org>
+ * Synaptics Incorporated
+ */
+
+#include <linux/kprobes.h>
+
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *ops, struct pt_regs *regs)
+{
+ struct kprobe *p;
+ struct kprobe_ctlblk *kcb;
+
+ /* Preempt is disabled by ftrace */
+ p = get_kprobe((kprobe_opcode_t *)ip);
+ if (unlikely(!p) || kprobe_disabled(p))
+ return;
+
+ kcb = get_kprobe_ctlblk();
+ if (kprobe_running()) {
+ kprobes_inc_nmissed_count(p);
+ } else {
+ unsigned long orig_ip = instruction_pointer(regs);
+
+ instruction_pointer_set(regs, ip);
+ __this_cpu_write(current_kprobe, p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ /*
+ * Emulate singlestep (and also recover regs->pc)
+ * as if there is a nop
+ */
+ instruction_pointer_set(regs,
+ (unsigned long)p->addr + MCOUNT_INSN_SIZE);
+ if (unlikely(p->post_handler)) {
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ p->post_handler(p, regs, 0);
+ }
+ instruction_pointer_set(regs, orig_ip);
+ }
+ /*
+ * If pre_handler returns !0, it changes regs->pc. We have to
+ * skip emulating post_handler.
+ */
+ __this_cpu_write(current_kprobe, NULL);
+ }
+}
+NOKPROBE_SYMBOL(kprobe_ftrace_handler);
+
+kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
+{
+ unsigned long addr = kallsyms_lookup_name(name);
+
+ if (addr && !offset) {
+ unsigned long faddr;
+ /*
+ * with -fpatchable-function-entry=2, the first 4 bytes is the
+ * LR saver, then the actual call insn. So ftrace location is
+ * always on the first 4 bytes offset.
+ */
+ faddr = ftrace_location_range(addr,
+ addr + AARCH64_INSN_SIZE);
+ if (faddr)
+ return (kprobe_opcode_t *)faddr;
+ }
+ return (kprobe_opcode_t *)addr;
+}
+
+bool arch_kprobe_on_func_entry(unsigned long offset)
+{
+ return offset <= AARCH64_INSN_SIZE;
+}
+
+int arch_prepare_kprobe_ftrace(struct kprobe *p)
+{
+ p->ainsn.api.insn = NULL;
+ return 0;
+}
--
2.23.0.rc1
^ permalink raw reply related
* Re: [PATCH v3 07/10] KVM: arm64: Provide a PV_TIME device to user space
From: Jonathan Cameron @ 2019-08-22 11:48 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, linux-kernel, Russell King,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <87bc2a01-8cf5-5161-45f8-00384775cf3a@arm.com>
On Thu, 22 Aug 2019 12:11:55 +0100
Steven Price <steven.price@arm.com> wrote:
> On 22/08/2019 11:57, Jonathan Cameron wrote:
> > On Wed, 21 Aug 2019 16:36:53 +0100
> > Steven Price <steven.price@arm.com> wrote:
> >
> >> Allow user space to inform the KVM host where in the physical memory
> >> map the paravirtualized time structures should be located.
> >>
> >> A device is created which provides the base address of an array of
> >> Stolen Time (ST) structures, one for each VCPU. There must be (64 *
> >> total number of VCPUs) bytes of memory available at this location.
> >>
> >> The address is given in terms of the physical address visible to
> >> the guest and must be page aligned. The guest will discover the address
> >> via a hypercall.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >
> > Hi Steven,
> >
> > One general question inline. I'm not particularly familiar with this area
> > of the kernel, so maybe I'm missing something obvious, but having
> > .destroy free the kvm_device which wasn't created in .create seems
> > 'unusual'.
> >
> > Otherwise, FWIW looks good to me.
> >
> > Jonathan
> >
> [...]
> >> +static void kvm_arm_pvtime_destroy(struct kvm_device *dev)
> >> +{
> >> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> >> +
> >> + pvtime->st_base = GPA_INVALID;
> >> + kfree(dev);
> >
> > Nothing to do with your patch as such... All users do the same.
> >
> > This seems miss balanced. Why do we need to free the device by hand
> > when we didn't create it in the create function? I appreciate
> > the comments say this is needed, but as far as I can see every
> > single callback does kfree(dev) at the end which seems an
> > odd thing to do.
>
> Yes I think this is odd too - indeed when I initially wrote this I
> missed off the kfree() call and had to track down the memory leak.
>
> When I looked into potentially tiding this up I found some other
> oddities, e.g. "kvm-xive" (arch/powerpc/kvm/book3s_xive.c) doesn't have
> a destroy callback. But I can't see anything in the common code which
> deals with that case. So I decided to just "go with the flow" at the
> moment, since I don't understand how some of these existing devices work
> (perhaps they are already broken?).
It has a release however and kvm_device_release also removes the
device from the list that would then be cleared by kvm_destroy_devices.
kvm_device_release is a release callback for the file operations so it
'might' be called in all paths.
Fun though, in kvm_ioctl_create_device the error handling for
the anon_inode_getfd calls ops->destroy without checking it exists.
Boom.
Possibly never happens in reality but looks like a bug to me.
Jonathan
>
> Steve
>
> >> +}
> >> +
> >> +static int kvm_arm_pvtime_set_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + struct kvm *kvm = dev->kvm;
> >> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
> >> + u64 __user *user = (u64 __user *)attr->addr;
> >> + struct kvm_dev_arm_st_region region;
> >> +
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PV_TIME_REGION:
> >> + if (copy_from_user(®ion, user, sizeof(region)))
> >> + return -EFAULT;
> >> + if (region.gpa & ~PAGE_MASK)
> >> + return -EINVAL;
> >> + if (region.size & ~PAGE_MASK)
> >> + return -EINVAL;
> >> + switch (attr->attr) {
> >> + case KVM_DEV_ARM_PV_TIME_ST:
> >> + if (pvtime->st_base != GPA_INVALID)
> >> + return -EEXIST;
> >> + pvtime->st_base = region.gpa;
> >> + pvtime->st_size = region.size;
> >> + return 0;
> >> + }
> >> + break;
> >> + }
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pvtime_get_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> >> + u64 __user *user = (u64 __user *)attr->addr;
> >> + struct kvm_dev_arm_st_region region;
> >> +
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PV_TIME_REGION:
> >> + switch (attr->attr) {
> >> + case KVM_DEV_ARM_PV_TIME_ST:
> >> + region.gpa = pvtime->st_base;
> >> + region.size = pvtime->st_size;
> >> + if (copy_to_user(user, ®ion, sizeof(region)))
> >> + return -EFAULT;
> >> + return 0;
> >> + }
> >> + break;
> >> + }
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pvtime_has_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PV_TIME_REGION:
> >> + switch (attr->attr) {
> >> + case KVM_DEV_ARM_PV_TIME_ST:
> >> + return 0;
> >> + }
> >> + break;
> >> + }
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static const struct kvm_device_ops pvtime_ops = {
> >> + "Arm PV time",
> >> + .create = kvm_arm_pvtime_create,
> >> + .destroy = kvm_arm_pvtime_destroy,
> >> + .set_attr = kvm_arm_pvtime_set_attr,
> >> + .get_attr = kvm_arm_pvtime_get_attr,
> >> + .has_attr = kvm_arm_pvtime_has_attr
> >> +};
> >> +
> >> +void kvm_pvtime_init(void)
> >> +{
> >> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
> >> +}
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
^ permalink raw reply
* Re: [PATCH v5] arm64: implement KPROBES_ON_FTRACE
From: Naveen N. Rao @ 2019-08-22 11:52 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Jisheng Zhang, Masami Hiramatsu
Cc: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland, Peter Zijlstra,
Steven Rostedt, Thomas Gleixner
In-Reply-To: <20190822191351.3796aca8@xhacker.debian>
Jisheng Zhang wrote:
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Tested on berlin arm64 platform.
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009fe28 k _do_fork+0x0 [DISABLED]
>
> after the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
^ permalink raw reply
* MY $25,000,000.00 INVESTMENT PROPOSAL WITH YOU AND IN YOUR COUNTRY.
From: Law firm(Eku and Associates) @ 2019-08-22 12:29 UTC (permalink / raw)
--
Dear,
With due respect this is not spam or Scam mail, because I have
contacted you before and there was no response from you,I apologise if
the contents of this mail are contrary to your moral ethics, which I
feel may be of great disturbance to your person, but please treat this
with absolute confidentiality, believing that this email reaches you
in good faith. My contacting you is not a mistake or a coincidence
because God can use any person known or unknown to accomplish great
things.
I am a lawyer and I have an investment business proposal to offer you.
It is not official but should be considered as legal and confidential
business. I have a customer's deposit of $US25 million dollars ready
to be moved for investment if you can partner with us. We are ready to
offer you 10% of this total amount as your compensation for supporting
the transaction to completion. If you are interested to help me please
reply me with your full details as stated below:
(1) Your full names:
(2) Your address:
(3) Your occupation:
(4) Your mobile telephone number:
(5) Your nationality:
(6) Your present location:
(7) Your age:
So that I will provide you more details on what to do and what is
required for successful completion.
Note: DO NOT REPLY ME IF YOU ARE NOT INTERESTED AND WITHOUT THE ABOVE
MENTIONED DETAILS
Sincèrement vôtre,
Avocat Etienne Eku Esq.(Lawfirm)
Procureur principal. De Cabinet d’avocats de l’Afrique de l’ouest.
Skype:westafricalawfirm
^ permalink raw reply
* [PATCH V4 0/3] KVM/Hyper-V: Add Hyper-V direct tlb flush support
From: lantianyu1986 @ 2019-08-22 14:30 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-hyperv, linux-kernel, vkuznets
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V
in L0 can delegate L1 hypervisor to handle tlb flush request from
L2 guest when direct tlb flush is enabled in L1.
Patch 2 introduces new cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH to enable
feature from user space. User space should enable this feature only
when Hyper-V hypervisor capability is exposed to guest and KVM profile
is hided. There is a parameter conflict between KVM and Hyper-V hypercall.
We hope L2 guest doesn't use KVM hypercall when the feature is
enabled. Detail please see comment of new API "KVM_CAP_HYPERV_DIRECT_TLBFLUSH"
Change since v3:
- Update changelog in each patches.
Change since v2:
- Move hv assist page(hv_pa_pg) from struct kvm to struct kvm_hv.
Change since v1:
- Fix offset issue in the patch 1.
- Update description of KVM KVM_CAP_HYPERV_DIRECT_TLBFLUSH.
Tianyu Lan (2):
x86/Hyper-V: Fix definition of struct hv_vp_assist_page
KVM/Hyper-V: Add new KVM capability KVM_CAP_HYPERV_DIRECT_TLBFLUSH
Vitaly Kuznetsov (1):
KVM/Hyper-V/VMX: Add direct tlb flush support
Documentation/virtual/kvm/api.txt | 13 +++++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 24 ++++++++++++++++++-----
arch/x86/include/asm/kvm_host.h | 4 ++++
arch/x86/kvm/vmx/evmcs.h | 2 ++
arch/x86/kvm/vmx/vmx.c | 39 ++++++++++++++++++++++++++++++++++++++
arch/x86/kvm/x86.c | 8 ++++++++
include/uapi/linux/kvm.h | 1 +
7 files changed, 86 insertions(+), 5 deletions(-)
--
2.14.5
^ permalink raw reply
* [PATCH V4 1/3] x86/Hyper-V: Fix definition of struct hv_vp_assist_page
From: lantianyu1986 @ 2019-08-22 14:30 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-kernel, linux-hyperv, vkuznets
In-Reply-To: <20190822143021.7518-1-Tianyu.Lan@microsoft.com>
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
The struct hv_vp_assist_page was defined incorrectly.
The "vtl_control" should be u64[3], "nested_enlightenments
_control" should be a u64 and there are 7 reserved bytes
following "enlighten_vmentry". Fix the definition.
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
---
Change since v3:
- Update changelog
Change since v1:
- Move definition of struct hv_nested_enlightenments_control
into this patch to fix offset issue.
---
arch/x86/include/asm/hyperv-tlfs.h | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
index af78cd72b8f3..cf0b2a04271d 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -514,14 +514,24 @@ struct hv_timer_message_payload {
__u64 delivery_time; /* When the message was delivered */
} __packed;
+struct hv_nested_enlightenments_control {
+ struct {
+ __u32 directhypercall:1;
+ __u32 reserved:31;
+ } features;
+ struct {
+ __u32 reserved;
+ } hypercallControls;
+} __packed;
+
/* Define virtual processor assist page structure. */
struct hv_vp_assist_page {
__u32 apic_assist;
- __u32 reserved;
- __u64 vtl_control[2];
- __u64 nested_enlightenments_control[2];
- __u32 enlighten_vmentry;
- __u32 padding;
+ __u32 reserved1;
+ __u64 vtl_control[3];
+ struct hv_nested_enlightenments_control nested_control;
+ __u8 enlighten_vmentry;
+ __u8 reserved2[7];
__u64 current_nested_vmcs;
} __packed;
--
2.14.5
^ permalink raw reply related
* [PATCH V4 2/3] KVM/Hyper-V: Add new KVM capability KVM_CAP_HYPERV_DIRECT_TLBFLUSH
From: lantianyu1986 @ 2019-08-22 14:30 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-kernel, linux-hyperv, vkuznets
In-Reply-To: <20190822143021.7518-1-Tianyu.Lan@microsoft.com>
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
Hyper-V direct tlb flush function should be enabled for
guest that only uses Hyper-V hypercall. User space
hypervisor(e.g, Qemu) can disable KVM identification in
CPUID and just exposes Hyper-V identification to make
sure the precondition. Add new KVM capability KVM_CAP_
HYPERV_DIRECT_TLBFLUSH for user space to enable Hyper-V
direct tlb function and this function is default to be
disabled in KVM.
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
---
Change since v3:
- Update Changelog.
Change since v1:
- Update description of KVM_CAP_HYPERV_DIRECT_TLBFLUSH
in the KVM API doc.
---
Documentation/virtual/kvm/api.txt | 13 +++++++++++++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 8 ++++++++
include/uapi/linux/kvm.h | 1 +
4 files changed, 24 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 2cd6250b2896..0c6e1b25d0c8 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -5289,3 +5289,16 @@ Architectures: x86
This capability indicates that KVM supports paravirtualized Hyper-V IPI send
hypercalls:
HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx.
+8.21 KVM_CAP_HYPERV_DIRECT_TLBFLUSH
+
+Architecture: x86
+
+This capability indicates that KVM running on top of Hyper-V hypervisor
+enables Direct TLB flush for its guests meaning that TLB flush
+hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM.
+Due to the different ABI for hypercall parameters between Hyper-V and
+KVM, enabling this capability effectively disables all hypercall
+handling by KVM (as some KVM hypercall may be mistakenly treated as TLB
+flush hypercalls by Hyper-V) so userspace should disable KVM identification
+in CPUID and only exposes Hyper-V identification. In this case, guest
+thinks it's running on Hyper-V and only use Hyper-V hypercalls.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0cc5b611a113..667d154e89d4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1205,6 +1205,8 @@ struct kvm_x86_ops {
uint16_t (*nested_get_evmcs_version)(struct kvm_vcpu *vcpu);
bool (*need_emulation_on_page_fault)(struct kvm_vcpu *vcpu);
+
+ int (*enable_direct_tlbflush)(struct kvm_vcpu *vcpu);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9d7b9e6a0939..a9d8ee7f7bf0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3183,6 +3183,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = kvm_x86_ops->get_nested_state ?
kvm_x86_ops->get_nested_state(NULL, NULL, 0) : 0;
break;
+ case KVM_CAP_HYPERV_DIRECT_TLBFLUSH:
+ r = kvm_x86_ops->enable_direct_tlbflush ? 1 : 0;
+ break;
default:
break;
}
@@ -3953,6 +3956,11 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
r = -EFAULT;
}
return r;
+ case KVM_CAP_HYPERV_DIRECT_TLBFLUSH:
+ if (!kvm_x86_ops->enable_direct_tlbflush)
+ return -ENOTTY;
+
+ return kvm_x86_ops->enable_direct_tlbflush(vcpu);
default:
return -EINVAL;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index a7c19540ce21..cb959bc925b1 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -996,6 +996,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
#define KVM_CAP_PMU_EVENT_FILTER 173
+#define KVM_CAP_HYPERV_DIRECT_TLBFLUSH 174
#ifdef KVM_CAP_IRQ_ROUTING
--
2.14.5
^ permalink raw reply related
* Re: [PATCH v5 3/9] fpga: dfl: afu: convert platform_driver to use dev_groups
From: Moritz Fischer @ 2019-08-22 15:07 UTC (permalink / raw)
To: Wu Hao; +Cc: gregkh, mdf, linux-fpga, linux-kernel, linux-api, linux-doc,
atull
In-Reply-To: <1565578204-13969-4-git-send-email-hao.wu@intel.com>
Hi Hao,
On Mon, Aug 12, 2019 at 10:49:58AM +0800, Wu Hao wrote:
> This patch takes advantage of driver core which helps to create
> and remove sysfs attribute files, so there is no need to register
> sysfs entries manually in dfl-afu platform river code.
Same nit: s/river/driver
>
> Signed-off-by: Wu Hao <hao.wu@intel.com>
Acked-by: Moritz Fischer <mdf@kernel.org>
> ---
> drivers/fpga/dfl-afu-main.c | 69 +++++++++++++++++++++++----------------------
> 1 file changed, 36 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
> index e50c45e..e955149 100644
> --- a/drivers/fpga/dfl-afu-main.c
> +++ b/drivers/fpga/dfl-afu-main.c
> @@ -282,24 +282,17 @@ static int port_get_id(struct platform_device *pdev)
> &dev_attr_power_state.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(port_hdr);
> +
> +static const struct attribute_group port_hdr_group = {
> + .attrs = port_hdr_attrs,
> +};
>
> static int port_hdr_init(struct platform_device *pdev,
> struct dfl_feature *feature)
> {
> - dev_dbg(&pdev->dev, "PORT HDR Init.\n");
> -
> port_reset(pdev);
>
> - return device_add_groups(&pdev->dev, port_hdr_groups);
> -}
> -
> -static void port_hdr_uinit(struct platform_device *pdev,
> - struct dfl_feature *feature)
> -{
> - dev_dbg(&pdev->dev, "PORT HDR UInit.\n");
> -
> - device_remove_groups(&pdev->dev, port_hdr_groups);
> + return 0;
> }
>
> static long
> @@ -330,7 +323,6 @@ static void port_hdr_uinit(struct platform_device *pdev,
>
> static const struct dfl_feature_ops port_hdr_ops = {
> .init = port_hdr_init,
> - .uinit = port_hdr_uinit,
> .ioctl = port_hdr_ioctl,
> };
>
> @@ -361,32 +353,37 @@ static void port_hdr_uinit(struct platform_device *pdev,
> &dev_attr_afu_id.attr,
> NULL
> };
> -ATTRIBUTE_GROUPS(port_afu);
>
> -static int port_afu_init(struct platform_device *pdev,
> - struct dfl_feature *feature)
> +static umode_t port_afu_attrs_visible(struct kobject *kobj,
> + struct attribute *attr, int n)
> {
> - struct resource *res = &pdev->resource[feature->resource_index];
> - int ret;
> -
> - dev_dbg(&pdev->dev, "PORT AFU Init.\n");
> + struct device *dev = kobj_to_dev(kobj);
>
> - ret = afu_mmio_region_add(dev_get_platdata(&pdev->dev),
> - DFL_PORT_REGION_INDEX_AFU, resource_size(res),
> - res->start, DFL_PORT_REGION_READ |
> - DFL_PORT_REGION_WRITE | DFL_PORT_REGION_MMAP);
> - if (ret)
> - return ret;
> + /*
> + * sysfs entries are visible only if related private feature is
> + * enumerated.
> + */
> + if (!dfl_get_feature_by_id(dev, PORT_FEATURE_ID_AFU))
> + return 0;
>
> - return device_add_groups(&pdev->dev, port_afu_groups);
> + return attr->mode;
> }
>
> -static void port_afu_uinit(struct platform_device *pdev,
> - struct dfl_feature *feature)
> +static const struct attribute_group port_afu_group = {
> + .attrs = port_afu_attrs,
> + .is_visible = port_afu_attrs_visible,
> +};
> +
> +static int port_afu_init(struct platform_device *pdev,
> + struct dfl_feature *feature)
> {
> - dev_dbg(&pdev->dev, "PORT AFU UInit.\n");
Thanks.
> + struct resource *res = &pdev->resource[feature->resource_index];
>
> - device_remove_groups(&pdev->dev, port_afu_groups);
> + return afu_mmio_region_add(dev_get_platdata(&pdev->dev),
> + DFL_PORT_REGION_INDEX_AFU,
> + resource_size(res), res->start,
> + DFL_PORT_REGION_MMAP | DFL_PORT_REGION_READ |
> + DFL_PORT_REGION_WRITE);
> }
>
> static const struct dfl_feature_id port_afu_id_table[] = {
> @@ -396,7 +393,6 @@ static void port_afu_uinit(struct platform_device *pdev,
>
> static const struct dfl_feature_ops port_afu_ops = {
> .init = port_afu_init,
> - .uinit = port_afu_uinit,
> };
>
> static struct dfl_feature_driver port_feature_drvs[] = {
> @@ -748,9 +744,16 @@ static int afu_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct attribute_group *afu_dev_groups[] = {
> + &port_hdr_group,
> + &port_afu_group,
> + NULL
> +};
> +
> static struct platform_driver afu_driver = {
> .driver = {
> - .name = DFL_FPGA_FEATURE_DEV_PORT,
> + .name = DFL_FPGA_FEATURE_DEV_PORT,
> + .dev_groups = afu_dev_groups,
> },
> .probe = afu_probe,
> .remove = afu_remove,
> --
> 1.8.3.1
>
Thanks,
Moritz
^ permalink raw reply
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Sean Christopherson @ 2019-08-22 15:28 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm,
Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, James Morse, Julien Thierry, Suzuki K Pouloze,
Mark Rutland, kvm, linux-doc, linux-kernel
In-Reply-To: <20190821153656.33429-5-steven.price@arm.com>
On Wed, Aug 21, 2019 at 04:36:50PM +0100, Steven Price wrote:
> kvm_put_guest() is analogous to put_user() - it writes a single value to
> the guest physical address. The implementation is built upon put_user()
> and so it has the same single copy atomic properties.
What you mean by "single copy atomic"? I.e. what guarantees does
put_user() provide that __copy_to_user() does not?
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> include/linux/kvm_host.h | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index fcb46b3374c6..e154a1897e20 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -746,6 +746,30 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
> unsigned long len);
> int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
> gpa_t gpa, unsigned long len);
> +
> +#define __kvm_put_guest(kvm, gfn, offset, value, type) \
> +({ \
> + unsigned long __addr = gfn_to_hva(kvm, gfn); \
> + type __user *__uaddr = (type __user *)(__addr + offset); \
> + int __ret = 0; \
> + \
> + if (kvm_is_error_hva(__addr)) \
> + __ret = -EFAULT; \
> + else \
> + __ret = put_user(value, __uaddr); \
> + if (!__ret) \
> + mark_page_dirty(kvm, gfn); \
> + __ret; \
> +})
> +
> +#define kvm_put_guest(kvm, gpa, value, type) \
> +({ \
> + gpa_t __gpa = gpa; \
> + struct kvm *__kvm = kvm; \
> + __kvm_put_guest(__kvm, __gpa >> PAGE_SHIFT, \
> + offset_in_page(__gpa), (value), type); \
> +})
> +
> int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int offset, int len);
> int kvm_clear_guest(struct kvm *kvm, gpa_t gpa, unsigned long len);
> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Steven Price @ 2019-08-22 15:46 UTC (permalink / raw)
To: Sean Christopherson
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190822152854.GE25467@linux.intel.com>
On 22/08/2019 16:28, Sean Christopherson wrote:
> On Wed, Aug 21, 2019 at 04:36:50PM +0100, Steven Price wrote:
>> kvm_put_guest() is analogous to put_user() - it writes a single value to
>> the guest physical address. The implementation is built upon put_user()
>> and so it has the same single copy atomic properties.
>
> What you mean by "single copy atomic"? I.e. what guarantees does
> put_user() provide that __copy_to_user() does not?
Single-copy atomicity is defined by the Arm architecture[1] and I'm not
going to try to go into the full details here, so this is a summary.
For the sake of this feature what we care about is that the value
written/read cannot be "torn". In other words if there is a read (in
this case from another VCPU) that is racing with the write then the read
will either get the old value or the new value. It cannot return a
mixture. (This is of course assuming that the read is using a
single-copy atomic safe method).
__copy_to_user() is implemented as a memcpy() and as such cannot provide
single-copy atomicity in the general case (the buffer could easily be
bigger than the architecture can guarantee).
put_user() on the other hand is implemented (on arm64) as an explicit
store instruction and therefore is guaranteed by the architecture to be
single-copy atomic (i.e. another CPU cannot see a half-written value).
Steve
[1] https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf#page=110
^ permalink raw reply
* Re: [PATCH v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Catalin Marinas @ 2019-08-22 15:55 UTC (permalink / raw)
To: Dave Martin
Cc: Will Deacon, linux-arch, Dave Hansen, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, linux-doc, Will Deacon, linux-mm,
Andrew Morton, Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20190821184649.GD27757@arm.com>
On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > @@ -59,6 +63,11 @@ be preserved.
> > > The architecture prevents the use of a tagged PC, so the upper byte will
> > > be set to a sign-extension of bit 55 on exception return.
> > >
> > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > +enabled. In addition, with the exceptions above, the kernel will
> > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
>
> sigaltstack() is interesting, since we don't support tagged stacks.
We should support tagged SP with the new ABI as they'll be required for
MTE. sigaltstack() and clone() are the two syscalls that come to mind
here.
> Do we keep the ss_sp tag in the kernel, but squash it when delivering
> a signal to the alternate stack?
We don't seem to be doing any untagging, so we just just use whatever
the caller asked for. We may need a small test to confirm.
That said, on_sig_stack() probably needs some untagging as it does user
pointer arithmetics with potentially different tags.
> > Hmm. I can see the need to provide this guarantee for things like
> > set_robust_list(), but the problem is that the statement above is too broad
> > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > its address parameter into the VMA.
> >
> > So I think we need to nail this down a bit more, but I'm having a really
> > hard time coming up with some wording :(
>
> Time for some creative vagueness?
>
> We can write a statement of our overall intent, along with examples of
> a few cases where the tag should and should not be expected to emerge
> intact.
>
> There is no foolproof rule, unless we can rewrite history...
I would expect the norm to be the preservation of tags with a few
exceptions. The only ones I think where we won't preserve the tags are
mmap, mremap, brk (apart from the signal stuff already mentioned in the
current tagged-pointers.rst doc).
So I can remove this paragraph altogether and add a note in part 3 of
the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
the tag information.
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Sean Christopherson @ 2019-08-22 16:24 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <e2abc69b-74c2-64ef-e270-43d93513eaae@arm.com>
On Thu, Aug 22, 2019 at 04:46:10PM +0100, Steven Price wrote:
> On 22/08/2019 16:28, Sean Christopherson wrote:
> > On Wed, Aug 21, 2019 at 04:36:50PM +0100, Steven Price wrote:
> >> kvm_put_guest() is analogous to put_user() - it writes a single value to
> >> the guest physical address. The implementation is built upon put_user()
> >> and so it has the same single copy atomic properties.
> >
> > What you mean by "single copy atomic"? I.e. what guarantees does
> > put_user() provide that __copy_to_user() does not?
>
> Single-copy atomicity is defined by the Arm architecture[1] and I'm not
> going to try to go into the full details here, so this is a summary.
>
> For the sake of this feature what we care about is that the value
> written/read cannot be "torn". In other words if there is a read (in
> this case from another VCPU) that is racing with the write then the read
> will either get the old value or the new value. It cannot return a
> mixture. (This is of course assuming that the read is using a
> single-copy atomic safe method).
Thanks for the explanation. I assumed that's what you were referring to,
but wanted to double check.
> __copy_to_user() is implemented as a memcpy() and as such cannot provide
> single-copy atomicity in the general case (the buffer could easily be
> bigger than the architecture can guarantee).
>
> put_user() on the other hand is implemented (on arm64) as an explicit
> store instruction and therefore is guaranteed by the architecture to be
> single-copy atomic (i.e. another CPU cannot see a half-written value).
I don't think kvm_put_guest() belongs in generic code, at least not with
the current changelog explanation about it providing single-copy atomic
semantics. AFAICT, the single-copy thing is very much an arm64
implementation detail, e.g. the vast majority of 32-bit architectures,
including x86, do not provide any guarantees, and x86-64 generates more
or less the same code for put_user() and __copy_to_user() for 8-byte and
smaller accesses.
As an alternative to kvm_put_guest() entirely, is it an option to change
arm64's raw_copy_to_user() to redirect to __put_user() for sizes that are
constant at compile time and can be handled by __put_user()? That would
allow using kvm_write_guest() to update stolen time, albeit with
arguably an even bigger dependency on the uaccess implementation details.
^ permalink raw reply
* Re: [PATCH v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Dave Martin @ 2019-08-22 16:37 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, linux-mm, Dave Hansen, Andrew Morton,
Vincenzo Frascino, Will Deacon, linux-arm-kernel
In-Reply-To: <20190822155531.GB55798@arrakis.emea.arm.com>
On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> > On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > > @@ -59,6 +63,11 @@ be preserved.
> > > > The architecture prevents the use of a tagged PC, so the upper byte will
> > > > be set to a sign-extension of bit 55 on exception return.
> > > >
> > > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > > +enabled. In addition, with the exceptions above, the kernel will
> > > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
> >
> > sigaltstack() is interesting, since we don't support tagged stacks.
>
> We should support tagged SP with the new ABI as they'll be required for
> MTE. sigaltstack() and clone() are the two syscalls that come to mind
> here.
>
> > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > a signal to the alternate stack?
>
> We don't seem to be doing any untagging, so we just just use whatever
> the caller asked for. We may need a small test to confirm.
If we want to support tagged SP, then I guess we shouldn't be squashing
the tag anywhere. A test for that would be sensible to have.
> That said, on_sig_stack() probably needs some untagging as it does user
> pointer arithmetics with potentially different tags.
Good point.
> > > Hmm. I can see the need to provide this guarantee for things like
> > > set_robust_list(), but the problem is that the statement above is too broad
> > > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > > its address parameter into the VMA.
> > >
> > > So I think we need to nail this down a bit more, but I'm having a really
> > > hard time coming up with some wording :(
> >
> > Time for some creative vagueness?
> >
> > We can write a statement of our overall intent, along with examples of
> > a few cases where the tag should and should not be expected to emerge
> > intact.
> >
> > There is no foolproof rule, unless we can rewrite history...
>
> I would expect the norm to be the preservation of tags with a few
> exceptions. The only ones I think where we won't preserve the tags are
> mmap, mremap, brk (apart from the signal stuff already mentioned in the
> current tagged-pointers.rst doc).
>
> So I can remove this paragraph altogether and add a note in part 3 of
> the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> the tag information.
Deleting text is always a good idea ;)
There are other cases like (non-)propagation of the tag to si_addr
when a fault is reported via a signal, but I think we already have
appropriate wording to cover that.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v2 4/6] dt-bindings: serial: Document Freescale LINFlex UART
From: Stefan-gabriel Mirea @ 2019-08-22 17:41 UTC (permalink / raw)
To: Rob Herring
Cc: corbet@lwn.net, mark.rutland@arm.com, gregkh@linuxfoundation.org,
catalin.marinas@arm.com, will@kernel.org, shawnguo@kernel.org,
Leo Li, jslaby@suse.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Cosmin Stefan Stoica,
Larisa Ileana Grigore
In-Reply-To: <20190821211841.GA16627@bogus>
Hello Rob,
Thank you for the review.
On 8/22/2019 12:18 AM, Rob Herring wrote:
> On Fri, Aug 09, 2019 at 11:29:14AM +0000, Stefan-gabriel Mirea wrote:
>> +* Freescale Linflex UART
>
> Be consistent with the name: LINFlexD?
This was also brought up in our internal review. However, the reference
manual is also inconsistent, using LINFlexD, LINflexD, LinFlexD,
LINFlex, LINFLEX, LinFlex and Linflex. I will switch to 'LINFlexD'
everywhere, though.
>> +The LINFlexD controller implements several LIN protocol versions, as well as
>> +support for full-duplex UART communication through 8-bit and 9-bit frames. The
>> +Linflex UART driver enables operation only in UART mode.
>
> What the driver supports or not is independent of the binding.
Ok, I will remove the last sentence ("The Linflex UART driver enables
operation only in UART mode").
>> + - "fsl,s32-linflexuart" for linflex configured in uart mode which
>
> LINFlexD?
Will fix; I agree that the all lowercase version has no occurrence in
the reference manual.
>> + is compatible with the one integrated on S32V234 SoC
>
> Compatibles should be SoC specific. Is 's32' specific enough to account
> for any differences or future bugs found?
It is probably not. I will change it to "fsl,s32v234-linflexuart" (as
well as in the device tree and driver).
>> +Example:
>> +uart0:serial@40053000 {
>
> space ^
>
>> + compatible = "fsl,s32-linflexuart";
>> + reg = <0x0 0x40053000 0x0 0x1000>;
>> + interrupts = <0 59 4>;
>> + status = "disabled";
>
> Don't show status in examples.
Will fix these too.
Regards,
Stefan
^ permalink raw reply
* Wohltätigkeitsspende von 2.000.000 Millionen Euro
From: ''Tayeb Souami'' @ 2019-08-22 10:22 UTC (permalink / raw)
To: Recipients
Lieber Freund,
Ich bin Herr Tayeb Souami, New Jersey, Vereinigte Staaten von Amerika, der Mega-Gewinner von $ 315million In Mega Millions Jackpot, spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt.Ich habe den größten Teil meines Vermögens auf eine Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt.Ich habe mich freiwillig dazu entschieden, die Summe von € 2.000.000,00 an Sie als eine der ausgewählten 5 zu spenden, um meine Gewinne zu überprüfen, sehen Sie bitte meine You Tube Seite unten.
UHR MICH HIER: https://www.youtube.com/watch?v=Z6ui8ZDQ6Ks
Das ist dein Spendencode: [TS530342018]
Antworten Sie mit dem SPENDE-CODE an diese E-Mail:Tayebsouam.spende@gmail.com
Ich hoffe, Sie und Ihre Familie glücklich zu machen.
Grüße
Herr Tayeb Souami
^ permalink raw reply
* Re: [PATCH v8 1/5] mm: untag user pointers in mmap/munmap/mremap/brk
From: Andrew Morton @ 2019-08-22 23:41 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-arm-kernel, linux-mm, linux-arch,
linux-doc, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
Will Deacon, Dave Hansen, Vincenzo Frascino, Dave P Martin
In-Reply-To: <20190819162851.tncj4wpwf625ofg6@willie-the-truck>
On Mon, 19 Aug 2019 17:28:51 +0100 Will Deacon <will@kernel.org> wrote:
> On Thu, Aug 15, 2019 at 04:43:59PM +0100, Catalin Marinas wrote:
> > There isn't a good reason to differentiate between the user address
> > space layout modification syscalls and the other memory
> > permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
> > address ABI. Untag the user addresses on entry to these functions.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > mm/mmap.c | 5 +++++
> > mm/mremap.c | 6 +-----
> > 2 files changed, 6 insertions(+), 5 deletions(-)
>
> Acked-by: Will Deacon <will@kernel.org>
>
> Andrew -- please can you pick this patch up? I'll take the rest of the
> series via arm64 once we've finished discussing the wording details.
>
Sure, I grabbed the patch from the v9 series.
But please feel free to include this in the arm64 tree - I'll autodrop
my copy if this turns up in linux-next.
^ permalink raw reply
* [PATCH] docs: ftrace: clarify when tracing is disabled by the trace file
From: Peter Wu @ 2019-08-22 23:48 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Jonathan Corbet
Cc: linux-doc, linux-kernel, Alexei Starovoitov
The current text could mislead the user into believing that only read()
disables tracing. Clarify that any open() call that requests read access
disables tracing.
Link: https://lkml.kernel.org/r/CAADnVQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqXOS2WpMj=q=LdiQ@mail.gmail.com
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
---
Documentation/trace/ftrace.rst | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index f60079259669..965be5c9afb3 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -125,7 +125,8 @@ of ftrace. Here is a list of some of the key files:
This file holds the output of the trace in a human
readable format (described below). Note, tracing is temporarily
- disabled while this file is being read (opened).
+ disabled when the file is open for reading. Once all readers
+ are closed, tracing is re-enabled.
trace_pipe:
@@ -139,8 +140,9 @@ of ftrace. Here is a list of some of the key files:
will not be read again with a sequential read. The
"trace" file is static, and if the tracer is not
adding more data, it will display the same
- information every time it is read. This file will not
- disable tracing while being read.
+ information every time it is read. Unlike the
+ "trace" file, opening this file for reading will not
+ temporarily disable tracing.
trace_options:
@@ -3153,7 +3155,10 @@ different. The trace is live.
Note, reading the trace_pipe file will block until more input is
-added.
+added. This is contrary to the trace file. If any process opened
+the trace file for reading, it will actually disable tracing and
+prevent new entries from being added. The trace_file file does
+not have this limitation.
trace entries
-------------
--
2.22.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox