[PATCH] x86/platform/uv: Include clocksource.h for clocksource_touch_watchdog()

Thanks, Ingo > >From d51953b0873358d13b189996e6976dfa12a9b59d Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mi...@kernel.org> Date: Fri, 11 Dec 2015 09:01:30 +0100 Subject: [PATCH] x86/platform/uv: Include clocksource.h for clocksource_touch_watchdog() This build failure triggers on 64-bit allmo

Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

* Paolo Bonzini wrote: > > > On 10/12/2015 00:12, Andy Lutomirski wrote: > > From: Andy Lutomirski > > > > The pvclock vdso code was too abstracted to understand easily and > > excessively paranoid. Simplify it for a huge speedup. > > > > This

Re: [GIT PULL 0/5] perf/core improvements and fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 43e41adc9e8c36545888d78fed2ef8d102a938dc: > > perf record: Add ability to sample call branches (2015-10-20 10:30:55 +0200) > > are

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

* Andy Lutomirski wrote: > > These could still be open coded in an inlined fashion, like the scheduler > > usage. > > We could have a raw_rdmsr for those. > > OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is > worth the effort. This isn't a

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

* Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote: > > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar <mi...@kernel.org> wrote: > > > > > > Linus, what's your preference? > > > >

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

* Denys Vlasenko <dvlas...@redhat.com> wrote: > On 09/28/2015 09:58 AM, Ingo Molnar wrote: > > > > * Denys Vlasenko <dvlas...@redhat.com> wrote: > > > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote: > >>> NAK. We really should map the GDT

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

* Denys Vlasenko wrote: > On 09/26/2015 09:50 PM, H. Peter Anvin wrote: > > NAK. We really should map the GDT read-only on all 64 bit systems, > > since we can't hide the address from SLDT. Same with the IDT. > > Sorry, I don't understand your point. So the problem is

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

* Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar <mi...@kernel.org> wrote: > > > > Linus, what's your preference? > > So quite frankly, is there any reason we don't just implement > native_read_msr(

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

* Andy Lutomirski wrote: > On Sep 20, 2015 5:15 PM, "Linus Torvalds" > wrote: > > > > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote: > > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > > >

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

* Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ON_ONCE and a return of poisoned values (in the > RDMSR case). We still write a pr_info entry unconditionally for > debugging. > > To be clear, this type of

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

* 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 bugs. In particular,

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

* Andy Lutomirski <l...@amacapital.net> wrote: > On Thu, Sep 17, 2015 at 12:19 AM, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Andy Lutomirski <l...@kernel.org> wrote: > > > >> Setting CONFIG_PARAVIRT=y has an unintended side effect: it si

[tip:x86/asm] x86/asm/tsc: Add rdtscll() merge helper

Commit-ID: 99770737ca7e3ebc14e66460a69b7032de9421e1 Gitweb: http://git.kernel.org/tip/99770737ca7e3ebc14e66460a69b7032de9421e1 Author: Ingo Molnar mi...@kernel.org AuthorDate: Fri, 21 Aug 2015 08:33:53 +0200 Committer: Ingo Molnar mi...@kernel.org CommitDate: Fri, 21 Aug 2015 08:35:42

Re: [PATCH] kvm:Return -ENOMEM directly for the function, kvm_create_lapic

* Nicholas Krause xerofo...@gmail.com wrote: In order to make code paths easier to read in the function, kvm_create_lapic we return -ENOMEM when unable to allocate memory for a kvm_lapic structure pointer directly. This makes the code easier to read and cleaner then jumping to a goto label

Re: [PATCH v3 1/2] perf/kvm: Port perf kvm to powerpc

* Hemant Kumar hem...@linux.vnet.ibm.com wrote: # perf kvm stat report -p 60515 Analyze events for pid(s) 60515, all VCPUs: VM-EXITSamples Samples% Time%Min Time Max Time Avg time H_DATA_STORAGE 500635.30% 0.13% 1.94us

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

* Christian Borntraeger borntrae...@de.ibm.com wrote: By all means! You'll first need to cherry-pick these commits: 927609d622a3 kernel: tighten rules for ACCESS ONCE c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE dd36929720f4 kernel: make READ_ONCE() valid on const

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

* Greg KH gre...@linuxfoundation.org wrote: It's: d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock Yes, This is the original patch. Please note I have taken out the READ_ONCE changes from the original patch to avoid build warnings mentioned below. (Those

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

* Greg KH gre...@linuxfoundation.org wrote: On Tue, Feb 24, 2015 at 02:54:59PM +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,

Re: typo of the comment

* john_gong john_g...@yeah.net wrote: hi Paolo, i find a typo of the comment. From 09d5df31f0930e8e3eb10ad60a3debc53d6ce992 Mon Sep 17 00:00:00 2001 From: john_gong john_g...@yeah.net Date: Fri, 7 Nov 2014 07:32:17 +0800 Subject: [PATCH] modify a typo of the comment Signed-off-by:

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

* Nadav Amit nadav.a...@gmail.com wrote: On 9/16/14 4:22 PM, Ingo Molnar wrote: * Nadav Amit na...@cs.technion.ac.il wrote: The code that deals with x86 cpuid fields is hard to follow since it performs many bit operations and does not refer to cpuid field explicitly

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

* Nadav Amit na...@cs.technion.ac.il wrote: The code that deals with x86 cpuid fields is hard to follow since it performs many bit operations and does not refer to cpuid field explicitly. To eliminate the need of openning a spec whenever dealing with cpuid fields, this patch-set introduces

Re: [PATCH 2/5] softlockup: make detector be aware of task switch of processes hogging cpu

* Don Zickus dzic...@redhat.com wrote: From: chai wen chaiw.f...@cn.fujitsu.com For now, soft lockup detector warns once for each case of process softlockup. But the thread 'watchdog/n' may not always get the cpu at the time slot between the task switch of two processes hogging that cpu

Re: [PATCH 3/5] watchdog: fix print-once on enable

* Don Zickus dzic...@redhat.com wrote: --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -522,6 +522,9 @@ static void watchdog_nmi_disable(unsigned int cpu) /* should be in cleanup, but blocks oprofile */ perf_event_release_kernel(event); } + if (cpu

Re: [PATCH 4/5] watchdog: control hard lockup detection default

* Don Zickus dzic...@redhat.com wrote: The running kernel still has the ability to enable/disable at any time with /proc/sys/kernel/nmi_watchdog us usual. However even when the default has been overridden /proc/sys/kernel/nmi_watchdog will initially show '1'. To truly turn it on one must

Re: [PATCH 3/5] watchdog: fix print-once on enable

* Don Zickus dzic...@redhat.com wrote: From: Ulrich Obergfell uober...@redhat.com This patch avoids printing the message 'enabled on all CPUs, ...' multiple times. For example, the issue can occur in the following scenario: 1) watchdog_nmi_enable() fails to enable PMU counters and sets

Re: [PATCH 4/5] watchdog: control hard lockup detection default

* Don Zickus dzic...@redhat.com wrote: From: Ulrich Obergfell uober...@redhat.com In some cases we don't want hard lockup detection enabled by default. An example is when running as a guest. Introduce watchdog_enable_hardlockup_detector(bool) So, the name

Re: [PATCH 2/5] softlockup: make detector be aware of task switch of processes hogging cpu

* Don Zickus dzic...@redhat.com wrote: On Mon, Aug 18, 2014 at 11:03:19AM +0200, Ingo Molnar wrote: * Don Zickus dzic...@redhat.com wrote: From: chai wen chaiw.f...@cn.fujitsu.com For now, soft lockup detector warns once for each case of process softlockup. But the thread

Re: [PATCH 4/5] watchdog: control hard lockup detection default

