[PATCH v3 0/2] kvm: limited x86 CPU power management

[PATCH v3 0/2] kvm: limited x86 CPU power management

[Michael S. Tsirkin]

This adds ability to expose some host CPU power management capabilities
to guests. For intel guests, this is sufficient for guest to enable low
power CPU states on idle. For AMD guests it isn't sufficient, deeper
C-states are entered using System-IO.

When enabled this puts CPU in a low power state with exit latencies that
can go up to multiple milliseconds, and makes host scheduler as well as
host utilities such as top and powertop think the CPU is constantly
busy.  Thus it has the effect of dedicating a host CPU for this guest.

mwait based power management is tied closely to specifics of CPUID,
making migration challenging. At this point only the non-migrateable
-cpu host is supported.

With this patch applied, VM latency is within the noise of
baremetal for some benchmarks.

perf bench sched pipe results:
Before:
    6.452 sec
After:
    4.382 sec
Baremetal:
    4.136 sec

Changes since v2:
    At Daniel's suggestion, don't use the -realtime flag.

    At Paolo's suggestion, group this with memory lock flag
    which has a similar effect of dedicating memory to this VM.

Michael S. Tsirkin (2):
  kvm: support -dedicated cpu-pm=on|off
  i386/cpu: make -cpu host support monitor/mwait

 include/sysemu/sysemu.h |  1 +
 target/i386/cpu.h       |  9 +++++++++
 target/i386/cpu.c       | 19 ++++++++++++++-----
 target/i386/kvm.c       | 32 ++++++++++++++++++++++++++++++++
 vl.c                    | 32 +++++++++++++++++++++++++++++++-
 qemu-options.hx         | 18 ++++++++++++++++++
 6 files changed, 105 insertions(+), 6 deletions(-)

-- 
MST

[Qemu-devel] [PATCH v3 0/2] kvm: limited x86 CPU power management

[Michael S. Tsirkin]

This adds ability to expose some host CPU power management capabilities
to guests. For intel guests, this is sufficient for guest to enable low
power CPU states on idle. For AMD guests it isn't sufficient, deeper
C-states are entered using System-IO.

When enabled this puts CPU in a low power state with exit latencies that
can go up to multiple milliseconds, and makes host scheduler as well as
host utilities such as top and powertop think the CPU is constantly
busy.  Thus it has the effect of dedicating a host CPU for this guest.

mwait based power management is tied closely to specifics of CPUID,
making migration challenging. At this point only the non-migrateable
-cpu host is supported.

With this patch applied, VM latency is within the noise of
baremetal for some benchmarks.

perf bench sched pipe results:
Before:
    6.452 sec
After:
    4.382 sec
Baremetal:
    4.136 sec

Changes since v2:
    At Daniel's suggestion, don't use the -realtime flag.

    At Paolo's suggestion, group this with memory lock flag
    which has a similar effect of dedicating memory to this VM.

Michael S. Tsirkin (2):
  kvm: support -dedicated cpu-pm=on|off
  i386/cpu: make -cpu host support monitor/mwait

 include/sysemu/sysemu.h |  1 +
 target/i386/cpu.h       |  9 +++++++++
 target/i386/cpu.c       | 19 ++++++++++++++-----
 target/i386/kvm.c       | 32 ++++++++++++++++++++++++++++++++
 vl.c                    | 32 +++++++++++++++++++++++++++++++-
 qemu-options.hx         | 18 ++++++++++++++++++
 6 files changed, 105 insertions(+), 6 deletions(-)

-- 
MST

[PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

With this flag, kvm allows guest to control host CPU power state.  This
increases latency for other processes using same host CPU in an
unpredictable way, but if decreases idle entry/exit times for the
running VCPU, so it works best if you use a dedicated host cpu,
hence the name.

Follow-up patches will expose this capability to guest
(using mwait leaf).

Based on a patch by Wanpeng Li <kernellwp@gmail.com> .

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/sysemu/sysemu.h |  1 +
 target/i386/kvm.c       | 23 +++++++++++++++++++++++
 vl.c                    | 32 +++++++++++++++++++++++++++++++-
 qemu-options.hx         | 18 ++++++++++++++++++
 4 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index e893f72f3b..b921c6f3b7 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -128,6 +128,7 @@ extern bool boot_strict;
 extern uint8_t *boot_splash_filedata;
 extern size_t boot_splash_filedata_size;
 extern bool enable_mlock;
+extern bool enable_cpu_pm;
 extern uint8_t qemu_extra_params_fw[2];
 extern QEMUClockType rtc_clock;
 extern const char *mem_path;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 44f70733e7..cf9107be4b 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1357,6 +1357,29 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
         smram_machine_done.notify = register_smram_listener;
         qemu_add_machine_init_done_notifier(&smram_machine_done);
     }
+
+    if (enable_cpu_pm) {
+        int disable_exits = kvm_check_extension(s, KVM_CAP_X86_DISABLE_EXITS);
+        int ret;
+
+/* Work around for kernel header with a typo. TODO: fix header and drop. */
+#if defined(KVM_X86_DISABLE_EXITS_HTL) && !defined(KVM_X86_DISABLE_EXITS_HLT)
+#define KVM_X86_DISABLE_EXITS_HLT KVM_X86_DISABLE_EXITS_HTL
+#endif
+        if (disable_exits) {
+            disable_exits &= (KVM_X86_DISABLE_EXITS_MWAIT |
+                              KVM_X86_DISABLE_EXITS_HLT |
+                              KVM_X86_DISABLE_EXITS_PAUSE);
+        }
+
+        ret = kvm_vm_enable_cap(s, KVM_CAP_X86_DISABLE_EXITS, 0,
+                                disable_exits);
+        if (ret < 0) {
+            error_report("kvm: guest stopping CPU not supported: %s",
+                         strerror(-ret));
+        }
+    }
+
     return 0;
 }
 
diff --git a/vl.c b/vl.c
index 06031715ac..d53a9abcde 100644
--- a/vl.c
+++ b/vl.c
@@ -142,6 +142,7 @@ ram_addr_t ram_size;
 const char *mem_path = NULL;
 int mem_prealloc = 0; /* force preallocation of physical target memory */
 bool enable_mlock = false;
