| Message ID | 1424251955-308-3-git-send-email-bogdan.purcareata@freescale.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On 02/18/2015 10:32 AM, Bogdan Purcareata wrote: > Due to the introduction of the raw_spinlock for the KVM openpic, guests with a > high number of VCPUs may induce great latencies on the underlying RT Linux > system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). > This can be further aggravated by sending a lot of external interrupts to the > guest. > > A malicious app can abuse this scenario, causing a DoS of the host Linux. > Until the KVM openpic code is refactored to use finer lock granularity, impose > a limitation on the number of VCPUs a guest can have when running on a > PREEMPT_RT_FULL system with KVM_MPIC emulation. How is this possible? You take the raw lock, write a register, release the raw lock. How can the guest lockup the host? Is this write blocking in guest? Sebastian
On 18.02.15 10:32, Bogdan Purcareata wrote: > Due to the introduction of the raw_spinlock for the KVM openpic, guests with a > high number of VCPUs may induce great latencies on the underlying RT Linux > system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). > This can be further aggravated by sending a lot of external interrupts to the > guest. > > A malicious app can abuse this scenario, causing a DoS of the host Linux. > Until the KVM openpic code is refactored to use finer lock granularity, impose > a limitation on the number of VCPUs a guest can have when running on a > PREEMPT_RT_FULL system with KVM_MPIC emulation. > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com> > Reviewed-by: Scott Wood <scottwood@freescale.com> I don't think this patch is reasonable to take upstream. If we have a latency issue, whoever spawned KVM VMs made a decision to spawn such big VMs. I'd say let's leave it at MAX_VCPUS == NR_CPUS for now and rather get someone to resolve any locking problems for real ;). Alex > --- > arch/powerpc/include/asm/kvm_host.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h > index 8ef0512..6f6b928 100644 > --- a/arch/powerpc/include/asm/kvm_host.h > +++ b/arch/powerpc/include/asm/kvm_host.h > @@ -36,8 +36,14 @@ > #include <asm/cacheflush.h> > #include <asm/hvcall.h> > > +#if defined(CONFIG_PREEMPT_RT_FULL) && defined(CONFIG_KVM_MPIC) > +/* Limit the number of vcpus due to in-kernel mpic concurrency */ > +#define KVM_MAX_VCPUS 4 > +#define KVM_MAX_VCORES 4 > +#else > #define KVM_MAX_VCPUS NR_CPUS > #define KVM_MAX_VCORES NR_CPUS > +#endif > #define KVM_USER_MEM_SLOTS 32 > #define KVM_MEM_SLOTS_NUM KVM_USER_MEM_SLOTS > >
On Fri, 2015-02-20 at 14:45 +0100, Alexander Graf wrote: > > On 18.02.15 10:32, Bogdan Purcareata wrote: > > Due to the introduction of the raw_spinlock for the KVM openpic, guests with a > > high number of VCPUs may induce great latencies on the underlying RT Linux > > system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). > > This can be further aggravated by sending a lot of external interrupts to the > > guest. > > > > A malicious app can abuse this scenario, causing a DoS of the host Linux. > > Until the KVM openpic code is refactored to use finer lock granularity, impose > > a limitation on the number of VCPUs a guest can have when running on a > > PREEMPT_RT_FULL system with KVM_MPIC emulation. > > > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > > Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com> > > Reviewed-by: Scott Wood <scottwood@freescale.com> > > I don't think this patch is reasonable to take upstream. I agree (or at least, I don't think the raw lock conversion should be separated from the vcpu limitation that makes it clear that it's a temporary hack), because it ought to be fixed properly. > If we have a > latency issue, whoever spawned KVM VMs made a decision to spawn such big > VMs. I disagree. The point of PREEMPT_RT is to prevent the majority of kernel code from excessively impacting latency. When you start using raw locks you're stepping outside those bounds and need to ensure that you don't hand things within those bounds (which includes userspace) the ability to excessively impact latency. -Scott
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h index 8ef0512..6f6b928 100644 --- a/arch/powerpc/include/asm/kvm_host.h +++ b/arch/powerpc/include/asm/kvm_host.h @@ -36,8 +36,14 @@ #include <asm/cacheflush.h> #include <asm/hvcall.h> +#if defined(CONFIG_PREEMPT_RT_FULL) && defined(CONFIG_KVM_MPIC) +/* Limit the number of vcpus due to in-kernel mpic concurrency */ +#define KVM_MAX_VCPUS 4 +#define KVM_MAX_VCORES 4 +#else #define KVM_MAX_VCPUS NR_CPUS #define KVM_MAX_VCORES NR_CPUS +#endif #define KVM_USER_MEM_SLOTS 32 #define KVM_MEM_SLOTS_NUM KVM_USER_MEM_SLOTS