* Don Zickus dzic...@redhat.com wrote: On Mon, Aug 18, 2014 at 11:16:44AM +0200, Ingo Molnar wrote: * Don Zickus dzic...@redhat.com wrote: The running kernel still has the ability to enable/disable at any time with /proc/sys/kernel/nmi_watchdog us usual. However even when

Re: [PATCH 4/5] watchdog: control hard lockup detection default

* Don Zickus dzic...@redhat.com wrote: 2) The softlockup and hardlockup detection control variables should be in separate flags, inside and outside the kernel - they (should) not relate to each other. They did because years ago I thought we wanted to keep them as one entity

Re: [PATCH 2/5] softlockup: make detector be aware of task switch of processes hogging cpu

* Don Zickus dzic...@redhat.com wrote: So I agree with the motivation of this improvement, but is this implementation namespace-safe? What namespace are you worried about colliding with? I thought softlockup_ would provide the safety?? Maybe I am missing something

Re: [PATCH v9 05/19] qspinlock: Optimize for smaller NR_CPUS

* Waiman Long waiman.l...@hp.com wrote: On 04/18/2014 03:46 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: On 04/17/2014 11:58 AM, Peter Zijlstra wrote: On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: +static __always_inline void +clear_pending_set_locked

Re: [PATCH v9 03/19] qspinlock: Add pending bit

* Waiman Long waiman.l...@hp.com wrote: Because the qspinlock needs to touch a second cacheline; add a pending bit and allow a single in-word spinner before we punt to the second cacheline. Signed-off-by: Peter Zijlstra pet...@infradead.org Signed-off-by: Waiman Long waiman.l...@hp.com

Re: [PATCH v9 05/19] qspinlock: Optimize for smaller NR_CPUS