+bool enable_cpu_pm = false;
 int nb_nics;
 NICInfo nd_table[MAX_NICS];
 int autostart;
@@ -390,6 +391,22 @@ static QemuOptsList qemu_realtime_opts = {
     },
 };
 
+static QemuOptsList qemu_dedicated_opts = {
+    .name = "dedicated",
+    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
+    .desc = {
+        {
+            .name = "mem-lock",
+            .type = QEMU_OPT_BOOL,
+        },
+        {
+            .name = "cpu-pm",
+            .type = QEMU_OPT_BOOL,
+        },
+        { /* end of list */ }
+    },
+};
+
 static QemuOptsList qemu_msg_opts = {
     .name = "msg",
     .head = QTAILQ_HEAD_INITIALIZER(qemu_msg_opts.head),
@@ -3903,7 +3920,20 @@ int main(int argc, char **argv, char **envp)
                 if (!opts) {
                     exit(1);
                 }
-                enable_mlock = qemu_opt_get_bool(opts, "mlock", true);
+                /* Don't override the -dedicated option if set */
+                enable_mlock = enable_mlock ||
+                    qemu_opt_get_bool(opts, "mlock", true);
+                break;
+            case QEMU_OPTION_dedicated:
+                opts = qemu_opts_parse_noisily(qemu_find_opts("dedicated"),
+                                               optarg, false);
+                if (!opts) {
+                    exit(1);
+                }
+                /* Don't override the -realtime option if set */
+                enable_mlock = enable_mlock ||
+                    qemu_opt_get_bool(opts, "mem-lock", false);
+                enable_cpu_pm = qemu_opt_get_bool(opts, "cpu-pm", false);
                 break;
             case QEMU_OPTION_msg:
                 opts = qemu_opts_parse_noisily(qemu_find_opts("msg"), optarg,
diff --git a/qemu-options.hx b/qemu-options.hx
index c0d3951e9f..ddedb7eb92 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3337,6 +3337,24 @@ mlocking qemu and guest memory can be enabled via @option{mlock=on}
 (enabled by default).
 ETEXI
 
+DEF("dedicated", HAS_ARG, QEMU_OPTION_dedicated,
+    "-dedicated [mem-lock=on|off][cpu-pm=on|off]\n"
+    "                run qemu with realtime features\n"
+    "                mem-lock=on|off controls memory lock support (default: off)\n"
+    "                cpu-pm=on|off controls cpu power management (default: off)\n",
+    QEMU_ARCH_ALL)
+STEXI
+@item -dedicated mem-lock=on|off
+@item -dedicated cpu-pm=on|off
+@findex -dedicated
+Run qemu using dedicated host resources.
+Locking qemu and guest memory can be enabled via @option{mem-lock=on}
+(disabled by default). This is equivalent to @option{realtime}.
+Guest ability to manage power state of host cpus (increasing latency for other
+processes on the same host cpu, but decreasing latency for guest)
+can be enabled via @option{cpu-pm=on} (disabled by default).
+ETEXI
+
 DEF("gdb", HAS_ARG, QEMU_OPTION_gdb, \
     "-gdb dev        wait for gdb connection on 'dev'\n", QEMU_ARCH_ALL)
 STEXI
-- 
MST

[Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

With this flag, kvm allows guest to control host CPU power state.  This
increases latency for other processes using same host CPU in an
unpredictable way, but if decreases idle entry/exit times for the
running VCPU, so it works best if you use a dedicated host cpu,
hence the name.

Follow-up patches will expose this capability to guest
(using mwait leaf).

Based on a patch by Wanpeng Li <kernellwp@gmail.com> .

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/sysemu/sysemu.h |  1 +
 target/i386/kvm.c       | 23 +++++++++++++++++++++++
 vl.c                    | 32 +++++++++++++++++++++++++++++++-
 qemu-options.hx         | 18 ++++++++++++++++++
 4 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index e893f72f3b..b921c6f3b7 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -128,6 +128,7 @@ extern bool boot_strict;
 extern uint8_t *boot_splash_filedata;
 extern size_t boot_splash_filedata_size;
 extern bool enable_mlock;
+extern bool enable_cpu_pm;
 extern uint8_t qemu_extra_params_fw[2];
 extern QEMUClockType rtc_clock;
 extern const char *mem_path;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 44f70733e7..cf9107be4b 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1357,6 +1357,29 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
         smram_machine_done.notify = register_smram_listener;
         qemu_add_machine_init_done_notifier(&smram_machine_done);
     }
+
+    if (enable_cpu_pm) {
+        int disable_exits = kvm_check_extension(s, KVM_CAP_X86_DISABLE_EXITS);
+        int ret;
+
+/* Work around for kernel header with a typo. TODO: fix header and drop. */
+#if defined(KVM_X86_DISABLE_EXITS_HTL) && !defined(KVM_X86_DISABLE_EXITS_HLT)
+#define KVM_X86_DISABLE_EXITS_HLT KVM_X86_DISABLE_EXITS_HTL
+#endif
+        if (disable_exits) {
+            disable_exits &= (KVM_X86_DISABLE_EXITS_MWAIT |
+                              KVM_X86_DISABLE_EXITS_HLT |
+                              KVM_X86_DISABLE_EXITS_PAUSE);
+        }
+
+        ret = kvm_vm_enable_cap(s, KVM_CAP_X86_DISABLE_EXITS, 0,
+                                disable_exits);
+        if (ret < 0) {
+            error_report("kvm: guest stopping CPU not supported: %s",
+                         strerror(-ret));
+        }
+    }
+
     return 0;
 }
 
diff --git a/vl.c b/vl.c
index 06031715ac..d53a9abcde 100644
--- a/vl.c
+++ b/vl.c
@@ -142,6 +142,7 @@ ram_addr_t ram_size;
 const char *mem_path = NULL;
 int mem_prealloc = 0; /* force preallocation of physical target memory */
 bool enable_mlock = false;
+bool enable_cpu_pm = false;
 int nb_nics;
 NICInfo nd_table[MAX_NICS];
 int autostart;
@@ -390,6 +391,22 @@ static QemuOptsList qemu_realtime_opts = {
     },
 };
 
