[libvirt] [PATCH 1/1] cpu_map.xml: add cmt/mbm feature to x86
Some Intel processor families (e.g. the Intel Xeon processor E5 v3 family) introduced some PQos (Platform Qos) features, including CMT (Cache Monitoring echnology) and MBM (Memory Bandwidth Monitoring), to monitor or control shared resource. This patch add them into x86 part of cpu_map.xml to be used for applications (like OpenStack) based on libvirt to get cpu capabilities. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> --- src/cpu/cpu_map.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 08aded2..2e2cb4f 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -320,6 +320,9 @@ <feature name='rtm'> <cpuid function='0x00000007' ebx='0x00000800'/> </feature> + <feature name='cmt'> + <cpuid function='0x00000007' ebx='0x00001000'/> + </feature> <feature name='mpx'> <cpuid function='0x00000007' ebx='0x00004000'/> </feature> @@ -353,6 +356,14 @@ <cpuid function='0x80000007' edx='0x00000100'/> </feature> + <!-- cpuid level 0x0000000f:1 (edx) --> + <feature name='mbm_total'> <!-- LLC Total MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000002'/> + </feature> + <feature name='mbm_local'> <!-- LLC Local MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000004'/> + </feature> + <!-- models --> <model name='486'> <feature name='fpu'/> -- 1.9.1
On Fri, Jun 17, 2016 at 09:23:56 +0800, Qiaowei Ren wrote:
Some Intel processor families (e.g. the Intel Xeon processor E5 v3 family) introduced some PQos (Platform Qos) features, including CMT (Cache Monitoring echnology) and MBM (Memory Bandwidth Monitoring), to monitor or control shared resource. This patch add them into x86 part of cpu_map.xml to be used for applications (like OpenStack) based on libvirt to get cpu capabilities.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> --- src/cpu/cpu_map.xml | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 08aded2..2e2cb4f 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -320,6 +320,9 @@ <feature name='rtm'> <cpuid function='0x00000007' ebx='0x00000800'/> </feature> + <feature name='cmt'> + <cpuid function='0x00000007' ebx='0x00001000'/> + </feature> <feature name='mpx'> <cpuid function='0x00000007' ebx='0x00004000'/> </feature>
This hunk won't apply since about a week ago. Please, use current git when sending patches.
@@ -353,6 +356,14 @@ <cpuid function='0x80000007' edx='0x00000100'/> </feature>
+ <!-- cpuid level 0x0000000f:1 (edx) --> + <feature name='mbm_total'> <!-- LLC Total MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000002'/> + </feature> + <feature name='mbm_local'> <!-- LLC Local MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000004'/> + </feature> +
And keep the list of features sorted by CPUID level, i.e., these features should go after 0x0d and before 0x80000000. Jirka
On Fri, Jun 17, 2016 at 09:25:14 +0200, Jiri Denemark wrote:
On Fri, Jun 17, 2016 at 09:23:56 +0800, Qiaowei Ren wrote:
Some Intel processor families (e.g. the Intel Xeon processor E5 v3 family) introduced some PQos (Platform Qos) features, including CMT (Cache Monitoring echnology) and MBM (Memory Bandwidth Monitoring), to monitor or control shared resource. This patch add them into x86 part of cpu_map.xml to be used for applications (like OpenStack) based on libvirt to get cpu capabilities.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> --- src/cpu/cpu_map.xml | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 08aded2..2e2cb4f 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -320,6 +320,9 @@ <feature name='rtm'> <cpuid function='0x00000007' ebx='0x00000800'/> </feature> + <feature name='cmt'> + <cpuid function='0x00000007' ebx='0x00001000'/> + </feature> <feature name='mpx'> <cpuid function='0x00000007' ebx='0x00004000'/> </feature>
This hunk won't apply since about a week ago. Please, use current git when sending patches.
@@ -353,6 +356,14 @@ <cpuid function='0x80000007' edx='0x00000100'/> </feature>
+ <!-- cpuid level 0x0000000f:1 (edx) --> + <feature name='mbm_total'> <!-- LLC Total MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000002'/> + </feature> + <feature name='mbm_local'> <!-- LLC Local MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000004'/> + </feature> +
And keep the list of features sorted by CPUID level, i.e., these features should go after 0x0d and before 0x80000000.
Oh and I completely forgot the most important thing: it makes little sense to add CPUID features that QEMU does not support. It will only allow users to see the features in host CPU capabilities. So if the purpose of these patches is to be able to advertise whether the appropriate perf events are supported on current host, CPU features are not the right way of doing that. I think domain capabilities XML would be the right place to advertise what events are supported. Jirka
On Fri, Jun 17, 2016 at 11:17:47AM +0200, Jiri Denemark wrote:
On Fri, Jun 17, 2016 at 09:25:14 +0200, Jiri Denemark wrote:
On Fri, Jun 17, 2016 at 09:23:56 +0800, Qiaowei Ren wrote:
Some Intel processor families (e.g. the Intel Xeon processor E5 v3 family) introduced some PQos (Platform Qos) features, including CMT (Cache Monitoring echnology) and MBM (Memory Bandwidth Monitoring), to monitor or control shared resource. This patch add them into x86 part of cpu_map.xml to be used for applications (like OpenStack) based on libvirt to get cpu capabilities.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> --- src/cpu/cpu_map.xml | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 08aded2..2e2cb4f 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -320,6 +320,9 @@ <feature name='rtm'> <cpuid function='0x00000007' ebx='0x00000800'/> </feature> + <feature name='cmt'> + <cpuid function='0x00000007' ebx='0x00001000'/> + </feature> <feature name='mpx'> <cpuid function='0x00000007' ebx='0x00004000'/> </feature>
This hunk won't apply since about a week ago. Please, use current git when sending patches.
@@ -353,6 +356,14 @@ <cpuid function='0x80000007' edx='0x00000100'/> </feature>
+ <!-- cpuid level 0x0000000f:1 (edx) --> + <feature name='mbm_total'> <!-- LLC Total MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000002'/> + </feature> + <feature name='mbm_local'> <!-- LLC Local MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000004'/> + </feature> +
And keep the list of features sorted by CPUID level, i.e., these features should go after 0x0d and before 0x80000000.
Oh and I completely forgot the most important thing: it makes little sense to add CPUID features that QEMU does not support. It will only allow users to see the features in host CPU capabilities. So if the purpose of these patches is to be able to advertise whether the appropriate perf events are supported on current host, CPU features are not the right way of doing that. I think domain capabilities XML would be the right place to advertise what events are supported.
Nova schedules guests based on the CPU features that the host has, so we really do want this to be exposed in the general host capabilities XML description of the host CPU. We don't care about running guests with this features - we just want to see the host report for them. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
-----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Thursday, June 23, 2016 5:18 PM To: Ren, Qiaowei <qiaowei.ren@intel.com>; libvir-list@redhat.com; Peter Krempa <pkrempa@redhat.com> Subject: Re: [libvirt] [PATCH 1/1] cpu_map.xml: add cmt/mbm feature to x86
On Fri, Jun 17, 2016 at 11:17:47AM +0200, Jiri Denemark wrote:
On Fri, Jun 17, 2016 at 09:25:14 +0200, Jiri Denemark wrote:
On Fri, Jun 17, 2016 at 09:23:56 +0800, Qiaowei Ren wrote:
Some Intel processor families (e.g. the Intel Xeon processor E5 v3 family) introduced some PQos (Platform Qos) features, including CMT (Cache Monitoring echnology) and MBM (Memory Bandwidth Monitoring), to monitor or control shared resource. This patch add them into x86 part of cpu_map.xml to be used for applications (like OpenStack) based on libvirt to get cpu capabilities.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> --- src/cpu/cpu_map.xml | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 08aded2..2e2cb4f 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -320,6 +320,9 @@ <feature name='rtm'> <cpuid function='0x00000007' ebx='0x00000800'/> </feature> + <feature name='cmt'> + <cpuid function='0x00000007' ebx='0x00001000'/> + </feature> <feature name='mpx'> <cpuid function='0x00000007' ebx='0x00004000'/> </feature>
This hunk won't apply since about a week ago. Please, use current git when sending patches.
@@ -353,6 +356,14 @@ <cpuid function='0x80000007' edx='0x00000100'/> </feature>
+ <!-- cpuid level 0x0000000f:1 (edx) --> + <feature name='mbm_total'> <!-- LLC Total MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000002'/> + </feature> + <feature name='mbm_local'> <!-- LLC Local MBM monitoring --> + <cpuid function='0x0000000f' edx='0x00000004'/> + </feature> +
And keep the list of features sorted by CPUID level, i.e., these features should go after 0x0d and before 0x80000000.
Oh and I completely forgot the most important thing: it makes little sense to add CPUID features that QEMU does not support. It will only allow users to see the features in host CPU capabilities. So if the purpose of these patches is to be able to advertise whether the appropriate perf events are supported on current host, CPU features are not the right way of doing that. I think domain capabilities XML would be the right place to advertise what events are supported.
Nova schedules guests based on the CPU features that the host has, so we really do want this to be exposed in the general host capabilities XML description of the host CPU. We don't care about running guests with this features - we just want to see the host report for them.
Yes, Nova need host report for these features, and I will submit new version for this patch based on latest code according to Jiri's previous comment. Thanks, Qiaowei
On Thu, Jun 23, 2016 at 10:18:20 +0100, Daniel P. Berrange wrote:
On Fri, Jun 17, 2016 at 11:17:47AM +0200, Jiri Denemark wrote:
Oh and I completely forgot the most important thing: it makes little sense to add CPUID features that QEMU does not support. It will only allow users to see the features in host CPU capabilities. So if the purpose of these patches is to be able to advertise whether the appropriate perf events are supported on current host, CPU features are not the right way of doing that. I think domain capabilities XML would be the right place to advertise what events are supported.
Nova schedules guests based on the CPU features that the host has, so we really do want this to be exposed in the general host capabilities XML description of the host CPU. We don't care about running guests with this features - we just want to see the host report for them.
Wouldn't it be more practical to advertise this stuff in a different manner than? If we report these CPU features in host CPU capabilities and someone takes the host CPU definition, runs it through virConnectBaselineCPU to get a guest CPU configuration and uses it to start a domain, they might be quite surprised that it doesn't work: $ ./qemu-system-x86_64 -cpu Skylake-Client,+mbm_total qemu-system-x86_64: CPU feature mbm-total not found On the other hand, running an older QEMU which doesn't understand features which new QEMU does is not any different. And technically, all the new features are valid CPU. So take this comment more as something to thing about the right way to advertise this kind of stuff. Jirka
On Fri, Jun 24, 2016 at 01:32:32PM +0200, Jiri Denemark wrote:
On Thu, Jun 23, 2016 at 10:18:20 +0100, Daniel P. Berrange wrote:
On Fri, Jun 17, 2016 at 11:17:47AM +0200, Jiri Denemark wrote:
Oh and I completely forgot the most important thing: it makes little sense to add CPUID features that QEMU does not support. It will only allow users to see the features in host CPU capabilities. So if the purpose of these patches is to be able to advertise whether the appropriate perf events are supported on current host, CPU features are not the right way of doing that. I think domain capabilities XML would be the right place to advertise what events are supported.
Nova schedules guests based on the CPU features that the host has, so we really do want this to be exposed in the general host capabilities XML description of the host CPU. We don't care about running guests with this features - we just want to see the host report for them.
Wouldn't it be more practical to advertise this stuff in a different manner than? If we report these CPU features in host CPU capabilities and someone takes the host CPU definition, runs it through virConnectBaselineCPU to get a guest CPU configuration and uses it to start a domain, they might be quite surprised that it doesn't work:
$ ./qemu-system-x86_64 -cpu Skylake-Client,+mbm_total qemu-system-x86_64: CPU feature mbm-total not found
On the other hand, running an older QEMU which doesn't understand features which new QEMU does is not any different. And technically, all the new features are valid CPU. So take this comment more as something to thing about the right way to advertise this kind of stuff.
Yep, that problem already exists. What is likely needed is a way to ask for a baseline CPU, given a particular choice of machine type and emulator binary. eg similar to how we added the domain capabilities which accepts emulator, arch, machine as parameters. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Daniel P. Berrange -
Jiri Denemark -
Qiaowei Ren -
Ren, Qiaowei