* Waiman Long waiman.l...@hp.com wrote: On 04/17/2014 11:58 AM, Peter Zijlstra wrote: On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: +static __always_inline void +clear_pending_set_locked(struct qspinlock *lock, u32 val) +{ + struct __qspinlock *l = (void *)lock; + +

Re: [PATCH v8 01/10] qspinlock: A generic 4-byte queue spinlock implementation

* Waiman Long waiman.l...@hp.com wrote: On 04/04/2014 09:00 AM, Peter Zijlstra wrote: So I'm just not ever going to pick up this patch; I spend a week trying to reverse engineer this; I posted a 7 patch series creating the equivalent, but in a gradual and readable fashion:

Re: [PATCH v8 01/10] qspinlock: A generic 4-byte queue spinlock implementation

* Waiman Long waiman.l...@hp.com wrote: On 04/04/2014 12:57 PM, Konrad Rzeszutek Wilk wrote: On Fri, Apr 04, 2014 at 03:00:12PM +0200, Peter Zijlstra wrote: So I'm just not ever going to pick up this patch; I spend a week trying to reverse engineer this; I posted a 7 patch series creating

Re: [GIT PULL] tree-wide: clean up no longer required #include linux/init.h

* Paul Gortmaker paul.gortma...@windriver.com wrote: On Feb 4, 2014 3:52 PM, Paul Gortmaker paul.gortma...@windriver.com wrote: We've had this in linux-next for 2+ weeks (thanks Stephen!) as a linux-stable like queue of patches, and as can be seen here:

Re: [GIT PULL] tree-wide: clean up no longer required #include linux/init.h

* Stephen Rothwell s...@canb.auug.org.au wrote: Hi Ingo, On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar mi...@kernel.org wrote: So, if you meant Linus to pull it, you probably want to cite a real Git URI along the lines of: git://git.kernel.org/pub/scm/linux/kernel/git/paulg

Re: [PATCH RESEND V13 14/14] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

* H. Peter Anvin h...@zytor.com wrote: Raghavendra... Even with this latest patch this branch is broken: :(.discard+0x6108): multiple definition of `__pcpu_unique_lock_waiting' arch/x86/xen/built-in.o:(.discard+0x23): first defined here CC drivers/firmware/google/gsmi.o

Re: [PATCH RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

* Gleb Natapov g...@redhat.com wrote: On Fri, Aug 02, 2013 at 11:25:39AM +0200, Ingo Molnar wrote: Ingo, Do you have any concerns reg this series? please let me know if this looks good now to you. I'm inclined to NAK it for excessive quotation - who knows how many people

Re: [PATCH RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

* Gleb Natapov g...@redhat.com wrote: On Mon, Aug 05, 2013 at 11:46:03AM +0200, Ingo Molnar wrote: Acked-by: Ingo Molnar mi...@kernel.org I guess you'd want to carry this in the KVM tree or so - maybe in a separate branch because it changes Xen as well? It changes KVM host

Re: [PATCH RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: On 08/01/2013 02:34 PM, Raghavendra K T wrote: On 08/01/2013 01:15 PM, Gleb Natapov wrote: Shall I consider this as an ack for kvm part? For everything except 18/18. For that I still want to see numbers. But 18/18 is pretty

Re: [PATCH RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: On 07/31/2013 11:54 AM, Gleb Natapov wrote: On Tue, Jul 30, 2013 at 10:13:12PM +0530, Raghavendra K T wrote: On 07/25/2013 03:08 PM, Raghavendra K T wrote: On 07/25/2013 02:45 PM, Gleb Natapov wrote: On Thu, Jul 25, 2013 at

Re: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel

* Borislav Petkov b...@alien8.de wrote: From: Borislav Petkov b...@suse.de Date: Tue, 16 Apr 2013 18:24:34 +0200 Subject: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel This is pretty useful for the case where people want to boot the resulting kernel in qemu/kvm. Instead of

Re: [PATCH v8 2/7] KVM: VMX: Register a new IPI for posted interrupt

* Gleb Natapov g...@redhat.com wrote: On Mon, Apr 08, 2013 at 10:23:17PM +0800, Yang Zhang wrote: From: Yang Zhang yang.z.zh...@intel.com Posted Interrupt feature requires a special IPI to deliver posted interrupt to guest. And it should has a high priority so the interrupt will not be

Re: [PATCH v5 2/5] KVM: VMX: Register a new IPI for posted interrupt

* Yang Zhang yang.z.zh...@intel.com wrote: diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c index 6e03b0d..2329a54 100644 --- a/arch/x86/kernel/irqinit.c +++ b/arch/x86/kernel/irqinit.c @@ -205,6 +205,10 @@ static void __init apic_intr_init(void) /* IPI for X86

Re: [PATCH v5 2/5] KVM: VMX: Register a new IPI for posted interrupt

* Gleb Natapov g...@redhat.com wrote: On Fri, Mar 08, 2013 at 02:26:25PM +0100, Ingo Molnar wrote: * Yang Zhang yang.z.zh...@intel.com wrote: diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c index 6e03b0d..2329a54 100644 --- a/arch/x86/kernel/irqinit.c

Re: [PATCH v5 2/5] KVM: VMX: Register a new IPI for posted interrupt

* Gleb Natapov g...@redhat.com wrote: On Fri, Mar 08, 2013 at 03:05:45PM +0100, Ingo Molnar wrote: * Gleb Natapov g...@redhat.com wrote: On Fri, Mar 08, 2013 at 02:26:25PM +0100, Ingo Molnar wrote: * Yang Zhang yang.z.zh...@intel.com wrote: diff --git a/arch/x86

Re: [PATCH V3 RESEND RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: * Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]: * Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: From: Peter Zijlstra pet...@infradead.org In case of undercomitted scenarios, especially in large

Re: [PATCH V3 RESEND RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: On 01/25/2013 04:17 PM, Ingo Molnar wrote: * Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: * Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]: * Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: From

Re: [PATCH V3 RESEND RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task

; + } Looks good to me in principle. Would be nice to get more consistent benchmark numbers. Once those are unambiguously showing that this is a win: Acked-by: Ingo Molnar mi...@kernel.org Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body

Re: [PATCH] x86, add hypervisor name to dump_stack() [v2]

...@redhat.com Cc: Marcelo Tostatti mtosa...@redhat.com Cc: Ingo Molnar mi...@redhat.com Cc: kvm@vger.kernel.org Cc: x...@kernel.org [v2]: Modifications suggested by Ingo and added changes for similar output from process.c --- arch/x86/kernel/dumpstack.c | 11 ++- arch/x86

Re: [RFC 2/3] lockdep: be nice about compiling from userspace

* Sasha Levin sasha.le...@oracle.com wrote: We can rather easily make lockdep work from userspace, although 3 issues remain which I'm not sure about: - Kernel naming - we can just wrap init_utsname() to return kvmtool related utsname, is that what we want though? - static_obj() - I

Re: [RFC 2/3] lockdep: be nice about compiling from userspace

* Sasha Levin sasha.le...@oracle.com wrote: On 10/25/2012 04:05 AM, Ingo Molnar wrote: * Sasha Levin sasha.le...@oracle.com wrote: We can rather easily make lockdep work from userspace, although 3 issues remain which I'm not sure about: - Kernel naming - we can just wrap

Re: [PATCH] x86, add hypervisor name to dump_stack()

alex.william...@redhat.com Cc: Marcelo Tostatti mtosa...@redhat.com Cc: Ingo Molnar mi...@redhat.com Cc: kvm@vger.kernel.org Cc: x...@kernel.org --- arch/x86/kernel/dumpstack.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel

Re: [PATCH 1/2] kvm tools: Export DISPLAY ENV as our default host ip address

* Pekka Enberg penb...@kernel.org wrote: On 08/24/2012 02:29 PM, Asias He wrote: It is useful to run a X program in guest and display it on host. 1) Make host's x server listen to localhost:6000 host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \

Re: [PATCH 5/7] kvm tools: enable LTO

* Pekka Enberg penb...@kernel.org wrote: On Thu, Aug 30, 2012 at 10:36 AM, Sasha Levin levinsasha...@gmail.com wrote: Build with -flto set, which should enable link-time-optimizations. I'm not sure if it provides a significant performance increase, but it's probably just worth it for

Re: [PATCH 1/3] apic: add apic_set_eoi_write for PV use

**drv; + + for (drv = __apicdrivers; drv __apicdrivers_end; drv++) { + /* Should happen once for each apic */ + WARN_ON((*drv)-eoi_write == eoi_write); + (*drv)-eoi_write = eoi_write; + } +} + ok, it's better this way. Acked-by: Ingo Molnar mi

Re: [PATCH RFC V2 2/2] kvm PLE handler: Choose better candidate for directed yield

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1595,6 +1595,9 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me) continue; if (waitqueue_active(vcpu-wq))

Re: [PATCH] apic: fix kvm build on UP without IOAPIC

* Michael S. Tsirkin m...@redhat.com wrote: On Fri, Jul 06, 2012 at 04:12:23PM +0200, Ingo Molnar wrote: * Marcelo Tosatti mtosa...@redhat.com wrote: On Fri, Jul 06, 2012 at 01:13:14PM +0200, Ingo Molnar wrote: * H. Peter Anvin h...@zytor.com wrote: On 07/01/2012

Re: [PATCH] apic: fix kvm build on UP without IOAPIC

* H. Peter Anvin h...@zytor.com wrote: On 07/01/2012 08:05 AM, Michael S. Tsirkin wrote: On UP i386, when APIC is disabled # CONFIG_X86_UP_APIC is not set # CONFIG_PCI_IOAPIC is not set code looking at apicdrivers never has any effect but it still gets compiled in. In particular, this

Re: [PATCH] apic: fix kvm build on UP without IOAPIC

* Marcelo Tosatti mtosa...@redhat.com wrote: On Fri, Jul 06, 2012 at 01:13:14PM +0200, Ingo Molnar wrote: * H. Peter Anvin h...@zytor.com wrote: On 07/01/2012 08:05 AM, Michael S. Tsirkin wrote: On UP i386, when APIC is disabled # CONFIG_X86_UP_APIC is not set

Re: [PATCH] kvm: optimize ISR lookups

* Avi Kivity a...@redhat.com wrote: On 05/22/2012 02:01 AM, Thomas Gleixner wrote: Others are not my fault :) Seriously, if Avi/Marcelo want to rewrite the ISR emulation Interesting POV, really. Did you ever notice that the kernel is a collaborative effort and not

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

* Takuya Yoshikawa takuya.yoshik...@gmail.com wrote: Replaced Ingo's address with kernel.org one, On Thu, 03 May 2012 17:47:30 +0200 Peter Zijlstra pet...@infradead.org wrote: On Thu, 2012-05-03 at 22:00 +0900, Takuya Yoshikawa wrote: But as I could not see why spin_needbreak() was

Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks

* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM.(targeted for 3.5 window) Note: This needs debugfs changes

Re: [PATCH RFC 0/5] apic: eoi optimization support

* Michael S. Tsirkin m...@redhat.com wrote: I'm looking at reducing the interrupt overhead for virtualized guests: some workloads spend a large part of their time processing interrupts. This patchset supplies infrastructure to reduce the IRQ ack overhead on x86: the idea is to add an

Re: [PATCH RFC 0/5] apic: eoi optimization support

* Michael S. Tsirkin m...@redhat.com wrote: On Mon, May 07, 2012 at 12:35:12PM +0200, Ingo Molnar wrote: Michael S. Tsirkin (5): apic: fix typo EIO_ACK - EOI_ACK and document apic: use symbolic APIC_EOI_ACK x86: add apic-eoi_write callback x86: eoi micro-optimization

Re: [PATCH RFC 0/5] apic: eoi optimization support

* Avi Kivity a...@redhat.com wrote: On 05/07/2012 02:40 PM, Ingo Molnar wrote: No objections from the x86 side. Is kvm.git a good tree to merge this through? Fine to me, but I haven't checked how widely it conflicts with existing bits: by the looks of it most

Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks

* Avi Kivity a...@redhat.com wrote: PS: Nikunj had experimented that pv-flush tlb + paravirt-spinlock is a win on PLE where only one of them alone could not prove the benefit. I'd like to see those numbers, then. Ingo, please hold on the kvm-specific patches, meanwhile. I'll hold

Re: [PATCH RFC V6 0/11] Paravirtualized ticketlocks

* Andi Kleen a...@firstfloor.org wrote: Care to back that up with numbers and proper trace evidence instead of handwaving? E.g. my plumbers presentations on lock and mm scalability from last year has some graphs that show this very clearly, plus some additional data on the mutexes.

Re: [GIT PULL] KVM updates for the 3.4 merge window

* Avi Kivity a...@redhat.com wrote: Say a fix comes in which needs to be mainlined during -rc. So I put it in some other branch, to be sent off to Linus in a few days after maturing a little. Meanwhile developers see an incomplete tree, since that patch is not in it. Once Linus

Re: [PATCH v5 0/3] KVM: perf: kvm events analysis tool

* Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: The output example is following: #./perf kvm-events report --event mmio --vcpu 3 So we already have 'perf kvm': usage: perf kvm [options] {top|record|report|diff|buildid-list} which is a sub-namespace for all things KVM

Re: [PATCH v5 0/3] KVM: perf: kvm events analysis tool

* Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: Thanks for your review, Ingo! On 03/06/2012 05:07 PM, Ingo Molnar wrote: So, your new tool has a similar workflow to: perf kvm record perf kvm report but differs from it in terms of events used and in terms

[VT-d reboot problems] Re: [PATCH] x86 / reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot

(added KVM folks to the Cc:) * Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Ping^2 Bastien On Mon, Jan 23, 2012 at 11:28 AM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Mon, Jan 16, 2012 at 8:21 PM, H. Peter Anvin h...@zytor.com wrote: On 01/16/2012 03:27 AM,

Re: [PATCH] kvm tools: Use assert() helper to check a variable value

* Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Dec 19, 2011 at 09:13:28AM +0200, Pekka Enberg wrote: - BUILD_BUG_ON(i E820_X_MAX); + assert(i = E820_X_MAX); We should use BUG_ON() like tools/perf does. We dont have it yet. So I'll introduce this helper later, but note

Re: [PATCH] kvm tools: Use assert() helper to check a variable value

* Cyrill Gorcunov gorcu...@gmail.com wrote: +# +#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) +#define BUG_ON(condition)assert(!(condition)) Just a sidenote, the patch is fine but the above will result in weird double negated assertion messages. it's

Re: [PATCH] kvm tools: Use assert() helper to check a variable value

* Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Dec 19, 2011 at 11:40:09AM +0100, Ingo Molnar wrote: GDB will catch that signal. Yeah, good point! Pekka, drop this patch please, I'll make new one at evening. Patch is good as-is IMO - assert() was used before so it's

Re: [PATCH] kvm tools: Fix 'make kvmconfig'

* Sasha Levin levinsasha...@gmail.com wrote: Set features which depend on the config we select to make 'make kvmconfig' non-interactive. Signed-off-by: Sasha Levin levinsasha...@gmail.com Acked-by: Ingo Molnar mi...@elte.hu Thanks, Ingo -- To unsubscribe from this list: send

Re: [PATCH] kvm tools: mmap guest kernel instead of reading it into memory

* Sasha Levin levinsasha...@gmail.com wrote: + kvm-bz_start = mmap(NULL, kvm-bz_len, PROT_READ | PROT_WRITE, + MAP_PRIVATE, kvm-bz_fd, setup_end); + /* NOP everything before the kernel start */ + memset(kvm-bz_start, 0x90, setup_size - setup_end);

Re: [PATCH] kvm tools: Fix serial port probing

* Pekka Enberg penb...@kernel.org wrote:                        dev-ier        = ioport__read8(data) 0x3f; +                       kvm__irq_line(kvm, dev-irq, dev-ier?1:0);                        break;                case UART_LCR:                        dev-lcr        =

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: [...] I haven't looked closely at Matt's patches, but it should be possible to use [un]signed long long for the u64/s64 types, I would think. In tools/kvm/ we are using our own u64/s64 definitions, not glibc's, so i think it should be fine -

Re: [PATCH] kvm tools: Add 'kvm nmi' command

* Sasha Levin levinsasha...@gmail.com wrote: This patch adds a 'kvm nmi' command which can be used to trigger NMIs in guests. Mostly useful for debugging purposes. Could we make this something like 'kvm debug nmi'? We already have some debug functionality, right? Those should be

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: On 08/12/11 04:14, Pekka Enberg wrote: On Wed, 7 Dec 2011, Ingo Molnar wrote: * Matt Evans m...@ozlabs.org wrote: [...] I haven't looked closely at Matt's patches, but it should be possible to use [un]signed long long for the u64/s64 types

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: Since tools/kvm/include/linux/types.h only requires __u32, __u64 et al from asm/types.h, wouldn't it be most straightforward to just #include asm-generic/int-ll64.h? This avoids #define __KERNEL__ breaking other includes brought into userland, avoids

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: [...] I haven't looked closely at Matt's patches, but it should be possible to use [un]signed long long for the u64/s64 types, I would think. In tools/kvm/ we are using our own u64/s64 definitions, not glibc's, so i think it should be fine -

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: On 08/12/11 04:14, Pekka Enberg wrote: On Wed, 7 Dec 2011, Ingo Molnar wrote: * Matt Evans m...@ozlabs.org wrote: [...] I haven't looked closely at Matt's patches, but it should be possible to use [un]signed long long for the u64/s64 types

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Matt Evans m...@ozlabs.org wrote: Since tools/kvm/include/linux/types.h only requires __u32, __u64 et al from asm/types.h, wouldn't it be most straightforward to just #include asm-generic/int-ll64.h? This avoids #define __KERNEL__ breaking other includes brought into userland, avoids

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Sasha Levin levinsasha...@gmail.com wrote: Ingo actually got us to remove all the PRI* specifiers, but that was back when we only did x86 :) Ingo, does it make sense to use them now when we support different architectures? Not at all - ppc should use a sane u64/s64 definition, i.e.

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Paul Mackerras pau...@samba.org wrote: On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote: * Sasha Levin levinsasha...@gmail.com wrote: Ingo actually got us to remove all the PRI* specifiers, but that was back when we only did x86 :) Ingo, does it make sense

Re: [PATCH 1/2] kvm tools: Zero out event before calling epoll_ctl()

* Sasha Levin levinsasha...@gmail.com wrote: Zero out struct epoll_event before calling epoll_ctl(). This isn't really required, but is done to avoid warnings. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/kvm-ipc.c |2 +- 1 files changed, 1 insertions(+), 1

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Sasha Levin levinsasha...@gmail.com wrote: Ingo actually got us to remove all the PRI* specifiers, but that was back when we only did x86 :) Ingo, does it make sense to use them now when we support different architectures? Not at all - ppc should use a sane u64/s64 definition, i.e.

Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately

* Paul Mackerras pau...@samba.org wrote: On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote: * Sasha Levin levinsasha...@gmail.com wrote: Ingo actually got us to remove all the PRI* specifiers, but that was back when we only did x86 :) Ingo, does it make sense

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Anca Emanuel anca.eman...@gmail.com wrote: I'd even argue that that C library is obviously something the kernelshould offer as well - so klibc is the way to go and would help usfurther streamline this and keep Linux quality high. I think there is code to share. Why not ? The biggest

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Alexander Graf ag...@suse.de wrote: [...] Outside of the kernel tree, you can do your own decisions. If someone thinks it's a great idea to write device emulation in python (I would love that!), he could go in and implement it without having to worry about Linus possibly rejecting it

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Ted Ts'o ty...@mit.edu wrote: On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote: I guess you can do well with a split project as well - my main claim is that good compatibility comes *naturally* with integration. Here I have to disagree; my main worry is that integration

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Ted Ts'o ty...@mit.edu wrote: On Tue, Nov 08, 2011 at 07:14:57PM +0200, Anca Emanuel wrote: @Ten Ts'o: you are sponsored by something like microsoft (joking) ? Stop trolling. If you are not familiar with perf, or other tools, save your time and do some useful things. I am quite

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* John Kacur jka...@redhat.com wrote: On Tue, 8 Nov 2011, Ted Ts'o wrote: On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote: I guess you can do well with a split project as well - my main claim is that good compatibility comes *naturally* with integration. Here I

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Gerd Hoffmann kra...@redhat.com wrote: For reference, the default set of colors now is (from tools/perf/util/ui/browser.c): static struct ui_browser__colorset { const char *name, *fg, *bg; int colorset; } ui_browser__colorsets[] = { {

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Arnaldo Carvalho de Melo a...@redhat.com wrote: sure the colors have enougth contrast so they are readable. Problem is figuring out something that is considered a good default :-\ There will always be somebody that will complain. When doing the coding to allow using the default xterm

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Steven Rostedt rost...@goodmis.org wrote: On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote: None of the perf developers with whom i'm working complained about the shared repo so far - publicly or privately. By all means they are enjoying it and if you look at the stats

Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

* Arnaldo Carvalho de Melo a...@redhat.com wrote: Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu: Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu: Its fully configurable as of now, what we need is a set of .perfconfigs that show how people

  1   2   3   4   5   6   7   >