+static QemuOptsList qemu_dedicated_opts = {
+    .name = "dedicated",
+    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
+    .desc = {
+        {
+            .name = "mem-lock",
+            .type = QEMU_OPT_BOOL,
+        },
+        {
+            .name = "cpu-pm",
+            .type = QEMU_OPT_BOOL,
+        },
+        { /* end of list */ }
+    },
+};
+
 static QemuOptsList qemu_msg_opts = {
     .name = "msg",
     .head = QTAILQ_HEAD_INITIALIZER(qemu_msg_opts.head),
@@ -3903,7 +3920,20 @@ int main(int argc, char **argv, char **envp)
                 if (!opts) {
                     exit(1);
                 }
-                enable_mlock = qemu_opt_get_bool(opts, "mlock", true);
+                /* Don't override the -dedicated option if set */
+                enable_mlock = enable_mlock ||
+                    qemu_opt_get_bool(opts, "mlock", true);
+                break;
+            case QEMU_OPTION_dedicated:
+                opts = qemu_opts_parse_noisily(qemu_find_opts("dedicated"),
+                                               optarg, false);
+                if (!opts) {
+                    exit(1);
+                }
+                /* Don't override the -realtime option if set */
+                enable_mlock = enable_mlock ||
+                    qemu_opt_get_bool(opts, "mem-lock", false);
+                enable_cpu_pm = qemu_opt_get_bool(opts, "cpu-pm", false);
                 break;
             case QEMU_OPTION_msg:
                 opts = qemu_opts_parse_noisily(qemu_find_opts("msg"), optarg,
diff --git a/qemu-options.hx b/qemu-options.hx
index c0d3951e9f..ddedb7eb92 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3337,6 +3337,24 @@ mlocking qemu and guest memory can be enabled via @option{mlock=on}
 (enabled by default).
 ETEXI
 
+DEF("dedicated", HAS_ARG, QEMU_OPTION_dedicated,
+    "-dedicated [mem-lock=on|off][cpu-pm=on|off]\n"
+    "                run qemu with realtime features\n"
+    "                mem-lock=on|off controls memory lock support (default: off)\n"
+    "                cpu-pm=on|off controls cpu power management (default: off)\n",
+    QEMU_ARCH_ALL)
+STEXI
+@item -dedicated mem-lock=on|off
+@item -dedicated cpu-pm=on|off
+@findex -dedicated
+Run qemu using dedicated host resources.
+Locking qemu and guest memory can be enabled via @option{mem-lock=on}
+(disabled by default). This is equivalent to @option{realtime}.
+Guest ability to manage power state of host cpus (increasing latency for other
+processes on the same host cpu, but decreasing latency for guest)
+can be enabled via @option{cpu-pm=on} (disabled by default).
+ETEXI
+
 DEF("gdb", HAS_ARG, QEMU_OPTION_gdb, \
     "-gdb dev        wait for gdb connection on 'dev'\n", QEMU_ARCH_ALL)
 STEXI
-- 
MST

[PATCH v3 2/2] i386/cpu: make -cpu host support monitor/mwait

[Michael S. Tsirkin]

When guest CPU PM is enabled, and with -cpu host, expose the host CPU
MWAIT leaf in the CPUID so guest can make good PM decisions.

Note: the result is 100% CPU utilization reported by host as host
no longer knows that the CPU is halted.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 target/i386/cpu.h |  9 +++++++++
 target/i386/cpu.c | 19 ++++++++++++++-----
 target/i386/kvm.c |  9 +++++++++
 3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 664504610e..309f804573 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1378,6 +1378,15 @@ struct X86CPU {
     /* if true the CPUID code directly forward host cache leaves to the guest */
     bool cache_info_passthrough;
 
+    /* if true the CPUID code directly forwards
+     * host monitor/mwait leaves to the guest */
+    struct {
+        uint32_t eax;
+        uint32_t ebx;
+        uint32_t ecx;
+        uint32_t edx;
+    } mwait;
+
     /* Features that were filtered out because of missing host capabilities */
     uint32_t filtered_features[FEATURE_WORDS];
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 94260412e2..a4fb856d58 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3760,11 +3760,11 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         }
         break;
     case 5:
-        /* mwait info: needed for Core compatibility */
-        *eax = 0; /* Smallest monitor-line size in bytes */
-        *ebx = 0; /* Largest monitor-line size in bytes */
-        *ecx = CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
-        *edx = 0;
+        /* MONITOR/MWAIT Leaf */
+        *eax = cpu->mwait.eax; /* Smallest monitor-line size in bytes */
+        *ebx = cpu->mwait.ebx; /* Largest monitor-line size in bytes */
+        *ecx = cpu->mwait.ecx; /* flags */
+        *edx = cpu->mwait.edx; /* mwait substates */
         break;
     case 6:
         /* Thermal and Power Leaf */
@@ -4595,6 +4595,15 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
         goto out;
     }
 
+    if (xcc->host_cpuid_required && enable_cpu_pm) {
+        host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx,
+                   &cpu->mwait.ecx, &cpu->mwait.edx);
+        env->features[FEAT_1_ECX] |= CPUID_EXT_MONITOR;
+    }
+    /* mwait extended info: needed for Core compatibility */
+    /* We always wake on interrupt even if host does not have the capability */
+    cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
+
     if (cpu->apic_id == UNASSIGNED_APIC_ID) {
         error_setg(errp, "apic-id property was not initialized properly");
         return;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index cf9107be4b..805968d5b7 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -366,6 +366,15 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
         if (!kvm_irqchip_in_kernel()) {
             ret &= ~CPUID_EXT_X2APIC;
         }
+
+        if (enable_cpu_pm) {
+            int disable_exits = kvm_check_extension(s,
+                                                    KVM_CAP_X86_DISABLE_EXITS);
+
+            if (disable_exits & KVM_X86_DISABLE_EXITS_MWAIT) {
+                ret |= CPUID_EXT_MONITOR;
+            }
+        }
     } else if (function == 6 && reg == R_EAX) {
         ret |= CPUID_6_EAX_ARAT; /* safe to allow because of emulated APIC */
     } else if (function == 7 && index == 0 && reg == R_EBX) {
-- 
MST

[Qemu-devel] [PATCH v3 2/2] i386/cpu: make -cpu host support monitor/mwait

[Michael S. Tsirkin]

When guest CPU PM is enabled, and with -cpu host, expose the host CPU
MWAIT leaf in the CPUID so guest can make good PM decisions.

Note: the result is 100% CPU utilization reported by host as host
no longer knows that the CPU is halted.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 target/i386/cpu.h |  9 +++++++++
 target/i386/cpu.c | 19 ++++++++++++++-----
 target/i386/kvm.c |  9 +++++++++
 3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 664504610e..309f804573 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1378,6 +1378,15 @@ struct X86CPU {
     /* if true the CPUID code directly forward host cache leaves to the guest */
     bool cache_info_passthrough;
 
+    /* if true the CPUID code directly forwards
+     * host monitor/mwait leaves to the guest */
+    struct {
+        uint32_t eax;
+        uint32_t ebx;
+        uint32_t ecx;
+        uint32_t edx;
+    } mwait;
+
     /* Features that were filtered out because of missing host capabilities */
     uint32_t filtered_features[FEATURE_WORDS];
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 94260412e2..a4fb856d58 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3760,11 +3760,11 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         }
         break;
     case 5:
-        /* mwait info: needed for Core compatibility */
-        *eax = 0; /* Smallest monitor-line size in bytes */
-        *ebx = 0; /* Largest monitor-line size in bytes */
-        *ecx = CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
-        *edx = 0;
+        /* MONITOR/MWAIT Leaf */
+        *eax = cpu->mwait.eax; /* Smallest monitor-line size in bytes */
+        *ebx = cpu->mwait.ebx; /* Largest monitor-line size in bytes */
+        *ecx = cpu->mwait.ecx; /* flags */
+        *edx = cpu->mwait.edx; /* mwait substates */
         break;
     case 6:
         /* Thermal and Power Leaf */
@@ -4595,6 +4595,15 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
         goto out;
     }
 
