Re: [PATCH 14/23] userfaultfd: wake pending userfaults

On Thu, May 14, 2015 at 07:31:11PM +0200, Andrea Arcangeli wrote: > @@ -255,21 +259,23 @@ int handle_userfault(struct vm_area_struct *vma, > unsigned long address, >* through poll/read(). >*/ > __add_wait_queue(>fault_wqh, ); > - for (;;) { > -

Re: [PATCH 14/23] userfaultfd: wake pending userfaults

On Thu, Oct 22, 2015 at 03:20:15PM +0200, Andrea Arcangeli wrote: > If schedule spontaneously wakes up a task in TASK_KILLABLE state that > would be a bug in the scheduler in my view. Luckily there doesn't seem > to be such a bug, or at least we never experienced it. Well, there will be a

Re: [PATCH 14/23] userfaultfd: wake pending userfaults

On Thu, Oct 22, 2015 at 04:18:31PM +0200, Andrea Arcangeli wrote: > The risk of memory corruption is still zero no matter what happens > here, in the extremely rare case the app will get a SIGBUS or a That might still upset people, SIGBUS isn't something an app can really recover from. > I'm

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

On Fri, Oct 09, 2015 at 10:45:32AM +0200, Paolo Bonzini wrote: > So you need another smp_mb() after prepare_to_wait(). I'm not sure > if it's needed also for your original tty report, but I think it is > for https://lkml.org/lkml/2015/10/8/989 ("mei: fix waitqueue_active > without memory barrier

Re: [PATCH v2] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

On Fri, Oct 09, 2015 at 12:21:55PM +, Kosuke Tatsukawa wrote: > + * Memory barrier is required here to make sure change to > + * vcpu->async_pf.done is visible from other CPUs. This memory > + * barrier pairs with prepare_to_wait's set_current_state() That is not how memory

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote: > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: > > > > Linus, what's your preference? > > So quite frankly, is there any reason we don't just implement > native_read_msr() as just > >unsigned long long

Re: [PATCH] sched: access local runqueue directly in single_task_running

very little time > * (e.g. a polling loop) > */ > > I'll include it in my pull request. In which case: Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: single_task_running() vs. preemption warnings (was Re: [PATCH] kvm: fix preemption warnings in kvm_vcpu_block)

On Thu, Sep 17, 2015 at 01:32:55PM -0700, Tim Chen wrote: > I have no objection to change single_task_running to use > raw_smp_processor_id. The worker in mcryptd is bound to > the cpu so it has no migration/preemption issue. So it shouldn't care > which smp_processor_id version is being used.

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Wed, Sep 16, 2015 at 04:33:11PM -0700, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 01:40:30PM +0200, Paolo Bonzini wrote: > > > On 17/09/2015 10:58, Peter Zijlstra wrote: > > But the far greater problem I have with the whole virt thing is that > > you cannot use rdmsr_safe() to probe if an MSR exists at all because, as > &

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote: > > Ah, that would be good news. Andy earlier argued I could not rely on > > rdmsr_safe() faulting on unknown MSRs. If practically we can there's > > some code I can simplify :-) > > I was taking about QEMU TCG, not KVM. Just for

Re: [PATCH] Fixes: 805de8f43c20 (atomic: Replace atomic_{set,clear}_mask() usage)

ply replaces the incorrect atomic_or with atomic_andnot > > Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com> Urgh, sorry about that. Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> -- To unsubscribe from this list: send the line "unsubscribe kvm&

Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm

On Tue, Sep 15, 2015 at 02:05:14PM +0200, Christian Borntraeger wrote: > Tejun, > > > commit d59cfc09c32a2ae31f1c3bc2983a0cd79afb3f14 (sched, cgroup: replace > signal_struct->group_rwsem with a global percpu_rwsem) causes some noticably > hickups when starting several kvm guests (which libvirt

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Fri, Aug 07, 2015 at 12:57:38PM +0200, Peter Zijlstra wrote: +void __finish_swait(struct swait_queue_head *q, struct swait_queue *wait) this one has no users the __ suggests that it is locked edition. Maybe it is for the completions… Yeah, who knows, I certainly do not anymore

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Wed, Feb 25, 2015 at 10:02:50PM +0100, Sebastian Andrzej Siewior wrote: +static inline int swait_active(struct swait_queue_head *q) +{ +return !list_empty(q-task_list); In RT there was a smp_mb() which you dropped and I assume you had reasons for it. Yeah, RT didn't have a reason

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Fri, Aug 07, 2015 at 09:41:31AM -0700, Christoph Hellwig wrote: On Fri, Aug 07, 2015 at 01:14:15PM +0200, Peter Zijlstra wrote: On that, we cannot convert completions to swait. Because swait wake_all must not happen from IRQ context, and complete_all() typically is used from just

Re: Should KVM_GUEST stop depending on PARAVIRT?

On Wed, Jul 29, 2015 at 11:24:09AM +0200, Paolo Bonzini wrote: On 29/07/2015 11:19, Peter Zijlstra wrote: On Tue, Jul 28, 2015 at 05:23:22PM -0700, Andy Lutomirski wrote: PeterZ, can we fix this for real instead of relying on CONFIG_PARAVIRT=y accidentally turning all msr accesses

Re: Should KVM_GUEST stop depending on PARAVIRT?

On Tue, Jul 28, 2015 at 05:23:22PM -0700, Andy Lutomirski wrote: PeterZ, can we fix this for real instead of relying on CONFIG_PARAVIRT=y accidentally turning all msr accesses into safe accesses? We have the CPUID hypervisor bit, but I still don't fully understand the problem. So a whole

Re: [PATCH v2 3/3] sched/preempt: fix cond_resched_lock() and cond_resched_softirq()

On Wed, Jul 15, 2015 at 03:52:34PM +0300, Konstantin Khlebnikov wrote: On 15.07.2015 15:16, Eric Dumazet wrote: On Wed, 2015-07-15 at 12:52 +0300, Konstantin Khlebnikov wrote: These functions check should_resched() before unlocking spinlock/bh-enable: preempt_count always non-zero =

Re: [PATCH] signals: Generate warning when flush_signals() is called from non-kthread context

On Sat, May 02, 2015 at 09:27:49AM -0700, Linus Torvalds wrote: On Sat, May 2, 2015 at 1:30 AM, NeilBrown ne...@suse.de wrote: All the calls in md.c are in a kernel thread so safe, but I'd rather have an explicit uninterruptible, but no load-average wait Hmm. Our task state is a

Re: Non-exiting rdpmc on KVM guests?

On Tue, Apr 21, 2015 at 02:10:53PM -0700, Andy Lutomirski wrote: One question is whether we care if we leak unrelated counters to the guest. (We already leak them to unrelated user tasks, so this is hopefully not a big deal. OTOH, the API is different for guests.) Good question indeed. I

Re: Non-exiting rdpmc on KVM guests?

On Mon, Apr 20, 2015 at 05:47:23PM -0700, Andy Lutomirski wrote: I just wrote a little perf self-monitoring tool that uses rdpmc to count cycles. Performance sucks under KVM (VMX). How hard would it be to avoid rdpmc exits in cases where the host and guest pmu configurations are compatible

Re: Non-exiting rdpmc on KVM guests?

On Tue, Apr 21, 2015 at 06:32:54PM +0200, Paolo Bonzini wrote: However, if you take into account that RDPMC can also be used to read an inactive counter, and that multiple guests fight for the same host counters, it's even harder to ensure that the guest counter indices match those on the

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote: On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote: include/linux/sched.h |8 + kernel/sched/core.c| 15 + Can you please not puke over

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote: include/linux/sched.h |8 + kernel/sched/core.c| 15 + Can you please not puke over the scheduler without Acks from at least one maintainer? I complained about this

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 12:38:07PM +0200, Paolo Bonzini wrote: On 17/04/2015 12:36, Peter Zijlstra wrote: Now you make everybody pay for your crap, x86-64 paravirt or not. Keep the cost by those who need it. Please take it out, ASAP. I'll just implement the static key. Can you

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote: On 17/04/2015 12:55, Peter Zijlstra wrote: Also, it looks like you already do exactly this for other things, look at: kvm_sched_in() kvm_arch_vcpu_load() if (unlikely(vcpu-cpu != cpu) ... ) So no, I

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote: The path this notifier is called from has nothing to do with those costs. How not? The task is going to incur those costs, it's not like half a dozen extra instruction make any difference. But anyway... Its attributed to the

Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 12:09:49PM +0200, Paolo Bonzini wrote: On 17/04/2015 11:17, Peter Zijlstra wrote: On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote: On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote: include/linux/sched.h

Re: [PATCH v15 09/15] pvqspinlock: Implement simple paravirt support for the qspinlock

On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote: +void __init __pv_init_lock_hash(void) +{ + int pv_hash_size = 4 * num_possible_cpus(); + + if (pv_hash_size (1U LFSR_MIN_BITS)) + pv_hash_size = (1U LFSR_MIN_BITS); + /* +* Allocate space from bootmem

Re: [PATCH v15 09/15] pvqspinlock: Implement simple paravirt support for the qspinlock

On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote: +__visible void __pv_queue_spin_unlock(struct qspinlock *lock) +{ + struct __qspinlock *l = (void *)lock; + struct pv_node *node; + + if (likely(cmpxchg(l-locked, _Q_LOCKED_VAL, 0) == _Q_LOCKED_VAL)) + return; +

Re: [PATCH v15 09/15] pvqspinlock: Implement simple paravirt support for the qspinlock

On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote: +static void pv_wait_head(struct qspinlock *lock, struct mcs_spinlock *node) +{ + struct __qspinlock *l = (void *)lock; + struct qspinlock **lp = NULL; + struct pv_node *pn = (struct pv_node *)node; + int slow_set = false;

Re: [PATCH v15 16/16] unfair qspinlock: a queue based unfair lock

On Thu, Apr 09, 2015 at 09:16:24AM -0400, Rik van Riel wrote: On 04/09/2015 03:01 AM, Peter Zijlstra wrote: On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: For a virtual guest with the qspinlock patch, a simple unfair byte lock will be used if PV spinlock is not configured

Re: [PATCH v15 09/15] pvqspinlock: Implement simple paravirt support for the qspinlock

On Thu, Apr 09, 2015 at 08:13:27PM +0200, Peter Zijlstra wrote: On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: +#define PV_HB_PER_LINE (SMP_CACHE_BYTES / sizeof(struct pv_hash_bucket)) +static struct qspinlock **pv_hash(struct qspinlock *lock, struct pv_node *node

Re: [PATCH v15 09/15] pvqspinlock: Implement simple paravirt support for the qspinlock

On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: +++ b/kernel/locking/qspinlock_paravirt.h @@ -0,0 +1,321 @@ +#ifndef _GEN_PV_LOCK_SLOWPATH +#error do not include this file +#endif + +/* + * Implement paravirt qspinlocks; the general idea is to halt the vcpus instead + * of

Re: [PATCH v15 13/15] pvqspinlock: Only kick CPU at unlock time

On Mon, Apr 06, 2015 at 10:55:48PM -0400, Waiman Long wrote: @@ -219,24 +236,30 @@ static void pv_wait_node(struct mcs_spinlock *node) } /* + * Called after setting next-locked = 1 lock acquired. + * Check if the the CPU has been halted. If so, set the _Q_SLOW_VAL flag + * and put an

Re: [PATCH v15 13/15] pvqspinlock: Only kick CPU at unlock time

On Thu, Apr 09, 2015 at 09:57:21PM +0200, Peter Zijlstra wrote: On Mon, Apr 06, 2015 at 10:55:48PM -0400, Waiman Long wrote: @@ -219,24 +236,30 @@ static void pv_wait_node(struct mcs_spinlock *node) } /* + * Called after setting next-locked = 1 lock acquired. + * Check

Re: [PATCH v15 16/16] unfair qspinlock: a queue based unfair lock

On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: For a virtual guest with the qspinlock patch, a simple unfair byte lock will be used if PV spinlock is not configured in or the hypervisor isn't either KVM or Xen. The byte lock works fine with small guest of just a few vCPUs. On a

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Apr 02, 2015 at 09:48:34PM +0200, Peter Zijlstra wrote: @@ -158,20 +257,20 @@ static void pv_wait_head(struct qspinloc void __pv_queue_spin_unlock(struct qspinlock *lock) { struct __qspinlock *l = (void *)lock; + struct pv_hash_bucket *hb; if (xchg(l-locked, 0

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Apr 02, 2015 at 07:20:57PM +0200, Peter Zijlstra wrote: pv_wait_head(): pv_hash() /* MB as per cmpxchg */ cmpxchg(l-locked, _Q_LOCKED_VAL, _Q_SLOW_VAL); VS __pv_queue_spin_unlock(): if (xchg(l-locked, 0) != _Q_SLOW_VAL) return

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Apr 02, 2015 at 12:28:30PM -0400, Waiman Long wrote: On 04/01/2015 05:03 PM, Peter Zijlstra wrote: On Wed, Apr 01, 2015 at 03:58:58PM -0400, Waiman Long wrote: On 04/01/2015 02:48 PM, Peter Zijlstra wrote: I am sorry that I don't quite get what you mean here. My point

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Apr 01, 2015 at 12:20:30PM -0400, Waiman Long wrote: After more careful reading, I think the assumption that the presence of an unused bucket means there is no match is not true. Consider the scenario: 1. cpu 0 puts lock1 into hb[0] 2. cpu 1 puts lock2 into hb[1] 3. cpu 2 clears

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Apr 01, 2015 at 07:42:39PM +0200, Peter Zijlstra wrote: Hohumm.. time to think more I think ;-) So bear with me, I've not really pondered this well so it could be full of holes (again). After the cmpxchg(l-locked, _Q_LOCKED_VAL, _Q_SLOW_VAL) succeeds the spin_unlock() must do

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Apr 01, 2015 at 02:54:45PM -0400, Waiman Long wrote: On 04/01/2015 02:17 PM, Peter Zijlstra wrote: On Wed, Apr 01, 2015 at 07:42:39PM +0200, Peter Zijlstra wrote: Hohumm.. time to think more I think ;-) So bear with me, I've not really pondered this well so it could be full of holes

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Apr 01, 2015 at 07:12:23PM +0200, Peter Zijlstra wrote: On Wed, Apr 01, 2015 at 12:20:30PM -0400, Waiman Long wrote: After more careful reading, I think the assumption that the presence of an unused bucket means there is no match is not true. Consider the scenario: 1. cpu 0 puts

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Apr 01, 2015 at 03:58:58PM -0400, Waiman Long wrote: On 04/01/2015 02:48 PM, Peter Zijlstra wrote: I am sorry that I don't quite get what you mean here. My point is that in the hashing step, a cpu will need to scan an empty bucket to put the lock in. In the interim, an previously used

Re: [PATCH 0/9] qspinlock stuff -v15

On Mon, Mar 30, 2015 at 12:25:12PM -0400, Waiman Long wrote: I did it differently in my PV portion of the qspinlock patch. Instead of just waking up the CPU, the new lock holder will check if the new queue head has been halted. If so, it will set the slowpath flag for the halted queue head in

Re: [PATCH 0/9] qspinlock stuff -v15

On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote: Ah nice. That could be spun out as a seperate patch to optimize the existing ticket locks I presume. Yes I suppose we can do something similar for the ticket and patch in the right increment. We'd need to restructure the

Re: [PATCH 9/9] qspinlock,x86,kvm: Implement KVM support for paravirt qspinlock

On Wed, Mar 18, 2015 at 10:45:55PM -0400, Waiman Long wrote: On 03/16/2015 09:16 AM, Peter Zijlstra wrote: I do have some concern about this call site patching mechanism as the modification is not atomic. The spin_unlock() calls are in many places in the kernel. There is a possibility

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Wed, Mar 18, 2015 at 04:50:37PM -0400, Waiman Long wrote: +this_cpu_write(__pv_lock_wait, lock); We may run into the same problem of needing to have 4 queue nodes per CPU. If an interrupt happens just after the write and before the actual wait and it goes through the same

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Mar 19, 2015 at 11:12:42AM +0100, Peter Zijlstra wrote: So I was now thinking of hashing the lock pointer; let me go and quickly put something together. A little something like so; ideally we'd allocate the hashtable since NR_CPUS is kinda bloated, but it shows the idea I think

Re: [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Mar 19, 2015 at 01:25:36PM +0100, Peter Zijlstra wrote: +static struct qspinlock **pv_hash(struct qspinlock *lock) +{ + u32 hash = hash_ptr(lock, PV_LOCK_HASH_BITS); + struct pv_hash_bucket *hb, *end; + + if (!hash) + hash = 1; + + hb = __pv_lock_hash

Re: [Xen-devel] [PATCH 0/9] qspinlock stuff -v15

On Thu, Mar 19, 2015 at 06:01:34PM +, David Vrabel wrote: This seems work for me, but I've not got time to give it a more thorough testing. You can fold this into your series. Thanks! There doesn't seem to be a way to disable QUEUE_SPINLOCKS when supported by the arch, is this

[PATCH 4/9] qspinlock: Extract out code snippets for the next patch

...@linux-foundation.org Cc: Thomas Gleixner t...@linutronix.de Cc: H. Peter Anvin h...@zytor.com Cc: Rik van Riel r...@redhat.com Cc: Raghavendra K T raghavendra...@linux.vnet.ibm.com Signed-off-by: Waiman Long waiman.l...@hp.com Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Link

[PATCH 5/9] qspinlock: Optimize for smaller NR_CPUS

From: Peter Zijlstra pet...@infradead.org When we allow for a max NR_CPUS 2^14 we can optimize the pending wait-acquire and the xchg_tail() operations. By growing the pending bit to a byte, we reduce the tail to 16bit. This means we can use xchg16 for the tail part and do away with all

[PATCH 2/9] qspinlock, x86: Enable x86-64 to use queue spinlock

. Peter Anvin h...@zytor.com Cc: Rik van Riel r...@redhat.com Cc: Raghavendra K T raghavendra...@linux.vnet.ibm.com Signed-off-by: Waiman Long waiman.l...@hp.com Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Link: http://lkml.kernel.org/r/1421784755-21945-3-git-send-email-waiman.l

[PATCH 6/9] qspinlock: Use a simple write to grab the lock

: Rik van Riel r...@redhat.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Raghavendra K T raghavendra...@linux.vnet.ibm.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Signed-off-by: Waiman Long waiman.l...@hp.com Signed-off-by: Peter Zijlstra (Intel) pet

[PATCH 7/9] qspinlock: Revert to test-and-set on hypervisors

From: Peter Zijlstra pet...@infradead.org When we detect a hypervisor (!paravirt, see qspinlock paravirt support patches), revert to a simple test-and-set lock to avoid the horrors of queue preemption. Cc: Ingo Molnar mi...@redhat.com Cc: David Vrabel david.vra...@citrix.com Cc: Oleg Nesterov o

[PATCH 3/9] qspinlock: Add pending bit

From: Peter Zijlstra pet...@infradead.org Because the qspinlock needs to touch a second cacheline (the per-cpu mcs_nodes[]); add a pending bit and allow a single in-word spinner before we punt to the second cacheline. It is possible so observe the pending bit without the locked bit when the last

[PATCH 8/9] qspinlock: Generic paravirt support

to the current kvm code. We can do a single enrty because any nesting will wake the vcpu and cause the lower loop to retry. Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org --- include/asm-generic/qspinlock.h |3 kernel/locking/qspinlock.c | 69 +- kernel/locking

[PATCH 1/9] qspinlock: A simple generic 4-byte queue spinlock

...@linux.vnet.ibm.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Signed-off-by: Waiman Long waiman.l...@hp.com Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Link: http://lkml.kernel.org/r/1421784755-21945-2-git-send-email-waiman.l...@hp.com --- include/asm-generic

[PATCH 9/9] qspinlock,x86,kvm: Implement KVM support for paravirt qspinlock

. This significantly lowers the overhead of having CONFIG_PARAVIRT_SPINLOCKS enabled, even for native code. Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org --- arch/x86/Kconfig |2 - arch/x86/include/asm/paravirt.h | 28 - arch/x86/include/asm

[PATCH 0/9] qspinlock stuff -v15

Hi Waiman, As promised; here is the paravirt stuff I did during the trip to BOS last week. All the !paravirt patches are more or less the same as before (the only real change is the copyright lines in the first patch). The paravirt stuff is 'simple' and KVM only -- the Xen code was a little

Re: virtio balloon: do not call blocking ops when !TASK_RUNNING

On Thu, Feb 26, 2015 at 09:30:31AM +0100, Michael S. Tsirkin wrote: On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: Thomas Huth th...@linux.vnet.ibm.com writes: Hi all, with the recent kernel 3.19, I get a kernel warning when I start my KVM guest on s390 with virtio

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote: * Peter Zijlstra | 2015-01-21 16:07:16 [+0100]: On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote: I'm actually wondering if we should just nuke the _interruptible() version of swait. As it should only

Re: [PATCH V3] x86 spinlock: Fix memory corruption on completing completions

On Thu, Feb 12, 2015 at 05:17:27PM +0530, Raghavendra K T wrote: Paravirt spinlock clears slowpath flag after doing unlock. As explained by Linus currently it does: prev = *lock; add_smp(lock-tickets.head, TICKET_LOCK_INC); /* add_smp() is a

Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: So we have 3 choices, 1. xadd 2. continue with current approach. 3. a read before unlock and also after that. For the truly paranoid we have probe_kernel_address(), suppose the lock was in module space and the module just got

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote: I'm actually wondering if we should just nuke the _interruptible() version of swait. As it should only be all interruptible or all not interruptible, that the swait_wake() should just do the wake up regardless. In which case,

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote: I notice everywhere you have a swait_wake_interruptible() but here. Is there a reason why? IIRC, Peter wants to make swait wakeup usage homogenous. That is, you either sleep in an interruptible state, or you don't. You can't mix

Re: [PATCH v13 09/11] pvqspinlock, x86: Add para-virtualization support

On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote: arch/x86/include/asm/pvqspinlock.h| 411 + I do wonder why all this needs to live in x86.. +#ifdef CONFIG_QUEUE_SPINLOCK + +static __always_inline void pv_kick_cpu(int cpu) +{ +

Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support

On Mon, Oct 27, 2014 at 01:15:53PM -0400, Waiman Long wrote: On 10/24/2014 06:04 PM, Peter Zijlstra wrote: On Fri, Oct 24, 2014 at 04:53:27PM -0400, Waiman Long wrote: The additional register pressure may just cause a few more register moves which should be negligible in the overall

Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support

On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote: On 10/24/2014 04:54 AM, Peter Zijlstra wrote: On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote: Since enabling paravirt spinlock will disable unlock function inlining, a jump label can be added to the unlock function

Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support

On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote: +static inline void pv_init_node(struct mcs_spinlock *node) +{ + struct pv_qnode *pn = (struct pv_qnode *)node; + + BUILD_BUG_ON(sizeof(struct pv_qnode) 5*sizeof(struct mcs_spinlock)); + + if (!pv_enabled()) +

Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support

On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote: Since enabling paravirt spinlock will disable unlock function inlining, a jump label can be added to the unlock function without adding patch sites all over the kernel. But you don't have to. My patches allowed for the inline to

Re: [PATCH v12 00/11] qspinlock: a 4-byte queue spinlock with PV support

On Thu, Oct 16, 2014 at 02:10:29PM -0400, Waiman Long wrote: v11-v12: - Based on PeterZ's version of the qspinlock patch (https://lkml.org/lkml/2014/6/15/63). - Incorporated many of the review comments from Konrad Wilk and Paolo Bonzini. - The pvqspinlock code is largely from my

Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support

On Fri, Oct 24, 2014 at 04:53:27PM -0400, Waiman Long wrote: The additional register pressure may just cause a few more register moves which should be negligible in the overall performance . The additional icache pressure, however, may have some impact on performance. I was trying to balance

Re: [PATCH 1/4] mm: gup: add FOLL_TRIED

On Wed, Oct 01, 2014 at 10:56:34AM +0200, Andrea Arcangeli wrote: From: Andres Lagar-Cavilla andre...@google.com This needs a changelog Reviewed-by: Radim Krčmář rkrc...@redhat.com Signed-off-by: Andres Lagar-Cavilla andre...@google.com Signed-off-by: Andrea Arcangeli aarca...@redhat.com

Re: [PATCH 2/4] mm: gup: add get_user_pages_locked and get_user_pages_unlocked

On Wed, Oct 01, 2014 at 10:56:35AM +0200, Andrea Arcangeli wrote: +static inline long __get_user_pages_locked(struct task_struct *tsk, +struct mm_struct *mm, +unsigned long start, +

Re: [PATCH 2/4] mm: gup: add get_user_pages_locked and get_user_pages_unlocked

On Wed, Oct 01, 2014 at 10:56:35AM +0200, Andrea Arcangeli wrote: +static inline long __get_user_pages_locked(struct task_struct *tsk, +struct mm_struct *mm, +unsigned long start, +

Re: [PATCH 3/4] mm: gup: use get_user_pages_fast and get_user_pages_unlocked

On Wed, Oct 01, 2014 at 10:56:36AM +0200, Andrea Arcangeli wrote: Just an optimization. Does it make sense to split the thing in two? One where you apply _unlocked and then one where you apply _fast? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to

Re: RFC: get_user_pages_locked|unlocked to leverage VM_FAULT_RETRY

On Thu, Oct 02, 2014 at 02:31:17PM +0200, Andrea Arcangeli wrote: On Wed, Oct 01, 2014 at 05:36:11PM +0200, Peter Zijlstra wrote: For all these and the other _fast() users, is there an actual limit to the nr_pages passed in? Because we used to have the 64 pages limit from DIO, but without

Re: RFC: get_user_pages_locked|unlocked to leverage VM_FAULT_RETRY

On Thu, Oct 02, 2014 at 02:50:52PM +0200, Peter Zijlstra wrote: On Thu, Oct 02, 2014 at 02:31:17PM +0200, Andrea Arcangeli wrote: On Wed, Oct 01, 2014 at 05:36:11PM +0200, Peter Zijlstra wrote: For all these and the other _fast() users, is there an actual limit to the nr_pages passed

Re: RFC: get_user_pages_locked|unlocked to leverage VM_FAULT_RETRY

On Fri, Sep 26, 2014 at 07:25:35PM +0200, Andrea Arcangeli wrote: diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c index bb48a57..12ea7c3 100644 --- a/drivers/dma/iovlock.c +++ b/drivers/dma/iovlock.c @@ -95,17 +95,11 @@ struct dma_pinned_list *dma_pin_iovec_pages(struct iovec

Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields

On Wed, Sep 17, 2014 at 03:54:12PM +0300, Nadav Amit wrote: Adding structs that reflect various cpuid fields in x86 architecture. Structs were added only for functions that are not pure bitmaps. Signed-off-by: Nadav Amit na...@cs.technion.ac.il --- arch/x86/include/asm/cpuid_def.h | 163

Re: [PATCH 0/3] x86: structs for cpuid info in x86

On Wed, Sep 17, 2014 at 02:37:10PM +0200, Ingo Molnar wrote: If hpa, tglx or Linus objects I'll yield to that objection though. Opinions, objections? They generally look fine to me. I appreciate the bitfields for readability. I often use the same when having to deal with hardware bitfields.

Re: [PATCH V6 1/2] perf ignore LBR and extra_rsp

: a...@firstfloor.org Signed-off-by: Kan Liang kan.li...@intel.com Signed-off-by: Peter Zijlstra pet...@infradead.org Link: http://lkml.kernel.org/r/1405365957-20202-1-git-send-email-kan.li...@intel.com --- arch/x86/kernel/cpu/perf_event.c |3 + arch/x86/kernel/cpu/perf_event.h | 12

Re: [PATCH V6 1/2] perf ignore LBR and extra_rsp

On Tue, Jul 15, 2014 at 03:32:36PM +, Liang, Kan wrote: Since nobody ever treats EVENT_EXTRA_END as an actual event, the value of .extra_msr_access is irrelevant, this leaves the only 'possible' value 'true' and we can delete all those changes. Right. Which, combined with

Re: [PATCH V5 1/2] perf ignore LBR and extra_regs

On Thu, Jul 10, 2014 at 03:59:43AM -0700, kan.li...@intel.com wrote: From: Kan Liang kan.li...@intel.com x86, perf: Protect LBR and extra_regs against KVM lying With -cpu host, KVM reports LBR and extra_regs support, if the host has support. When the guest perf driver tries to access LBR

Re: [PATCH V5 1/2] perf ignore LBR and extra_regs

On Thu, Jul 10, 2014 at 03:59:43AM -0700, kan.li...@intel.com wrote: +/* + * Under certain circumstances, access certain MSR may cause #GP. + * The function tests if the input MSR can be safely accessed. + */ +static inline bool check_msr(unsigned long msr) +{ + u64 val_old, val_new,

Re: [PATCH V5 1/2] perf ignore LBR and extra_regs

On Mon, Jul 14, 2014 at 01:55:03PM +0200, Paolo Bonzini wrote: Il 10/07/2014 12:59, kan.li...@intel.com ha scritto: From: Kan Liang kan.li...@intel.com x86, perf: Protect LBR and extra_regs against KVM lying With -cpu host, KVM reports LBR and extra_regs support, if the host has support.

Re: [PATCH V5 1/2] perf ignore LBR and extra_regs

On Mon, Jul 14, 2014 at 02:40:33PM +0200, Paolo Bonzini wrote: Hmmm, I thought rdmsr_safe was going to return zero, but it just returns whatever happened to be in edx:eax which maybe should also be fixed. Kan Liang, what happens if CONFIG_PARAVIRT=y? Do you get garbage or just no events

Re: [PATCH V5 1/2] perf ignore LBR and extra_regs

so once more; and then I'm going to route your emails to /dev/null, wrap text at 78 chars. On Mon, Jul 14, 2014 at 02:28:36PM +, Liang, Kan wrote: +++ b/arch/x86/kernel/cpu/perf_event.h @@ -464,6 +464,12 @@ struct x86_pmu { */ struct extra_reg *extra_regs; unsigned int

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

/me reminds you of 78 char text wrap. On Wed, Jul 09, 2014 at 07:32:09PM +, Liang, Kan wrote: Sure; but what I meant was, check_msr() is broken when ran on such a kernel. You need to fix check_msr() to return failure on these 'ignored' MSRs, after all they don't function as expected,

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 2bdfbff..f0e8022 100644 --- a/arch/x86/kernel/cpu/perf_event.c +++ b/arch/x86/kernel/cpu/perf_event.c @@ -118,6 +118,9 @@ static int

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 2bdfbff..f0e8022 100644 --- a/arch/x86/kernel/cpu/perf_event.c +++ b/arch/x86/kernel/cpu/perf_event.c @@ -118,6 +118,9 @@ static int

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: + /* + * Access LBR MSR may cause #GP under certain circumstances. + * E.g. KVM doesn't support LBR MSR + * Check all LBT MSR here. + * Disable LBR access if any LBR MSRs can not be accessed. +

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: --- a/arch/x86/kernel/cpu/perf_event.h +++ b/arch/x86/kernel/cpu/perf_event.h @@ -464,6 +464,12 @@ struct x86_pmu { */ struct extra_reg *extra_regs; unsigned int er_flags; + /* + * EXTRA REG

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: +/* + * Under certain circumstances, access certain MSR may cause #GP. + * The function tests if the input MSR can be safely accessed. + */ +static inline bool check_msr(unsigned long msr) +{ + u64 value; + + if

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Wed, Jul 09, 2014 at 02:32:28PM +, Liang, Kan wrote: On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote: +/* + * Under certain circumstances, access certain MSR may cause #GP. + * The function tests if the input MSR can be safely accessed. + */ +static

Re: [PATCH V4 1/2] perf ignore LBR and extra_regs.

On Wed, Jul 09, 2014 at 03:43:45PM +, Liang, Kan wrote: -Original Message- From: Peter Zijlstra [mailto:pet...@infradead.org] Sent: Wednesday, July 09, 2014 10:58 AM To: Liang, Kan Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org Subject: Re

  1   2   3   4   5   6   >