On 24.04.2015 00:26, Scott Wood wrote:
On Thu, 2015-04-23 at 15:31 +0300, Purcareata Bogdan wrote:
On 23.04.2015 03:30, Scott Wood wrote:
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan
On Thu, 2015-04-23 at 15:31 +0300, Purcareata Bogdan wrote:
On 23.04.2015 03:30, Scott Wood wrote:
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for
On 23.04.2015 03:30, Scott Wood wrote:
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding inner
function is
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding
inner
function is kvmppc_set_epr, which is a static
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding inner
function is kvmppc_set_epr, which is a static inline. Removing the static inline
yields a compiler crash
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
On 10.04.2015 02:53, Scott Wood wrote:
On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote:
So at this point I was getting kinda frustrated so I decided to measure
the time spend in kvm_mpic_write and kvm_mpic_read. I
On 10.04.2015 02:53, Scott Wood wrote:
On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote:
So at this point I was getting kinda frustrated so I decided to measure
the time spend in kvm_mpic_write and kvm_mpic_read. I assumed these were
the main entry points in the in-kernel MPIC and
On 04.04.2015 00:26, Scott Wood wrote:
On Fri, 2015-04-03 at 11:07 +0300, Purcareata Bogdan wrote:
On 03.04.2015 02:11, Scott Wood wrote:
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej
On 03.04.2015 02:11, Scott Wood wrote:
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
On Fri, 2015-04-03 at 11:07 +0300, Purcareata Bogdan wrote:
On 03.04.2015 02:11, Scott Wood wrote:
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM,
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver.
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a
On 27/02/2015 02:05, Scott Wood wrote:
Obviously leaving it in a buggy state is not what we want -- but I lean
towards a short term fix of putting depends on !PREEMPT_RT on the
in-kernel MPIC emulation (which is itself just an optimization -- you
can still use KVM without it). This way
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
IRQ_check() which loops over all pending
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular,
* Scott Wood | 2015-02-23 17:27:31 [-0600]:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
IRQ_check() which loops over all pending
On 20.02.2015 17:17, Sebastian Andrzej Siewior wrote:
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event
On Fri, 2015-02-20 at 15:54 +0100, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for
On 20.02.2015 17:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
Usually you see scheduling while atomic on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to
On 20.02.2015 16:54, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for upstream, that's the
On 20/02/2015 14:45, Alexander Graf wrote:
On 18.02.15 10:32, Bogdan Purcareata wrote:
This patchset enables running KVM SMP guests with external interrupts on an
underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel
MPIC
emulation could easily panic the kernel
On 18.02.15 10:32, Bogdan Purcareata wrote:
This patchset enables running KVM SMP guests with external interrupts on an
underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel
MPIC
emulation could easily panic the kernel due to preemption when delivering IPIs
and
On 20.02.15 15:12, Paolo Bonzini wrote:
On 20/02/2015 14:45, Alexander Graf wrote:
On 18.02.15 10:32, Bogdan Purcareata wrote:
This patchset enables running KVM SMP guests with external interrupts on an
underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel
MPIC
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for upstream, that's the reason why we
have raw_spin_lock vs. raw_spin_unlock.
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
Usually you see scheduling while atomic on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
not cause a DoS and large latencies in the host. I haven't seen an
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
Usually you see scheduling while atomic on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
not cause a DoS and
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event injection in an atomic regions for example).
Until it
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event injection in an atomic regions for example).
Until it is, using raw_spin_lock is correct.
It
29 matches
Mail list logo