+    if (xcc->host_cpuid_required && enable_cpu_pm) {
+        host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx,
+                   &cpu->mwait.ecx, &cpu->mwait.edx);
+        env->features[FEAT_1_ECX] |= CPUID_EXT_MONITOR;
+    }
+    /* mwait extended info: needed for Core compatibility */
+    /* We always wake on interrupt even if host does not have the capability */
+    cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
+
     if (cpu->apic_id == UNASSIGNED_APIC_ID) {
         error_setg(errp, "apic-id property was not initialized properly");
         return;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index cf9107be4b..805968d5b7 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -366,6 +366,15 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
         if (!kvm_irqchip_in_kernel()) {
             ret &= ~CPUID_EXT_X2APIC;
         }
+
+        if (enable_cpu_pm) {
+            int disable_exits = kvm_check_extension(s,
+                                                    KVM_CAP_X86_DISABLE_EXITS);
+
+            if (disable_exits & KVM_X86_DISABLE_EXITS_MWAIT) {
+                ret |= CPUID_EXT_MONITOR;
+            }
+        }
     } else if (function == 6 && reg == R_EAX) {
         ret |= CPUID_6_EAX_ARAT; /* safe to allow because of emulated APIC */
     } else if (function == 7 && index == 0 && reg == R_EBX) {
-- 
MST

Re: [PATCH v3 0/2] kvm: limited x86 CPU power management

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180615222855.44421-1-mst@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/2] kvm: limited x86 CPU power management

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]               patchew/20180615222855.44421-1-mst@redhat.com -> patchew/20180615222855.44421-1-mst@redhat.com
Switched to a new branch 'test'
ec6f28cbc9 i386/cpu: make -cpu host support monitor/mwait
8df4beb5c5 kvm: support -dedicated cpu-pm=on|off

=== OUTPUT BEGIN ===
Checking PATCH 1/2: kvm: support -dedicated cpu-pm=on|off...
ERROR: do not initialise globals to 0 or NULL
#103: FILE: vl.c:145:
+bool enable_cpu_pm = false;

total: 1 errors, 0 warnings, 110 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/2: i386/cpu: make -cpu host support monitor/mwait...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Re: [Qemu-devel] [PATCH v3 0/2] kvm: limited x86 CPU power management

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180615222855.44421-1-mst@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/2] kvm: limited x86 CPU power management

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]               patchew/20180615222855.44421-1-mst@redhat.com -> patchew/20180615222855.44421-1-mst@redhat.com
Switched to a new branch 'test'
ec6f28cbc9 i386/cpu: make -cpu host support monitor/mwait
8df4beb5c5 kvm: support -dedicated cpu-pm=on|off

=== OUTPUT BEGIN ===
Checking PATCH 1/2: kvm: support -dedicated cpu-pm=on|off...
ERROR: do not initialise globals to 0 or NULL
#103: FILE: vl.c:145:
+bool enable_cpu_pm = false;

total: 1 errors, 0 warnings, 110 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/2: i386/cpu: make -cpu host support monitor/mwait...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 16/06/2018 00:29, Michael S. Tsirkin wrote:
>  
> +static QemuOptsList qemu_dedicated_opts = {
> +    .name = "dedicated",
> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> +    .desc = {
> +        {
> +            .name = "mem-lock",
> +            .type = QEMU_OPT_BOOL,
> +        },
> +        {
> +            .name = "cpu-pm",
> +            .type = QEMU_OPT_BOOL,
> +        },
> +        { /* end of list */ }
> +    },
> +};
> +

Let the bikeshedding begin!

1) Should we deprecate -realtime?

2) Maybe -hostresource?

