[libvirt] [PATCH] cpu: Add support for CPU vendor

[Dan Kenigsberg]

On Tue, Jul 20, 2010 at 11:04:01AM +0200, Jiri Denemark wrote:
> > > > > And how about adding policy='disable' attribute, so that I can ask
> > > > > virConnectCompareCPU to ignore this particular incompatibility, as I do
> > > > > with <feature> items?
> > > > 
> > > > Just don't use <vendor> tag in your XML.
> > > > 
> > > > In other words, if you specify <vendor> in domain XML (or it's cpu fragment
> > > > used by virConnectCompareCPU) and your host CPU is made by different vendor,
> > > > the CPUs won't match. If you don't specify <vendor>, you don't care about the
> > > > vendor and neither does libvirt.
> > > > 
> > > > I hope it's more clear now.
> > > 
> > > I wanted to (ab)use virConnectCompareCPU to roughly tell a certain cpu
> > > model (say athlon) can be emulated on my host. I now see that this is not
> > > going to happen, and I'll have to do my own feature set comparison.
> >
> > I don't see the problem in virConnectCompareCPU() that prevents you using
> > it for that ? Checking whether a certain cpu model can be emulated on a
> > host is exactly what's virConnectCompareCPU is design todo. We explicitly
> > did not want apps to need to do a manual feature set comparison because
> > that's just horrible code to get right.
> 
> Yeah exactly, I don't really get what makes you think you can't use
> virConnectCompareCPU.
> 
> You can use
>     <cpu match='exact'>
>         <model>athlon</model>
>     </cpu>
> to check if athlon model is compatible with host CPU (regardless on vendor).
> 
> If you are not interested in some features (say 3dnowext), you can use
>     <cpu match='exact'>
>         <model>athlon</model>
>         <feature name='3dnowext' policy='disable'/>
>     </cpu>
> 
> And if you only want to run on an AuthenticAMD CPU, you'd use
>     <cpu match='exact'>
>         <model>athlon</model>
>         <vendor>AMD</vendor>
>         <feature name='3dnowext' policy='disable'/>
>     </cpu>

Oh, I assumed that the fact the <vendor>AMD</vendor> appears in the
model definition of "athlon", it is implicit whenever
<model>athlon</model> is mentioned. The semantics missing <vendor> is
"don't care about vendor", and the semantics of a missing <feature> is
"enforce the feature". This is a bit confusing.

> 
> However it all depends on what you mean by "emulated". If you really want to
> check if the CPU can be emulated on your machine as in "I have this old
> pentium3 box but I want to run a VM which requires the newest Opteron even
> though most of its features will be emulated in software" then
> virConnectCompareCPU is not currently able to check that for you. But I doubt
> you could check this by doing your own feature set comparison since you'd need
> to go deep into qemu and check what features it can emulate in software.
> 
> Anyway, if you think virConnectCompareCPU is not doing what it should or if
> you have ideas on improving feature set comparison, please share them here.
> It's better to improve libvirt than doing all by yourself within your
> application.

Well, I would like to tell in advance if starting up domain is going to
be rejected due to incompatibility between guest cpu and host cpu in the
relevant hypervisor (qemu -cpu bla,enforce style).