On Fri, 13 Jul 2012, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
> 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 thing for MSI interrupts
On Fri, 13 Jul 2012, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 11:28 AM, Thomas Gleixner 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 re
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
> > wrote:
> > At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
> > improved. The fact that the
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
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
> >>
On Mon, 7 May 2012, Ingo Molnar wrote:
> * Avi Kivity 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 o
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
>
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;
>
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:
> > > >
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:
> > > > >
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:
> > > > >
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;
> >
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
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
> >&
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 cont
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
> >> regist
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
&
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, pci_d
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:
&g
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
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, 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
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
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
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
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
--
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
n ret;
> }
>
> +void kvm_save_sched_clock_state(void)
static ?
> +{
> +}
> +
> +void kvm_restore_sched_clock_state(void)
Ditto
> +{
> + kvm_register_clock("primary cpu clock, resume");
> +}
> +
Otherwise: Reviewed-by: Thomas Gleixner
--
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 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 virtualiz
On Sat, 31 Mar 2012, Andi Kleen wrote:
> > So if a guest exits due to an external event it's easy to inspect the
> > state of that guest and avoid to schedule away when it was interrupted
> > in a spinlock held section. That guest/host shared state needs to be
>
> On a large system under high con
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 o
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)
> >
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
On Sun, 12 Dec 2010, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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 thus be
> performed
On Sun, 12 Dec 2010, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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
> ---
> include/linu
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 fo
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
> 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 regi
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
> >>chip_bus_lock(desc);
> >>retval = __setup_irq(irq, desc, action);
> >>chip_bus
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:
> >>>> F
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 sur
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 @@ sta
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 @@ sta
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();
> &g
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
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) &&
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, would
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
> >>>
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 inte
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
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
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c | 44 ++--
1 file
Use the new nanoseconds based interface and get rid of the timespec
conversion dance.
Signed-off-by: Thomas Gleixner
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: tip/arch/x86/kvm/x86.c
Use the new nanoseconds based interface and get rid of the timespec
conversion dance.
Signed-off-by: Thomas Gleixner
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: tip/arch/x86/kvm/x86.c
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
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c | 44 ++--
1 file
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 sinc
fs_boot = -wall_to_monotonic - total_sleep_time
>
> that is
>
>offs_boot - offs_real = wall_to_monotonic + total_sleep_time
>
> which is what this patch uses, adding xtime_sec separately. The "boot_ns"
> moniker is not too clear, so rename boot_ns to nsec_base and the
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 th
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 th
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 = wa
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_d
On Fri, 5 Sep 2014, Linus Torvalds wrote:
> On Fri, Sep 5, 2014 at 3:16 AM, Paolo Bonzini 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
> overwrite
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 to
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,
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 obvi
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
on in the KVM tree?
Are you content with my acked-by as well?
Acked-by: Thomas Gleixner
--
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 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
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, a
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 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 uns
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(expi
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 start
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.
> > >
> >
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 "schedulin
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
On Wed, 8 Apr 2009, Jan Blunck wrote:
> This patch removes the stupid "Read locks within the self-held write lock
> succeed" behaviour. This is breaking in mm_take_all_locks() since it is quite
> common to ensure that a lock is taken with
> BUG_ON(down_read_trylock(&mm->mmap_sem)).
Good catch. T
On Wed, 8 Apr 2009, Jan Blunck wrote:
> This patch converts some KVM spin-locks to be of type raw_spinlock_t.
Applied. Thanks,
tglx
--
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
On Wed, 8 Apr 2009, Jan Blunck wrote:
> This moves the get_cpu() call down to be called after we wake up the
> waiters. Therefore the waitqueue locks can savely be rt mutex.
Applied. Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
alled with interrupts disabled */
> 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: Thom
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
---
arch/x86/kvm/i8254.c | 10 +-
arch/x86/kvm/i8254.h |2 +-
arch/x86/kvm/i8259.c | 31 ---
arch
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
&
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 warnin
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
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
> >
On Thu, 29 May 2008, Marcelo Tosatti wrote:
> KVM wishes to allow direct guest access to the ACPI pmtimer. In that
> case QEMU/KVM has to read the current value for migration, so the proper
> syncing can be done on the destination.
I don't understand from the above which problem you are trying to
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 a
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, depe
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 runn
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 unsubsc
On Sat, 20 Jun 2015, walter harms wrote:
> Acked-by: walter harms
>
> 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
--
To unsubsc
On Sat, 20 Jun 2015, Andy Lutomirski wrote:
> On Sat, Jun 20, 2015 at 7:14 AM, Thomas Gleixner wrote:
> > On Sat, 20 Jun 2015, walter harms wrote:
> >
> >> Acked-by: walter harms
> >>
> >> Am 17.06.2015 02:35, schrieb Andy Lutomirski:
> >
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 pointles
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 th
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 in
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
Reviewed-by: Thomas Gleixner
> ---
>
97 matches
Mail list logo