Paolo

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 16/06/2018 00:29, Michael S. Tsirkin wrote:
>  
> +static QemuOptsList qemu_dedicated_opts = {
> +    .name = "dedicated",
> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> +    .desc = {
> +        {
> +            .name = "mem-lock",
> +            .type = QEMU_OPT_BOOL,
> +        },
> +        {
> +            .name = "cpu-pm",
> +            .type = QEMU_OPT_BOOL,
> +        },
> +        { /* end of list */ }
> +    },
> +};
> +

Let the bikeshedding begin!

1) Should we deprecate -realtime?

2) Maybe -hostresource?

Paolo

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Tue, Jun 19, 2018 at 05:17:45PM +0200, Paolo Bonzini wrote:
> On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> >  
> > +static QemuOptsList qemu_dedicated_opts = {
> > +    .name = "dedicated",
> > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > +    .desc = {
> > +        {
> > +            .name = "mem-lock",
> > +            .type = QEMU_OPT_BOOL,
> > +        },
> > +        {
> > +            .name = "cpu-pm",
> > +            .type = QEMU_OPT_BOOL,
> > +        },
> > +        { /* end of list */ }
> > +    },
> > +};
> > +
> 
> Let the bikeshedding begin!
> 
> 1) Should we deprecate -realtime?

Can be a patch on top, by whoever cares.

> 2) Maybe -hostresource?
> 
> Paolo

Is ability to cause high latency for other threads really a resource?

The issues in question:
1. a malicious guest can cause high latency for others sharing the host cpu.
2. to host scheduler cpu looks busier than it really is.

All are avoided if you use a dedicated host cpu, and 2 will
help scheduler get closer to giving you one.


-- 
MST

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Tue, Jun 19, 2018 at 05:17:45PM +0200, Paolo Bonzini wrote:
> On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> >  
> > +static QemuOptsList qemu_dedicated_opts = {
> > +    .name = "dedicated",
> > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > +    .desc = {
> > +        {
> > +            .name = "mem-lock",
> > +            .type = QEMU_OPT_BOOL,
> > +        },
> > +        {
> > +            .name = "cpu-pm",
> > +            .type = QEMU_OPT_BOOL,
> > +        },
> > +        { /* end of list */ }
> > +    },
> > +};
> > +
> 
> Let the bikeshedding begin!
> 
> 1) Should we deprecate -realtime?

Can be a patch on top, by whoever cares.

> 2) Maybe -hostresource?
> 
> Paolo

Is ability to cause high latency for other threads really a resource?

The issues in question:
1. a malicious guest can cause high latency for others sharing the host cpu.
2. to host scheduler cpu looks busier than it really is.

All are avoided if you use a dedicated host cpu, and 2 will
help scheduler get closer to giving you one.


-- 
MST

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Eric Blake]

On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> On 16/06/2018 00:29, Michael S. Tsirkin wrote:
>>   
>> +static QemuOptsList qemu_dedicated_opts = {
>> +    .name = "dedicated",
>> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
>> +    .desc = {
>> +        {
>> +            .name = "mem-lock",
>> +            .type = QEMU_OPT_BOOL,
>> +        },
>> +        {
>> +            .name = "cpu-pm",
>> +            .type = QEMU_OPT_BOOL,
>> +        },
>> +        { /* end of list */ }
>> +    },
>> +};
>> +
> 
> Let the bikeshedding begin!
> 
> 1) Should we deprecate -realtime?
> 
> 2) Maybe -hostresource?

What further things might we add in the future?

-dedicated sounds wrong (it is an adjective, while most of our options 
are nouns - thing -machine, -drive, -object, ...)

-hostresource at least sounds like a noun, but is long to type.  But at 
least '-hostresource cpu-pm=on' reads reasonably well.

About the only other noun I could think of would be '-feature cpu-pm=on'.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Eric Blake]

On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> On 16/06/2018 00:29, Michael S. Tsirkin wrote:
>>   
>> +static QemuOptsList qemu_dedicated_opts = {
>> +    .name = "dedicated",
>> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
>> +    .desc = {
>> +        {
>> +            .name = "mem-lock",
>> +            .type = QEMU_OPT_BOOL,
>> +        },
>> +        {
>> +            .name = "cpu-pm",
>> +            .type = QEMU_OPT_BOOL,
>> +        },
>> +        { /* end of list */ }
>> +    },
>> +};
>> +
> 
> Let the bikeshedding begin!
> 
> 1) Should we deprecate -realtime?
> 
> 2) Maybe -hostresource?

What further things might we add in the future?

-dedicated sounds wrong (it is an adjective, while most of our options 
are nouns - thing -machine, -drive, -object, ...)

-hostresource at least sounds like a noun, but is long to type.  But at 
least '-hostresource cpu-pm=on' reads reasonably well.

About the only other noun I could think of would be '-feature cpu-pm=on'.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > +static QemuOptsList qemu_dedicated_opts = {
> > > +    .name = "dedicated",
> > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > +    .desc = {
> > > +        {
> > > +            .name = "mem-lock",
> > > +            .type = QEMU_OPT_BOOL,
> > > +        },
> > > +        {
> > > +            .name = "cpu-pm",
> > > +            .type = QEMU_OPT_BOOL,
> > > +        },
> > > +        { /* end of list */ }
> > > +    },
> > > +};
> > > +
> > 
> > Let the bikeshedding begin!
> > 
> > 1) Should we deprecate -realtime?
> > 
> > 2) Maybe -hostresource?
> 
> What further things might we add in the future?
> 
> -dedicated sounds wrong (it is an adjective, while most of our options are
> nouns - thing -machine, -drive, -object, ...)
> 
> -hostresource at least sounds like a noun, but is long to type.  But at
> least '-hostresource cpu-pm=on' reads reasonably well.

Yes but host resource what? I feel it says nothing at all about what
one can expect to find in this flag.

> About the only other noun I could think of would be '-feature cpu-pm=on'.

If we have nothing at all to say about what is grouping these things,
we don't need a new flag. We can make it a machine property.

It's user's hint that some host resource is dedicated to a VM.


> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > +static QemuOptsList qemu_dedicated_opts = {
> > > +    .name = "dedicated",
> > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > +    .desc = {
> > > +        {
> > > +            .name = "mem-lock",
> > > +            .type = QEMU_OPT_BOOL,
> > > +        },
> > > +        {
> > > +            .name = "cpu-pm",
> > > +            .type = QEMU_OPT_BOOL,
> > > +        },
> > > +        { /* end of list */ }
> > > +    },
> > > +};
> > > +
> > 
> > Let the bikeshedding begin!
> > 
> > 1) Should we deprecate -realtime?
> > 
> > 2) Maybe -hostresource?
> 
> What further things might we add in the future?
> 
> -dedicated sounds wrong (it is an adjective, while most of our options are
> nouns - thing -machine, -drive, -object, ...)
> 
> -hostresource at least sounds like a noun, but is long to type.  But at
> least '-hostresource cpu-pm=on' reads reasonably well.

Yes but host resource what? I feel it says nothing at all about what
one can expect to find in this flag.

> About the only other noun I could think of would be '-feature cpu-pm=on'.

If we have nothing at all to say about what is grouping these things,
we don't need a new flag. We can make it a machine property.

It's user's hint that some host resource is dedicated to a VM.


> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Wanpeng Li]

On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > +    .name = "dedicated",
> > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > +    .desc = {
> > > > +        {
> > > > +            .name = "mem-lock",
> > > > +            .type = QEMU_OPT_BOOL,
> > > > +        },
> > > > +        {
> > > > +            .name = "cpu-pm",
> > > > +            .type = QEMU_OPT_BOOL,
> > > > +        },
> > > > +        { /* end of list */ }
> > > > +    },
> > > > +};
> > > > +
> > >
> > > Let the bikeshedding begin!
> > >
> > > 1) Should we deprecate -realtime?
> > >
> > > 2) Maybe -hostresource?
> >
> > What further things might we add in the future?
> >
> > -dedicated sounds wrong (it is an adjective, while most of our options are
> > nouns - thing -machine, -drive, -object, ...)
> >
> > -hostresource at least sounds like a noun, but is long to type.  But at
> > least '-hostresource cpu-pm=on' reads reasonably well.
>
> Yes but host resource what? I feel it says nothing at all about what
> one can expect to find in this flag.
>
> > About the only other noun I could think of would be '-feature cpu-pm=on'.
>
> If we have nothing at all to say about what is grouping these things,
> we don't need a new flag. We can make it a machine property.
>
> It's user's hint that some host resource is dedicated to a VM.

The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
KVM_HINTS_REALTIME) should be reverted according to several threads
discussion I think.

Regards,
Wanpeng Li

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Wanpeng Li]

On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > +    .name = "dedicated",
> > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > +    .desc = {
> > > > +        {
> > > > +            .name = "mem-lock",
> > > > +            .type = QEMU_OPT_BOOL,
> > > > +        },
> > > > +        {
> > > > +            .name = "cpu-pm",
> > > > +            .type = QEMU_OPT_BOOL,
> > > > +        },
> > > > +        { /* end of list */ }
> > > > +    },
> > > > +};
> > > > +
> > >
> > > Let the bikeshedding begin!
> > >
> > > 1) Should we deprecate -realtime?
> > >
> > > 2) Maybe -hostresource?
> >
> > What further things might we add in the future?
> >
> > -dedicated sounds wrong (it is an adjective, while most of our options are
> > nouns - thing -machine, -drive, -object, ...)
> >
> > -hostresource at least sounds like a noun, but is long to type.  But at
> > least '-hostresource cpu-pm=on' reads reasonably well.
>
> Yes but host resource what? I feel it says nothing at all about what
> one can expect to find in this flag.
>
> > About the only other noun I could think of would be '-feature cpu-pm=on'.
>
> If we have nothing at all to say about what is grouping these things,
> we don't need a new flag. We can make it a machine property.
>
> It's user's hint that some host resource is dedicated to a VM.

The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
KVM_HINTS_REALTIME) should be reverted according to several threads
discussion I think.

Regards,
Wanpeng Li

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Wed, Jun 20, 2018 at 08:46:10AM +0800, Wanpeng Li wrote:
> On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > > +    .name = "dedicated",
> > > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > > +    .desc = {
> > > > > +        {
> > > > > +            .name = "mem-lock",
> > > > > +            .type = QEMU_OPT_BOOL,
> > > > > +        },
> > > > > +        {
> > > > > +            .name = "cpu-pm",
> > > > > +            .type = QEMU_OPT_BOOL,
> > > > > +        },
> > > > > +        { /* end of list */ }
> > > > > +    },
> > > > > +};
> > > > > +
> > > >
> > > > Let the bikeshedding begin!
> > > >
> > > > 1) Should we deprecate -realtime?
> > > >
> > > > 2) Maybe -hostresource?
> > >
> > > What further things might we add in the future?
> > >
> > > -dedicated sounds wrong (it is an adjective, while most of our options are
> > > nouns - thing -machine, -drive, -object, ...)
> > >
> > > -hostresource at least sounds like a noun, but is long to type.  But at
> > > least '-hostresource cpu-pm=on' reads reasonably well.
> >
> > Yes but host resource what? I feel it says nothing at all about what
> > one can expect to find in this flag.
> >
> > > About the only other noun I could think of would be '-feature cpu-pm=on'.
> >
> > If we have nothing at all to say about what is grouping these things,
> > we don't need a new flag. We can make it a machine property.
> >
> > It's user's hint that some host resource is dedicated to a VM.
> 
> The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
> KVM_HINTS_REALTIME) should be reverted according to several threads
> discussion I think.
> 
> Regards,
> Wanpeng Li

IMHO that is unrelated - these KVM hints are hints to *guest*.

In this thread we are talking about hints to QEMU that are only
necessary because QEMU is separate from the host scheduler/memory
management.

