Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux

[Purcareata Bogdan]

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 injection in an atomic regions for example).
> > > > Until it is, using raw_spin_lock is correct.
> > >
> > > It does not sound like it. It sounds more like disabling interrupts to
> > > get things run faster and then limit it on a different corner to not
> > > blow up everything.
> >
> > "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 external interrupts, because of the openpic
> > spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux".
> >
> > > Max latencies was decreased "Max latency (us)  70        62" and that
> > > is why this is done? For 8 us and possible DoS in case there are too
> > > many cpus?
> >
> > My understanding is that:
> >
> > 1) netperf can get you a BUG KVM, and raw_spinlock fixes that

Actually, it's not just netperf. The bug triggers in the following 
scenarios:
- running CPU intensive task (while true; do date; done) in SMP guest 
(even with 2 VCPUs)
- running netperf in guest
- running cyclictest in SMP guest

> May I please see a backtrace with context tracking which states where
> the interrupts / preemption gets disabled and where the lock was taken?

Will do, I will get back to you as soon as I have it available. I will 
try and capture it using function trace.

> I'm not totally against this patch I just want to make sure this is not
> a blind raw conversation to shup up the warning the kernel throws.
>
> > 2) cyclictest did not trigger the BUG, and you can also get reduced
> > latency from using raw_spinlock.
> >
> > I think we agree that (2) is not a factor in accepting the patch.
> good :)
>
> > Paolo
> Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/