Hi Jiri,
Thank you for the valuable information.
That's exactly what I want to get.
Let me tell you what I'm doing now.
I'm extending OpenStack (cloud computing infrastructure) for high performance computing.
Before spawning a cloud instance, I want to check the full capability of the host machine because I will use KVM.
With the expanded feature list, a cloud user can decide which node to choose.
For example, if a users needs sse4.1, the scheduler should search for a node having sse4.1 as its feature.
OpensStack currently calls virConnectGetCapabilities at the start of a node to get its capability.
And it returns not fully expanded feature list.
Could you tell me how I can exand it fully?
Should I patch libvirt? Or can it be done giving different arguments to libvirt API?
Thank you,
Dong-In
----- Original Message -----
From: "Jiri Denemark" <jdenemar@xxxxxxxxxx>
To: "Dong-In David Kang" <dkang@xxxxxxx>
Cc: libvir-list@xxxxxxxxxx
Sent: Friday, May 13, 2011 5:29:09 AM
Subject: Re: inquiry, get native capabilities of the host
Hi,
On Thu, May 12, 2011 at 15:39:44 -0700, Dong-In David Kang wrote:
> I'm interested in getting native capabilities of host CPU using libvirt.
> I've looked at .../src/cpu/cpu_map.xml.
> And it does describe native capabilities of host CPU very well.
> But, libvirt always returns a subset of the native capabilities which is far different from the feature lists in the xml file.
> (I'm testing with <model name='Westmere'>.)
> The sponsor of my project is interested is high-performance computing.
> And knowing native feature of the host CPU that can also be available to a virtual machine is very important for performance reason.
>
> I couldn't find how to get the native features of the host that is described in .../src/cpu/cpu_map.xml.
> Is there a way or libvirt API to get the native capabilities of host CPU that is well described in .../src/cpu/cpu_map.xml?
I'm not sure I totally understand what you are looking for. Is the issue you
have that virsh capabilities tells you something like this:
<cpu>
<arch>x86_64</arch>
<model>Westmere</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='2' threads='2'/>
<feature name='rdtscp'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
while in cpu_map.xml mentions much more features for Westmere model? If so,
than the answer is quite simple. The thing is that the CPU description is
additive, that is the above XML snippet says that host CPU supports all
features that are defined by Westmere CPU model in cpu_map.xml *plus* the
features that are explicitly listed in the above <cpu> element. So if you
expand the model, you get a full list of features supported by the host CPU:
<!-- from Nehalem which Westmere is derived from -->
<feature name='sse2'/>
<feature name='sse'/>
<feature name='fxsr'/>
<feature name='mmx'/>
<feature name='pat'/>
<feature name='cmov'/>
<feature name='pge'/>
<feature name='sep'/>
<feature name='apic'/>
<feature name='cx8'/>
<feature name='mce'/>
<feature name='pae'/>
<feature name='msr'/>
<feature name='tsc'/>
<feature name='pse'/>
<feature name='de'/>
<feature name='fpu'/>
<feature name='mtrr'/>
<feature name='clflush'/>
<feature name='mca'/>
<feature name='pse36'/>
<feature name='pni'/>
<feature name='cx16'/>
<feature name='ssse3'/>
<feature name='sse4.1'/>
<feature name='sse4.2'/>
<feature name='popcnt'/>
<feature name='lm'/>
<feature name='syscall'/>
<feature name='nx'/>
<feature name='lahf_lm'/>
<!-- from Westmere -->
<feature name='aes'/>
<!-- explicitly listed -->
<feature name='rdtscp'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list