-- 
MST

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Wed, Jun 20, 2018 at 08:46:10AM +0800, Wanpeng Li wrote:
> On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > > +    .name = "dedicated",
> > > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > > +    .desc = {
> > > > > +        {
> > > > > +            .name = "mem-lock",
> > > > > +            .type = QEMU_OPT_BOOL,
> > > > > +        },
> > > > > +        {
> > > > > +            .name = "cpu-pm",
> > > > > +            .type = QEMU_OPT_BOOL,
> > > > > +        },
> > > > > +        { /* end of list */ }
> > > > > +    },
> > > > > +};
> > > > > +
> > > >
> > > > Let the bikeshedding begin!
> > > >
> > > > 1) Should we deprecate -realtime?
> > > >
> > > > 2) Maybe -hostresource?
> > >
> > > What further things might we add in the future?
> > >
> > > -dedicated sounds wrong (it is an adjective, while most of our options are
> > > nouns - thing -machine, -drive, -object, ...)
> > >
> > > -hostresource at least sounds like a noun, but is long to type.  But at
> > > least '-hostresource cpu-pm=on' reads reasonably well.
> >
> > Yes but host resource what? I feel it says nothing at all about what
> > one can expect to find in this flag.
> >
> > > About the only other noun I could think of would be '-feature cpu-pm=on'.
> >
> > If we have nothing at all to say about what is grouping these things,
> > we don't need a new flag. We can make it a machine property.
> >
> > It's user's hint that some host resource is dedicated to a VM.
> 
> The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
> KVM_HINTS_REALTIME) should be reverted according to several threads
> discussion I think.
> 
> Regards,
> Wanpeng Li

IMHO that is unrelated - these KVM hints are hints to *guest*.

In this thread we are talking about hints to QEMU that are only
necessary because QEMU is separate from the host scheduler/memory
management.

-- 
MST

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 19/06/2018 22:43, Michael S. Tsirkin wrote:
> 
>> 2) Maybe -hostresource?
>
> Is ability to cause high latency for other threads really a resource?

The "resource" here is host CPU time.  In general, a vCPU with
KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
overcommitting, just like mlock does for memory.

Paolo

> The issues in question:
> 1. a malicious guest can cause high latency for others sharing the host cpu.
> 2. to host scheduler cpu looks busier than it really is.

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 19/06/2018 22:43, Michael S. Tsirkin wrote:
> 
>> 2) Maybe -hostresource?
>
> Is ability to cause high latency for other threads really a resource?

The "resource" here is host CPU time.  In general, a vCPU with
KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
overcommitting, just like mlock does for memory.

Paolo

> The issues in question:
> 1. a malicious guest can cause high latency for others sharing the host cpu.
> 2. to host scheduler cpu looks busier than it really is.

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Wed, Jun 20, 2018 at 04:20:40PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 22:43, Michael S. Tsirkin wrote:
> > 
> >> 2) Maybe -hostresource?
> >
> > Is ability to cause high latency for other threads really a resource?
> 
> The "resource" here is host CPU time.

Right but then everything we do is a host resource in that sense.
Host network, host disk ...

> In general, a vCPU with
> KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
> overcommitting, just like mlock does for memory.

What bothers me is that it does not block overcommit as such.
It has a side effect that if something does end up
running on the same CPU, that something will get bad
latency jitter. 

> 
> Paolo

I agree there's similarity here around overcommit.

That's why I suggested -dedicated as an antonym to -overcommit.

But I'm fine with -disable-overcommit or -dedicated-host-resource too.

Or, how about

-locked

?


> > The issues in question:
> > 1. a malicious guest can cause high latency for others sharing the host cpu.
> > 2. to host scheduler cpu looks busier than it really is.

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Michael S. Tsirkin]

On Wed, Jun 20, 2018 at 04:20:40PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 22:43, Michael S. Tsirkin wrote:
> > 
> >> 2) Maybe -hostresource?
> >
> > Is ability to cause high latency for other threads really a resource?
> 
> The "resource" here is host CPU time.

Right but then everything we do is a host resource in that sense.
Host network, host disk ...

> In general, a vCPU with
> KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
> overcommitting, just like mlock does for memory.

What bothers me is that it does not block overcommit as such.
It has a side effect that if something does end up
running on the same CPU, that something will get bad
latency jitter. 

> 
> Paolo

I agree there's similarity here around overcommit.

That's why I suggested -dedicated as an antonym to -overcommit.

But I'm fine with -disable-overcommit or -dedicated-host-resource too.

Or, how about

-locked

?


> > The issues in question:
> > 1. a malicious guest can cause high latency for others sharing the host cpu.
> > 2. to host scheduler cpu looks busier than it really is.

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 20/06/2018 16:29, Michael S. Tsirkin wrote:
> On Wed, Jun 20, 2018 at 04:20:40PM +0200, Paolo Bonzini wrote:
>> On 19/06/2018 22:43, Michael S. Tsirkin wrote:
>>>
>>>> 2) Maybe -hostresource?
>>>
>>> Is ability to cause high latency for other threads really a resource?
>>
>> The "resource" here is host CPU time.
> 
> Right but then everything we do is a host resource in that sense.
> Host network, host disk ...

Yes of course.  These options control how (and how much) QEMU uses those
resources.

>> In general, a vCPU with
>> KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
>> overcommitting, just like mlock does for memory.
> 
> What bothers me is that it does not block overcommit as such.
> It has a side effect that if something does end up
> running on the same CPU, that something will get bad
> latency jitter. 
>
> I agree there's similarity here around overcommit.
> 
> That's why I suggested -dedicated as an antonym to -overcommit.
> 
> But I'm fine with -disable-overcommit or -dedicated-host-resource too.

Both of those are quite a mouthful.  I somewhat prefer "-overcommit" to
"-dedicated", though "-hostresource" it's still my favorite mostly
because it's the most future-proof.

Paolo

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Paolo Bonzini]

On 20/06/2018 16:29, Michael S. Tsirkin wrote:
> On Wed, Jun 20, 2018 at 04:20:40PM +0200, Paolo Bonzini wrote:
>> On 19/06/2018 22:43, Michael S. Tsirkin wrote:
>>>
>>>> 2) Maybe -hostresource?
>>>
>>> Is ability to cause high latency for other threads really a resource?
>>
>> The "resource" here is host CPU time.
> 
> Right but then everything we do is a host resource in that sense.
> Host network, host disk ...

