From: Alexander Graf <agraf@suse.de>
To: Bogdan Purcareata <bogdan.purcareata@freescale.com>,
linuxppc-dev@lists.ozlabs.org, linux-rt-users@vger.kernel.org,
bigeasy@linutronix.de, pbonzini@redhat.com
Cc: scottwood@freescale.com, mihai.caraman@freescale.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
Date: Fri, 20 Feb 2015 14:45:08 +0100 [thread overview]
Message-ID: <54E73A64.5020608@suse.de> (raw)
In-Reply-To: <1424251955-308-3-git-send-email-bogdan.purcareata@freescale.com>
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
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Bogdan Purcareata <bogdan.purcareata@freescale.com>,
linuxppc-dev@lists.ozlabs.org, linux-rt-users@vger.kernel.org,
bigeasy@linutronix.de, pbonzini@redhat.com
Cc: linux-kernel@vger.kernel.org, scottwood@freescale.com,
mihai.caraman@freescale.com
Subject: Re: [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
Date: Fri, 20 Feb 2015 14:45:08 +0100 [thread overview]
Message-ID: <54E73A64.5020608@suse.de> (raw)
In-Reply-To: <1424251955-308-3-git-send-email-bogdan.purcareata@freescale.com>
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
>
>
next prev parent reply other threads:[~2015-02-20 13:45 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 9:32 [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux Bogdan Purcareata
2015-02-18 9:32 ` Bogdan Purcareata
2015-02-18 9:32 ` [PATCH 1/2] powerpc/kvm: Convert openpic lock to raw_spinlock Bogdan Purcareata
2015-02-18 9:32 ` Bogdan Purcareata
2015-02-23 22:43 ` Scott Wood
2015-02-23 22:43 ` Scott Wood
2015-02-18 9:32 ` [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux Bogdan Purcareata
2015-02-18 9:32 ` Bogdan Purcareata
2015-02-18 9:36 ` Sebastian Andrzej Siewior
2015-02-18 9:36 ` Sebastian Andrzej Siewior
2015-02-20 13:45 ` Alexander Graf [this message]
2015-02-20 13:45 ` Alexander Graf
2015-02-23 22:48 ` Scott Wood
2015-02-23 22:48 ` Scott Wood
2015-02-20 13:45 ` [PATCH 0/2] powerpc/kvm: Enable running guests " Alexander Graf
2015-02-20 13:45 ` Alexander Graf
2015-02-20 14:12 ` Paolo Bonzini
2015-02-20 14:12 ` Paolo Bonzini
2015-02-20 14:16 ` Alexander Graf
2015-02-20 14:16 ` Alexander Graf
2015-02-20 14:54 ` Sebastian Andrzej Siewior
2015-02-20 14:54 ` Sebastian Andrzej Siewior
2015-02-20 14:57 ` Paolo Bonzini
2015-02-20 14:57 ` Paolo Bonzini
2015-02-20 15:06 ` Sebastian Andrzej Siewior
2015-02-20 15:06 ` Sebastian Andrzej Siewior
2015-02-20 15:10 ` Paolo Bonzini
2015-02-20 15:10 ` Paolo Bonzini
2015-02-20 15:17 ` Sebastian Andrzej Siewior
2015-02-20 15:17 ` Sebastian Andrzej Siewior
2015-02-23 8:12 ` Purcareata Bogdan
2015-02-23 8:12 ` Purcareata Bogdan
2015-02-23 7:50 ` Purcareata Bogdan
2015-02-23 7:50 ` Purcareata Bogdan
2015-02-23 7:29 ` Purcareata Bogdan
2015-02-23 7:29 ` Purcareata Bogdan
2015-02-23 23:27 ` Scott Wood
2015-02-23 23:27 ` Scott Wood
2015-02-23 23:27 ` Scott Wood
2015-02-25 16:36 ` Sebastian Andrzej Siewior
2015-02-25 16:36 ` Sebastian Andrzej Siewior
2015-02-26 13:02 ` Paolo Bonzini
2015-02-26 13:02 ` Paolo Bonzini
2015-02-26 13:31 ` Sebastian Andrzej Siewior
2015-02-26 13:31 ` Sebastian Andrzej Siewior
2015-02-27 1:05 ` Scott Wood
2015-02-27 1:05 ` Scott Wood
2015-02-27 13:06 ` Paolo Bonzini
2015-02-27 13:06 ` Paolo Bonzini
2015-03-27 17:07 ` Purcareata Bogdan
2015-03-27 17:07 ` Purcareata Bogdan
2015-04-02 23:11 ` Scott Wood
2015-04-02 23:11 ` Scott Wood
2015-04-03 8:07 ` Purcareata Bogdan
2015-04-03 8:07 ` Purcareata Bogdan
2015-04-03 21:26 ` Scott Wood
2015-04-03 21:26 ` Scott Wood
2015-04-09 7:44 ` Purcareata Bogdan
2015-04-09 7:44 ` Purcareata Bogdan
2015-04-09 7:44 ` Purcareata Bogdan
2015-04-09 23:53 ` Scott Wood
2015-04-09 23:53 ` Scott Wood
2015-04-20 10:53 ` Purcareata Bogdan
2015-04-20 10:53 ` Purcareata Bogdan
2015-04-21 0:52 ` Scott Wood
2015-04-21 0:52 ` Scott Wood
2015-04-22 12:06 ` Purcareata Bogdan
2015-04-22 12:06 ` Purcareata Bogdan
2015-04-22 12:06 ` Purcareata Bogdan
2015-04-23 0:30 ` Scott Wood
2015-04-23 0:30 ` Scott Wood
2015-04-23 12:31 ` Purcareata Bogdan
2015-04-23 12:31 ` Purcareata Bogdan
2015-04-23 12:31 ` Purcareata Bogdan
2015-04-23 21:26 ` Scott Wood
2015-04-23 21:26 ` Scott Wood
2015-04-27 6:45 ` Purcareata Bogdan
2015-04-27 6:45 ` Purcareata Bogdan
2015-04-27 6:45 ` Purcareata Bogdan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E73A64.5020608@suse.de \
--to=agraf@suse.de \
--cc=bigeasy@linutronix.de \
--cc=bogdan.purcareata@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mihai.caraman@freescale.com \
--cc=pbonzini@redhat.com \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.