On Fri, 18 Sep 2015, Paolo Bonzini wrote:
> This is friendlier to clients of the code, who are going to prepare
> vcpu_data structs unconditionally, even if CONFIG_IRQ_REMAP is not
> defined.
>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Reviewed-b
On Tue, 25 Aug 2015, Marc Zyngier wrote:
+static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
+
#ifndef MAX_GIC_NR
#define MAX_GIC_NR 1
#endif
@@ -137,6 +140,14 @@ static inline unsigned int gic_irq(struct irq_data *d)
return d-hwirq;
}
+static inline bool
On Fri, 7 Aug 2015, Peter Zijlstra wrote:
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…
On Thu, 9 Jul 2015, Marc Zyngier wrote:
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When used as a secondary interrupt controller, it uses handler_data
instead. As this difference is relatively pointless and
On Sat, 20 Jun 2015, Andy Lutomirski wrote:
On Sat, Jun 20, 2015 at 7:14 AM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 20 Jun 2015, walter harms wrote:
Acked-by: walter harms wha...@bfs.de
Am 17.06.2015 02:35, schrieb Andy Lutomirski:
This is only used if BAYCOM_DEBUG
On Sat, 20 Jun 2015, walter harms wrote:
Acked-by: walter harms wha...@bfs.de
Am 17.06.2015 02:35, schrieb Andy Lutomirski:
This is only used if BAYCOM_DEBUG is defined.
So why don't we just replace that by ktime_get() and get rid of the
x86'ism in that driver.
Thanks,
tglx
--
On Tue, 16 Jun 2015, Juergen Gross wrote:
AFAIK there are no outstanding questions for more than one month now.
I'd appreciate some feedback or accepting these patches.
They are against dead code, which will be gone soon. We switched over
to queued locks.
Thanks,
tglx
--
To
On Wed, 29 Oct 2014, Waiman Long wrote:
AIM7 XFS Disk Test (no overcommit)
kernel JPMReal Time Sys TimeUsr Time
- ----
PV ticketlock 25423737.08 98.95 5.44
PV
On Tue, 25 Nov 2014, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
On Tue, 25 Nov 2014, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Can this patch be merged in the KVM tree, and go
this for inclusion in the KVM tree?
Are you content with my acked-by as well?
Acked-by: Thomas Gleixner t...@linutronix.de
--
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
On Mon, 10 Nov 2014, Feng Wu wrote:
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
Can you
On Mon, 22 Sep 2014, Paolo Bonzini wrote:
On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.
The failure mode is currently a divide-by-zero exception, which
On Thu, 4 Sep 2014, Paolo Bonzini wrote:
Il 04/09/2014 22:58, Thomas Gleixner ha scritto:
This is simply wrong.
It is.
Now I have no idea why you think it needs to add xtime_sec. If the
result is wrong, then we need to figure out which one of the supplied
values is wrong
On Fri, 5 Sep 2014, Paolo Bonzini wrote:
Il 05/09/2014 17:14, Thomas Gleixner ha scritto:
So that means the code is correct. Now where is the bug?
In kernel/time/timekeeping.c?
We know that we should have
base_mono = wall_to_monotonic + xtime_sec
Instead
On Fri, 5 Sep 2014, Paolo Bonzini wrote:
Il 05/09/2014 20:33, Thomas Gleixner ha scritto:
update_vsyscall(tk);
-update_pvclock_gtod(tk, action TK_CLOCK_WAS_SET);
tk_update_ktime_data(tk);
+update_pvclock_gtod(tk, action TK_CLOCK_WAS_SET);
Why
On Fri, 5 Sep 2014, Linus Torvalds wrote:
On Fri, Sep 5, 2014 at 3:16 AM, Paolo Bonzini pbonz...@redhat.com wrote:
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
Nothing new there. Forgot to push out, or perhaps to use -f to
On Fri, 5 Sep 2014, Paolo Bonzini wrote:
Il 05/09/2014 22:58, Thomas Gleixner ha scritto:
Nothing new there. Forgot to push out, or perhaps to use -f to
overwrite the previous tag of the same name?
It's there now. Probably a --dry-run too much (I have
push=+refs/tags/for-linus:refs/tags
On Fri, 5 Sep 2014, Paolo Bonzini wrote:
Il 05/09/2014 23:24, Thomas Gleixner ha scritto:
that besides acting as a workaround, I find the patched code easier to
understand, and I clearly stated the same in the tag message.
Well, we might have different opinions about easier
On Thu, 4 Sep 2014, Paolo Bonzini wrote:
Commit cbcf2dd3b3d4 (x86: kvm: Make kvm_get_time_and_clockread() nanoseconds
based, 2014-07-16) forgot to add tk-xtime_sec, thus breaking kvmclock on
Errm. How is boottime related to xtime_sec?
hosts that have a reliable TSC. Add it back; and since
, adding xtime_sec separately. The boot_ns
moniker is not too clear, so rename boot_ns to nsec_base and the existing
nsec_base to snsec_base.
Cc: Thomas Gleixner t...@linutronix.de
Cc: John Stultz john.stu...@linaro.org
Reported-by: Chris J Arges chris.j.ar...@canonical.com
Signed-off
On Thu, 4 Sep 2014, Paolo Bonzini wrote:
Il 04/09/2014 22:58, Thomas Gleixner ha scritto:
This is simply wrong.
It is.
Now I have no idea why you think it needs to add xtime_sec. If the
result is wrong, then we need to figure out which one of the supplied
values is wrong
Use the new nanoseconds based interface and get rid of the timespec
conversion dance.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: tip/arch
Convert the relevant base data right away to nanoseconds instead of
doing the conversion on every readout. Reduces text size by 160 bytes.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c | 44
Convert the relevant base data right away to nanoseconds instead of
doing the conversion on every readout. Reduces text size by 160 bytes.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c | 44
Use the new nanoseconds based interface and get rid of the timespec
conversion dance.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: tip/arch
On Wed, 28 May 2014, Linus Torvalds wrote:
If somebody has a P4 still, that's likely the worst case by far.
I do, but I'm only using it during winter and only if the ia64 machine
does not provide sufficient heating. So you have to wait at least half
a year until I'm able to test it.
--
To
On Thu, 30 May 2013, Raghavendra K T wrote:
Here is the branch with pvpspinlock V9 version in github reabsed to 3.10-rc
https://github.com/ktraghavendra/linux/tree/pvspinlock_v9
planning post a formal email in a separate thread with link a to this
branch (instead of spamming with 19
On Sat, 14 Jul 2012, Jan Kiszka wrote:
On 2012-07-14 04:25, Thomas Gleixner wrote:
This patch here is a workaround to unbreak devices assignment in 3.5
after the IRQ layer changes without regressing noticeable /wrt overhead.
Yeah, workaround and regression are the proper marketing buzzwords
On Sat, 14 Jul 2012, Jan Kiszka wrote:
On 2012-07-14 13:16, Thomas Gleixner wrote:
On Sat, 14 Jul 2012, Jan Kiszka wrote:
On 2012-07-14 04:25, Thomas Gleixner wrote:
This patch here is a workaround to unbreak devices assignment in 3.5
after the IRQ layer changes without regressing
On Fri, 13 Jul 2012, Linus Torvalds wrote:
On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
improved. The fact that the KVM people think that the extra overhead
of IRQF_ONESHOT is a bad
On Fri, 13 Jul 2012, Linus Torvalds wrote:
On Fri, Jul 13, 2012 at 11:28 AM, Thomas Gleixner t...@linutronix.de wrote:
We already discussed to let the irq chip (in this case MSI) tell the
core that it does not need the extra oneshot handling. That way the
code which requests an threaded
On Fri, 13 Jul 2012, Thomas Gleixner wrote:
On Fri, 13 Jul 2012, Linus Torvalds wrote:
On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
improved. The fact that the KVM people think
On Sun, 3 Jun 2012, Avi Kivity wrote:
On 06/01/2012 09:26 PM, Jan Kiszka wrote:
you suggesting we need a request_edge_threaded_only_irq() API? Thanks,
I'm just wondering if that restriction for threaded IRQs is really
necessary for all use cases we have. Threaded MSIs do not appear
On Mon, 4 Jun 2012, Jan Kiszka wrote:
On 2012-06-04 13:21, Thomas Gleixner wrote:
So this shortcut requires some checks before being applied to a specific
MSI/MSI-X vector.
Taking KVM aside, my general question remains if threaded MSI handlers
of all devices really need to apply
On Mon, 4 Jun 2012, Jan Kiszka wrote:
On 2012-06-04 15:07, Thomas Gleixner wrote:
On Mon, 4 Jun 2012, Jan Kiszka wrote:
On 2012-06-04 13:21, Thomas Gleixner wrote:
So this shortcut requires some checks before being applied to a specific
MSI/MSI-X vector.
Taking KVM aside, my
On Thu, 24 May 2012, Alex Williamson wrote:
On Thu, 2012-05-24 at 18:02 +0100, Richard Weinberger wrote:
+if (address == msi_start + PCI_MSI_DATA_32)
+handle_cfg_write_msi(pci_dev, assigned_dev);
Why didn't we just use range_covers_byte(address, len,
On Thu, 24 May 2012, Alex Williamson wrote:
On Thu, 2012-05-24 at 18:53 -0300, Jan Kiszka wrote:
On 2012-05-24 18:39, Thomas Gleixner wrote:
On Thu, 24 May 2012, Alex Williamson wrote:
On Thu, 2012-05-24 at 18:02 +0100, Richard Weinberger wrote:
+if (address == msi_start
On Fri, 25 May 2012, Michael S. Tsirkin wrote:
On Thu, May 24, 2012 at 06:53:15PM -0300, Jan Kiszka wrote:
On 2012-05-24 18:39, Thomas Gleixner wrote:
On Thu, 24 May 2012, Alex Williamson wrote:
On Thu, 2012-05-24 at 18:02 +0100, Richard Weinberger wrote:
+if (address
On Fri, 25 May 2012, Thomas Gleixner wrote:
On Fri, 25 May 2012, Michael S. Tsirkin wrote:
On Thu, May 24, 2012 at 06:53:15PM -0300, Jan Kiszka wrote:
On 2012-05-24 18:39, Thomas Gleixner wrote:
On Thu, 24 May 2012, Alex Williamson wrote:
On Thu, 2012-05-24 at 18:02 +0100, Richard
On Thu, 24 May 2012, Alex Williamson wrote:
On Fri, 2012-05-25 at 01:01 +0200, Thomas Gleixner wrote:
So the proper fix is that qemu tells the guest that mask bit is
supported and catches the mask bit toggling before writing it out to
the hardware for those devices which do not support
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/22/2012 08:26 PM, Thomas Gleixner wrote:
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/23/2012 05:48 PM, Ingo Molnar wrote:
This is silly. Most of the time the kernel is advanced by
incremental patches. Sometimes it is advanced by minor or
major refactoring. It is never advanced by personal attacks
on contributors.
On Wed, 23 May 2012, H. Peter Anvin wrote:
On 05/23/2012 11:37 AM, Thomas Gleixner wrote:
That works, but replaces one problem with another: now we have two
sources for the same data, and need to juggle between them depending on
register number (either synchronizing in both directions
On Wed, 23 May 2012, Michael S. Tsirkin wrote:
On Wed, May 23, 2012 at 10:10:27PM +0200, Thomas Gleixner wrote:
Replying on a still polite reminder with a sloppy I just took what's
there and implemeted the optimization which I was tasked with is even
more of an offense.
Ow
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory into the guest space,
which is not the case here.
The APIC page is in fact mapped
On Mon, 21 May 2012, Michael S. Tsirkin wrote:
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we set/clear them in ISR
2. if count is 1, caching the vector number
3. if
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int vec, struct
kvm_lapic *apic)
apic-irr_pending = true;
}
+static inline void apic_set_isr(int
Michael,
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
On Mon, 21 May 2012, Michael S. Tsirkin wrote:
+static u8 count_vectors(void *bitmap)
+{
+ u32 *word = bitmap;
+ int word_offset;
+ u8 count = 0;
+ for (word_offset
On Mon, 7 May 2012, Ingo Molnar wrote:
* 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
On Sun, 1 Apr 2012, Avi Kivity wrote:
On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics are the correct approach
or not.
If I look at it from the non
-by: Thomas Gleixner t...@linutronix.de
--
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
* @setup_percpu_clockev:set up the per cpu clock event device
+ * @early_percpu_clock_init: early init of the per cpu clock event device
You initialize the per cpu clock, not the per cpu clock event
device. The latter is still initialized via setup_percpu_clockev().
Otherwise
Acked-by: Thomas Gleixner t
On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 16.12.2010 21:26, Jan Kiszka wrote:
Am 16.12.2010 14:13, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
+ if (old_action (old_action-flags IRQF_ADAPTIVE)
+ !(desc-irq_data.drv_status IRQS_SHARED
On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 17.12.2010 11:23, Thomas Gleixner wrote:
OTOH, if we have to disable anyway, then we could simply keep it
disabled across the installation of a new handler. That would make the
notification business go away, wouldn't it ?
No, the notification
On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 17.12.2010 11:41, Thomas Gleixner wrote:
On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 17.12.2010 11:23, Thomas Gleixner wrote:
OTOH, if we have to disable anyway, then we could simply keep it
disabled across the installation of a new handler
On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 17.12.2010 16:25, Thomas Gleixner wrote:
Your aproach with disable_irq_nosync() is completely flawed, simply
because you try to pretend that your interrupt handler is done, while
it is not done at all. The threaded interrupt handler is done when
On Mon, 13 Dec 2010, Jan Kiszka wrote:
+ if (old_action (old_action-flags IRQF_ADAPTIVE)
+ !(desc-irq_data.drv_status IRQS_SHARED)) {
+ /*
+ * Signal the old handler that is has to switch to shareable
+ * handling mode. Disable the line to
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 15.12.2010 09:05, Thomas Gleixner wrote:
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 14.12.2010 22:46, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
chip_bus_lock(desc
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 14.12.2010 21:54, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
@@ -943,6 +950,9 @@ static struct irqaction *__free_irq(unsigned int irq,
void *dev_id)
/* Make sure it's not being used on another CPU: */
synchronize_irq
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 15.12.2010 14:04, Thomas Gleixner wrote:
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 14.12.2010 21:54, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
@@ -943,6 +950,9 @@ static struct irqaction *__free_irq(unsigned int
irq, void
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 15.12.2010 14:04, Thomas Gleixner wrote:
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 14.12.2010 21:54, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
@@ -943,6 +950,9 @@ static struct irqaction *__free_irq(unsigned int
irq, void
On Wed, 15 Dec 2010, Jan Kiszka wrote:
Am 15.12.2010 16:41, Thomas Gleixner wrote:
Talking about headache. Your solution above does not prevent that
scenario.
CPU 0 CPU 1
synchronize_irq();
hard irq comes in sees shared
On Mon, 13 Dec 2010, Jan Kiszka wrote:
+/**
+ * get_irq_status - read interrupt line status word
+ * @irq: Interrupt line of the status word
+ *
+ * This returns the current content of the status word associated with
+ * the given interrupt line. See IRQS_* flags for details.
+ */
On Mon, 13 Dec 2010, Jan Kiszka wrote:
@@ -943,6 +950,9 @@ static struct irqaction *__free_irq(unsigned int irq,
void *dev_id)
/* Make sure it's not being used on another CPU: */
synchronize_irq(irq);
+ if (single_handler)
+ desc-irq_data.drv_status =
On Mon, 13 Dec 2010, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
chip_bus_lock(desc);
retval = __setup_irq(irq, desc, action);
chip_bus_sync_unlock(desc);
- if (retval)
+ if (retval) {
+ if (desc-action !desc-action-next)
+
On Mon, 13 Dec 2010, Jan Kiszka wrote:
This addresses the review comments of the previous round:
- renamed irq_data::status to drv_status
- moved drv_status around to unbreak GENERIC_HARDIRQS_NO_DEPRECATED
- fixed signature of get_irq_status (irq is now unsigned int)
- converted
On Sun, 12 Dec 2010, Jan Kiszka wrote:
Am 12.12.2010 18:29, Thomas Gleixner wrote:
Also we should name it different than status, drv_status perhaps, to
avoid confusion with the irq_desc status.
OK, will address both in a succeeding round (just waiting for potential
further comments
On Sun, 12 Dec 2010, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This enabled interrupt handlers to retrieve the current line sharing state via
the new interrupt status word so that they can adapt to it.
The switch from shared to exclusive is generally uncritical and can
On Sun, 12 Dec 2010, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This associates a status word with every IRQ descriptor. Drivers can obtain
its content via get_irq_status(irq). First use case will be propagating the
interrupt sharing state.
Signed-off-by: Jan Kiszka
On Sat, 4 Dec 2010, Jan Kiszka wrote:
Besides 3 cleanup patches, this series consists of two major changes.
The first introduces an interrupt sharing notifier to the genirq
subsystem. It fires when an interrupt line is about to be use by more
than one driver or the last but one user called
Jan,
On Sat, 4 Dec 2010, Jan Kiszka wrote:
Am 04.12.2010 11:37, Thomas Gleixner wrote:
On Sat, 4 Dec 2010, Jan Kiszka wrote:
If interrupt is shared, then you want to keep the current behaviour:
disable at line level (IRQF_ONESHOT)
run handler thread (PCI level masking
On Sat, 4 Dec 2010, Jan Kiszka wrote:
Am 04.12.2010 15:41, Thomas Gleixner wrote:
Also there is a pretty simple solution for this: The core code knows,
that there is an ONESHOT interrupt in flight, so it simply can call
It doesn't synchronize the tail part against the masking
On Tue, 23 Feb 2010, Jan Kiszka wrote:
Thomas Gleixner wrote:
The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert
them to raw_spinlock. No change for !RT kernels.
Doesn't fly for -rt anymore: pic_irq_update runs under this raw lock and
calls kvm_vcpu_kick which tries
The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert
them to raw_spinlock. No change for !RT kernels.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/x86/kvm/i8254.c | 10 +-
arch/x86/kvm/i8254.h |2 +-
arch/x86/kvm/i8259.c | 31
On Mon, 30 Nov 2009, Tejun Heo wrote:
Hello,
On 11/28/2009 09:12 PM, Avi Kivity wrote:
Hmm, commit 498657a moved the fire_sched_in_preempt_notifiers() call
into the irqs disabled section recently.
sched, kvm: Fix race condition involving sched_in_preempt_notifers
In
On Fri, 27 Nov 2009, Peter Zijlstra wrote:
On Fri, 2009-11-27 at 16:03 +0100, Jiri Slaby wrote:
On 11/25/2009 01:47 AM, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2009-11-24-16-47 has been uploaded to
Hi, when executing qemu-kvm I often get following warning and a
On Fri, 27 Nov 2009, Thomas Gleixner wrote:
On Fri, 27 Nov 2009, Peter Zijlstra wrote:
On Fri, 2009-11-27 at 16:03 +0100, Jiri Slaby wrote:
On 11/25/2009 01:47 AM, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2009-11-24-16-47 has been uploaded to
Hi, when
On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
What about getting rid of the retry loop, instead? So something
like:
- run hrtimer callbacks (once)
- while (tick_program_event(expires))
expires = ktime_add_ns(expires,
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Yesterday I was lucky enough to actually watch what's
going on when the delay actually happens.
I run desktop environment on a kvm virtual machine here.
The server is on diskless terminal, and the rest, incl.
the window manager etc, is started from
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Thomas Gleixner wrote:
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Yesterday I was lucky enough to actually watch what's
going on when the delay actually happens.
I run desktop environment on a kvm virtual machine here.
The server
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Thomas Gleixner wrote:
I'm really missing the big picture here.
What means causes timers to be calculated on the wrong CPU etc ?
And what do you consider a scheduling mistake ?
From the initial diagnostics by Marcelo:
It seems the way
On Thu, 8 Oct 2009, Marcelo Tosatti wrote:
On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote:
On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
What about getting rid of the retry loop, instead? So something
*/
WARN_ON_ONCE(irqs_disabled() !oops_in_progress);
Do we get another fix?
I think I have seen that before. Just remembered that I fixed that
with Avi last year. Patch got dropped in the 26-29 move.
Thanks,
tglx
From: Thomas Gleixner t...@linutronix.de
Date: Mon, 14 Jan 2008 14:02:44
On Wed, 4 Jun 2008, Avi Kivity wrote:
Anthony Liguori wrote:
Thomas Gleixner wrote:
Can we please keep that code inside of drivers/clocksource/acpi_pm.c
without creating a new disconnected file in drivers/char ?
Btw, depending on the use case we might as well have a sysfs entry
On Tue, 3 Jun 2008, Jiri Kosina wrote:
Ahh yes - you are right , I've completely forget about that old post -
I've thought that my post are usually getting fixed sooner :)
So yes - this is actually the same bug which is still not fixed within
the latest kernel - the machine is running
On Sun, 1 Jun 2008, Marcelo Tosatti wrote:
On Sun, Jun 01, 2008 at 06:34:27PM +0200, Thomas Gleixner wrote:
A sysfs entry sounds fine and much simpler. Should probably be a generic
clocksource interface (so userspace can read any available clocksource)
rather than acpi_pm specific.
Agreed
91 matches
Mail list logo