Yes of course.  These options control how (and how much) QEMU uses those
resources.

>> In general, a vCPU with
>> KVM_CPU_X86_DISABLE_EXITS will use more host CPU time and block
>> overcommitting, just like mlock does for memory.
> 
> What bothers me is that it does not block overcommit as such.
> It has a side effect that if something does end up
> running on the same CPU, that something will get bad
> latency jitter. 
>
> I agree there's similarity here around overcommit.
> 
> That's why I suggested -dedicated as an antonym to -overcommit.
> 
> But I'm fine with -disable-overcommit or -dedicated-host-resource too.

Both of those are quite a mouthful.  I somewhat prefer "-overcommit" to
"-dedicated", though "-hostresource" it's still my favorite mostly
because it's the most future-proof.

Paolo

Re: [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Wanpeng Li]

On Wed, 20 Jun 2018 at 10:41, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Jun 20, 2018 at 08:46:10AM +0800, Wanpeng Li wrote:
> > On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > > > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > > > +    .name = "dedicated",
> > > > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > > > +    .desc = {
> > > > > > +        {
> > > > > > +            .name = "mem-lock",
> > > > > > +            .type = QEMU_OPT_BOOL,
> > > > > > +        },
> > > > > > +        {
> > > > > > +            .name = "cpu-pm",
> > > > > > +            .type = QEMU_OPT_BOOL,
> > > > > > +        },
> > > > > > +        { /* end of list */ }
> > > > > > +    },
> > > > > > +};
> > > > > > +
> > > > >
> > > > > Let the bikeshedding begin!
> > > > >
> > > > > 1) Should we deprecate -realtime?
> > > > >
> > > > > 2) Maybe -hostresource?
> > > >
> > > > What further things might we add in the future?
> > > >
> > > > -dedicated sounds wrong (it is an adjective, while most of our options are
> > > > nouns - thing -machine, -drive, -object, ...)
> > > >
> > > > -hostresource at least sounds like a noun, but is long to type.  But at
> > > > least '-hostresource cpu-pm=on' reads reasonably well.
> > >
> > > Yes but host resource what? I feel it says nothing at all about what
> > > one can expect to find in this flag.
> > >
> > > > About the only other noun I could think of would be '-feature cpu-pm=on'.
> > >
> > > If we have nothing at all to say about what is grouping these things,
> > > we don't need a new flag. We can make it a machine property.
> > >
> > > It's user's hint that some host resource is dedicated to a VM.
> >
> > The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
> > KVM_HINTS_REALTIME) should be reverted according to several threads
> > discussion I think.
> >
> > Regards,
> > Wanpeng Li
>
> IMHO that is unrelated - these KVM hints are hints to *guest*.

Actually I really don't like the KVM_HINT_REALTIME renaming, there are
dedicated instances in public cloud environment consider security or
performance. The financial customers may prefer dedicated pCPUs when
considering security, and other gaming customers may prefer dedicated
pCPUs when considering performance. So "realtime" is not suitable.

Regards,
Wanpeng Li

Re: [Qemu-devel] [PATCH v3 1/2] kvm: support -dedicated cpu-pm=on|off

[Wanpeng Li]

On Wed, 20 Jun 2018 at 10:41, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Jun 20, 2018 at 08:46:10AM +0800, Wanpeng Li wrote:
> > On Wed, 20 Jun 2018 at 08:07, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Jun 19, 2018 at 05:07:46PM -0500, Eric Blake wrote:
> > > > On 06/19/2018 10:17 AM, Paolo Bonzini wrote:
> > > > > On 16/06/2018 00:29, Michael S. Tsirkin wrote:
> > > > > > +static QemuOptsList qemu_dedicated_opts = {
> > > > > > +    .name = "dedicated",
> > > > > > +    .head = QTAILQ_HEAD_INITIALIZER(qemu_dedicated_opts.head),
> > > > > > +    .desc = {
> > > > > > +        {
> > > > > > +            .name = "mem-lock",
> > > > > > +            .type = QEMU_OPT_BOOL,
> > > > > > +        },
> > > > > > +        {
> > > > > > +            .name = "cpu-pm",
> > > > > > +            .type = QEMU_OPT_BOOL,
> > > > > > +        },
> > > > > > +        { /* end of list */ }
> > > > > > +    },
> > > > > > +};
> > > > > > +
> > > > >
> > > > > Let the bikeshedding begin!
> > > > >
> > > > > 1) Should we deprecate -realtime?
> > > > >
> > > > > 2) Maybe -hostresource?
> > > >
> > > > What further things might we add in the future?
> > > >
> > > > -dedicated sounds wrong (it is an adjective, while most of our options are
> > > > nouns - thing -machine, -drive, -object, ...)
> > > >
> > > > -hostresource at least sounds like a noun, but is long to type.  But at
> > > > least '-hostresource cpu-pm=on' reads reasonably well.
> > >
> > > Yes but host resource what? I feel it says nothing at all about what
> > > one can expect to find in this flag.
> > >
> > > > About the only other noun I could think of would be '-feature cpu-pm=on'.
> > >
> > > If we have nothing at all to say about what is grouping these things,
> > > we don't need a new flag. We can make it a machine property.
> > >
> > > It's user's hint that some host resource is dedicated to a VM.
> >
> > The commit 633711e82 (kvm: rename KVM_HINTS_DEDICATED to
> > KVM_HINTS_REALTIME) should be reverted according to several threads
> > discussion I think.
> >
> > Regards,
> > Wanpeng Li
>
> IMHO that is unrelated - these KVM hints are hints to *guest*.

Actually I really don't like the KVM_HINT_REALTIME renaming, there are
dedicated instances in public cloud environment consider security or
performance. The financial customers may prefer dedicated pCPUs when
considering security, and other gaming customers may prefer dedicated
pCPUs when considering performance. So "realtime" is not suitable.

Regards,
Wanpeng Li