Re: [PATCH 20/23] KVM: PPC: Book3S PR: Better handling of host-side read-only pages
Am 14.09.2013 um 00:24 schrieb Paul Mackerras : > On Thu, Sep 12, 2013 at 06:01:37PM -0500, Alexander Graf wrote: >> >> On 05.08.2013, at 23:27, Paul Mackerras wrote: >> >>> Currently we request write access to all pages that get mapped into the >>> guest, even if the guest is only loading from the page. This reduces >>> the effectiveness of KSM because it means that we unshare every page we >>> access. Also, we always set the changed (C) bit in the guest HPTE if >>> it allows writing, even for a guest load. >> >> Have you measured how much performance we lose by mapping it twice? Usually >> Linux will mark user pages that are not written to yet as non-writable, no? >> That's why I assumed that "may_write" is the same as "guest wants to write" >> back when I wrote this. >> >> I'm also afraid that a sequence like >> >> ld x,y >> std x,y >> >> in the kernel will trap twice and slow us down heavily. But maybe I'm just >> being paranoid. Can you please measure bootup time with and without this, as >> well as a fork bomb (spawn /bin/echo 1000 times and time it) with and >> without so we get a feeling for its impact? > > Bootup (F19 guest, 3 runs): > > Without the patch: average 20.12 seconds, st. dev. 0.17 seconds > With the patch: 20.47 seconds, st. dev. 0.19 seconds > > Delta: 0.35 seconds, or 1.7%. > > time for i in $(seq 1000); do /bin/echo $i >/dev/null; done: > > Without the patch: average 7.27 seconds, st. dev. 0.23 seconds > With the patch: average 7.55 seconds, st. dev. 0.39 seconds > > Delta: 0.28 seconds, or 3.8%. > > So there appears to be a small effect, of a few percent. So in the normal case it slows us down, but allows ksm to be effective. Do we actually want this change then? Alex > > Paul. > -- 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
Re: [PATCH 19/23] KVM: PPC: Book3S: Select PR vs HV separately for each guest
Am 14.09.2013 um 13:33 schrieb "Aneesh Kumar K.V" : > Benjamin Herrenschmidt writes: > >> On Fri, 2013-09-13 at 10:17 +1000, Paul Mackerras wrote: >> >>> Aneesh and I are currently investigating an alternative approach, >>> which is much more like the x86 way of doing things. We are looking >>> at splitting the code into three modules: a kvm_pr.ko module with the >>> PR-specific bits, a kvm_hv.ko module with the HV-specific bits, and a >>> core kvm.ko module with the generic bits (basically book3s.c, >>> powerpc.c, stuff from virt/kvm/, plus the stuff that both PR and HV >>> use). Basically the core module would have a pointer to a struct >>> full of function pointers for the various ops that book3s_pr.c and >>> book3s_hv.c both provide. You would only be able to have one of >>> kvm_pr and kvm_hv loaded at any one time. If they were built in, you >>> could have them both built in but only one could register its function >>> pointer struct with the core. Obviously the kvm_hv module would only >>> load and register its struct on a machine that had hypervisor mode >>> available. If they were both built in I would think we would give HV >>> the first chance to register itself, and let PR register if we can't >>> do HV. >>> >>> How does that sound? >> >> As long as we can force-load the PR one on a machine that normally runs >> HV for the sake of testing ... > > This is what I currently have > > [root@llmp24l02 kvm]# insmod ./kvm-hv.ko > [root@llmp24l02 kvm]# insmod ./kvm-pr.ko > insmod: ERROR: could not insert module ./kvm-pr.ko: File exists The reason this model makes sense for x86 is that you never have SVM and VMX in the cpu at the same time. Either it is an AMD chip or an Intel chip. PR and HV however are not mutually exclusive in hardware. What you really want is 1) distro can force HV/PR 2) admin can force HV/PR 3) user can force HV/PR 4) by default things "just work" 1 can be done through kernel config options. 2 can be done through modules that get loaded or not 3 can be done through a vm ioctl 4 only works if you allow hv and pr to be available at the same time I can assume who you talked to about this to make these design decisions, but it definitely was not me. Alex > [root@llmp24l02 kvm]# rmmod kvm-hv > [root@llmp24l02 kvm]# insmod ./kvm-pr.ko > [root@llmp24l02 kvm]# > > So if by force load you mean rmmod kvm-hv and then modprobe kvm-pr that > works. But loading kvm-pr along side kvm-hv is not supported. My > understanding was we didn't want to allow that because that can confuse users > when they are not sure whether it is hv or pr kvm they are using. > > -aneesh > -- 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
Re: [PATCH 19/23] KVM: PPC: Book3S: Select PR vs HV separately for each guest
Benjamin Herrenschmidt writes: > On Fri, 2013-09-13 at 10:17 +1000, Paul Mackerras wrote: > >> Aneesh and I are currently investigating an alternative approach, >> which is much more like the x86 way of doing things. We are looking >> at splitting the code into three modules: a kvm_pr.ko module with the >> PR-specific bits, a kvm_hv.ko module with the HV-specific bits, and a >> core kvm.ko module with the generic bits (basically book3s.c, >> powerpc.c, stuff from virt/kvm/, plus the stuff that both PR and HV >> use). Basically the core module would have a pointer to a struct >> full of function pointers for the various ops that book3s_pr.c and >> book3s_hv.c both provide. You would only be able to have one of >> kvm_pr and kvm_hv loaded at any one time. If they were built in, you >> could have them both built in but only one could register its function >> pointer struct with the core. Obviously the kvm_hv module would only >> load and register its struct on a machine that had hypervisor mode >> available. If they were both built in I would think we would give HV >> the first chance to register itself, and let PR register if we can't >> do HV. >> >> How does that sound? > > As long as we can force-load the PR one on a machine that normally runs > HV for the sake of testing ... This is what I currently have [root@llmp24l02 kvm]# insmod ./kvm-hv.ko [root@llmp24l02 kvm]# insmod ./kvm-pr.ko insmod: ERROR: could not insert module ./kvm-pr.ko: File exists [root@llmp24l02 kvm]# rmmod kvm-hv [root@llmp24l02 kvm]# insmod ./kvm-pr.ko [root@llmp24l02 kvm]# So if by force load you mean rmmod kvm-hv and then modprobe kvm-pr that works. But loading kvm-pr along side kvm-hv is not supported. My understanding was we didn't want to allow that because that can confuse users when they are not sure whether it is hv or pr kvm they are using. -aneesh -- 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
[no subject]
Can anyone please let me know links providing \ info about ongoing/future kvm feature \ development?is the todo list in the main page upto date? -- 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
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
On Sat, Sep 14, 2013 at 07:14:02AM -0500, Alexander Graf wrote: > > > Am 14.09.2013 um 07:10 schrieb Andrew Jones : > > > Signed-off-by: Andrew Jones > > --- > > arch/arm/kvm/arm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c > > index 741f66a2edbd7..9ebf8ac3a12ff 100644 > > --- a/arch/arm/kvm/arm.c > > +++ b/arch/arm/kvm/arm.c > > @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) > >r = 1; > >break; > >case KVM_CAP_NR_VCPUS: > > -r = num_online_cpus(); > > +r = min(num_online_cpus(), KVM_MAX_VCPUS); > > Is there any real reason to prohibit overcommit? This doesn't prohibit it. Users can attempt to configure anything they'd like, but only selections KVM_MAX_VCPUS and below will work. drew > > Alex > > >break; > >case KVM_CAP_MAX_VCPUS: > >r = KVM_MAX_VCPUS; > > -- > > 1.8.1.4 > > > > ___ > > kvmarm mailing list > > kvm...@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- 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
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
On 2013-09-14 13:14, Alexander Graf wrote: Am 14.09.2013 um 07:10 schrieb Andrew Jones : Signed-off-by: Andrew Jones --- arch/arm/kvm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index 741f66a2edbd7..9ebf8ac3a12ff 100644 --- a/arch/arm/kvm/arm.c +++ b/arch/arm/kvm/arm.c @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; case KVM_CAP_NR_VCPUS: -r = num_online_cpus(); +r = min(num_online_cpus(), KVM_MAX_VCPUS); Is there any real reason to prohibit overcommit? I don't think this affects overcommit. This is the "recommended" limit, and you can still go up to KVM_MAX_CPUS. M. -- Fast, cheap, reliable. Pick two. -- 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
[PATCH] x86: kvm: introduce CONFIG_KVM_MAX_VCPUS
Take CONFIG_KVM_MAX_VCPUS from arm32, but set the default to 255. Signed-off-by: Andrew Jones --- arch/x86/include/asm/kvm_host.h | 5 +++-- arch/x86/kvm/Kconfig| 10 ++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index c76ff74a98f2e..e7e9b523a8f7e 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -31,8 +31,9 @@ #include #include -#define KVM_MAX_VCPUS 255 -#define KVM_SOFT_MAX_VCPUS 160 +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS +#define KVM_SOFT_MAX_VCPUS min(160, KVM_MAX_VCPUS) + #define KVM_USER_MEM_SLOTS 125 /* memory slots that are not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 3 diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index a47a3e54b964b..e9532c33527ee 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -52,6 +52,16 @@ config KVM If unsure, say N. +config KVM_MAX_VCPUS + int "Number maximum supported virtual CPUs per VM" + depends on KVM + default 255 + help + Static number of max supported virtual CPUs per VM. + + Set to a lower number to save some resources. Set to a higher + number to test scalability. + config KVM_INTEL tristate "KVM for Intel processors support" depends on KVM -- 1.8.1.4 -- 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
[PATCH] [RFC] x86: kvm: remove KVM_SOFT_MAX_VCPUS
This patch removes KVM_SOFT_MAX_VCPUS and uses num_online_cpus() for KVM_CAP_NR_VCPUS instead, as ARM does. While the API doc simply says KVM_CAP_NR_VCPUS should return the recommended maximum number of vcpus, it has been returning KVM_SOFT_MAX_VCPUS, which was defined as the maximum tested number of vcpus. As that concept could be distro-specific, this patch uses the other recommended maximum, the number of physical cpus, as we never recommend configuring a guest that has more vcpus than the host has pcpus. Of course a guest can always still be configured with up to KVM_CAP_MAX_VCPUS though anyway. I've put RFC on this patch because I'm not sure if there are any gotchas lurking with this change. The change now means hosts no longer return the same number for KVM_CAP_NR_VCPUS, and that number is likely going to generally be quite a bit less than what KVM_SOFT_MAX_VCPUS was (160). I can't think of anything other than generating more warnings[1] from qemu with guests that configure more vcpus than pcpus though. [1] Actually, until 972fc544b6034a in uq/master is merged there won't be any warnings either. Signed-off-by: Andrew Jones --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/x86.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index c76ff74a98f2e..9236c63315a9b 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -32,7 +32,6 @@ #include #define KVM_MAX_VCPUS 255 -#define KVM_SOFT_MAX_VCPUS 160 #define KVM_USER_MEM_SLOTS 125 /* memory slots that are not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 3 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e5ca72a5cdb6d..d9d3e2ed68ee9 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2604,7 +2604,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = !kvm_x86_ops->cpu_has_accelerated_tpr(); break; case KVM_CAP_NR_VCPUS: - r = KVM_SOFT_MAX_VCPUS; + r = min(num_online_cpus(), KVM_MAX_VCPUS); break; case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; -- 1.8.1.4 -- 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
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
Am 14.09.2013 um 07:10 schrieb Andrew Jones : > Signed-off-by: Andrew Jones > --- > arch/arm/kvm/arm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c > index 741f66a2edbd7..9ebf8ac3a12ff 100644 > --- a/arch/arm/kvm/arm.c > +++ b/arch/arm/kvm/arm.c > @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) >r = 1; >break; >case KVM_CAP_NR_VCPUS: > -r = num_online_cpus(); > +r = min(num_online_cpus(), KVM_MAX_VCPUS); Is there any real reason to prohibit overcommit? Alex >break; >case KVM_CAP_MAX_VCPUS: >r = KVM_MAX_VCPUS; > -- > 1.8.1.4 > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- 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
[PATCH 0/3] KVM_MAX_VCPUS related changes
Andrew Jones (3): arm: kvm: clamp NR_VCPUS to MAX_VCPUS arm32: kvm: rename CONFIG_KVM_ARM_MAX_VCPUS aarch64: kvm: introduce CONFIG_KVM_MAX_VCPUS arch/arm/include/asm/kvm_host.h | 4 ++-- arch/arm/kvm/Kconfig | 8 arch/arm/kvm/arm.c| 2 +- arch/arm64/include/asm/kvm_host.h | 7 ++- arch/arm64/kvm/Kconfig| 11 +++ 5 files changed, 24 insertions(+), 8 deletions(-) -- 1.8.1.4 -- 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
[PATCH 2/3] arm32: kvm: rename CONFIG_KVM_ARM_MAX_VCPUS
Drop the _ARM_ part of the name. We can then introduce a config option like this to aarch64 and other arches using the same name - allowing grep to show them all. Also update the help text to describe the option more completely. Signed-off-by: Andrew Jones --- arch/arm/include/asm/kvm_host.h | 4 ++-- arch/arm/kvm/Kconfig| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index 7d22517d80711..c614d3eb176c6 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -25,8 +25,8 @@ #include #include -#if defined(CONFIG_KVM_ARM_MAX_VCPUS) -#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS +#if defined(CONFIG_KVM_MAX_VCPUS) +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS #else #define KVM_MAX_VCPUS 0 #endif diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index ebf5015508b52..de63bfccb3eb5 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -40,16 +40,16 @@ config KVM_ARM_HOST ---help--- Provides host support for ARM processors. -config KVM_ARM_MAX_VCPUS +config KVM_MAX_VCPUS int "Number maximum supported virtual CPUs per VM" depends on KVM_ARM_HOST default 4 help Static number of max supported virtual CPUs per VM. - If you choose a high number, the vcpu structures will be quite - large, so only choose a reasonable number that you expect to - actually use. + The default is set to the highest number of vcpus that + current hardware supports. Set to a lower number to save + some resources. Set to a higher number to test scalability. config KVM_ARM_VGIC bool "KVM support for Virtual GIC" -- 1.8.1.4 -- 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
[PATCH 3/3] aarch64: kvm: introduce CONFIG_KVM_MAX_VCPUS
Take CONFIG_KVM_MAX_VCPUS from arm32, but set the default to 8. Signed-off-by: Andrew Jones --- arch/arm64/include/asm/kvm_host.h | 7 ++- arch/arm64/kvm/Kconfig| 11 +++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 0859a4ddd1e7d..d1af8c49a5ca4 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -26,7 +26,12 @@ #include #include -#define KVM_MAX_VCPUS 4 +#if defined(CONFIG_KVM_MAX_VCPUS) +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS +#else +#define KVM_MAX_VCPUS 0 +#endif + #define KVM_USER_MEM_SLOTS 32 #define KVM_PRIVATE_MEM_SLOTS 4 #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 21e90820bd23c..c9924b02e84f7 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -35,6 +35,17 @@ config KVM_ARM_HOST ---help--- Provides host support for ARM processors. +config KVM_MAX_VCPUS + int "Number maximum supported virtual CPUs per VM" + depends on KVM_ARM_HOST + default 8 + help + Static number of max supported virtual CPUs per VM. + + The default is set to the highest number of vcpus that + current hardware supports. Set to a lower number to save + some resources. Set to a higher number to test scalability. + config KVM_ARM_VGIC bool depends on KVM_ARM_HOST && OF -- 1.8.1.4 -- 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
[PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
Signed-off-by: Andrew Jones --- arch/arm/kvm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index 741f66a2edbd7..9ebf8ac3a12ff 100644 --- a/arch/arm/kvm/arm.c +++ b/arch/arm/kvm/arm.c @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; case KVM_CAP_NR_VCPUS: - r = num_online_cpus(); + r = min(num_online_cpus(), KVM_MAX_VCPUS); break; case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; -- 1.8.1.4 -- 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
Re: [PATCH 04/11] KVM: PPC: Book3S HV: Add GET/SET_ONE_REG interface for LPCR
Am 14.09.2013 um 00:58 schrieb Paul Mackerras : > On Sat, Sep 14, 2013 at 12:12:43AM -0500, Alexander Graf wrote: >> >> >> Am 13.09.2013 um 21:21 schrieb Paul Mackerras : >> >>> In hardware there is in fact an LPCR per hardware CPU thread, though >>> the architecture says that on threaded processors many of the fields >>> have to be the same on each thread, including the three fields >>> mentioned here. >> >> Ok. Is it mandatory to be identical per core? Or per vm? > > Per core. Then put it into the vcore struct like you put everything else with core wide scope, no? :) Alex > > Paul. -- 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
Re: [PATCH v4] KVM: nVMX: Fully support of nested VMX preemption timer
On 2013-09-13 19:15, Paolo Bonzini wrote: > Il 06/09/2013 04:04, Arthur Chunqi Li ha scritto: >> +preempt_val_l1 = delta_tsc_l1 >> preempt_scale; >> +if (preempt_val_l2 <= preempt_val_l1) >> +preempt_val_l2 = 0; >> +else >> +preempt_val_l2 -= preempt_val_l1; >> +vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, preempt_val_l2); > > Did you test that a value of 0 triggers an immediate exit, rather than > counting down by 2^32? Perhaps it's safer to limit the value to 1 > instead of 0. To my experience, 0 triggers immediate exists when the preemption timer is enabled. Jan signature.asc Description: OpenPGP digital signature
