Re: [libvirt] [PATCH] docs: added description of the vendor_id attribute

On Wed, Jul 11, 2012 at 09:00:05 +0200, Hendrik Schwartke wrote: > On 10.07.2012 21:57, Jiri Denemark wrote: >> I know I'm late in this vendor_id stuff but it hasn't been released yet so I'm >> not too late. I assume the reason for introducing it is to be able to lie to a >> guest. Please, correct me, if this is not the case. > Well, the reason is to specify a vendor_id which is different to the > actual host vendor id >>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in >>> index 94c555f..b6e0d5d 100644 >>> --- a/docs/formatdomain.html.in >>> +++ b/docs/formatdomain.html.in >>> @@ -779,7 +779,11 @@ >>> in which case an attempt to start a domain requesting an unsupported >>> CPU model will fail. Supported values for<code>fallback</code> >>> attribute are:<code>allow</code> (this is the default), and >>> -<code>forbid</code>.</dd> >>> +<code>forbid</code>. The optional<code>vendor_id</code> attribute >>> + (<span class="since">Since 0.9.14</span>) can be used to set the >>> + vendor id seen by the guest. It must be exactly 12 characters long. >>> + If not set the vendor id of the host is used. Typical possible >>> + values are "AuthenticAMD" and "GenuineIntel".</dd> >>> >>> <dt><code>vendor</code></dt> >>> <dd><span class="since">Since 0.8.3</span> the content of the >> This is wrong (unless your previous patch explicitly modified the code to >> behave like this). If vendor_id is not set, a guest should see model's default >> vendor. If a guest is configured with, e.g., SandyBridge model, its vendor >> will be "GenuineIntel". If a guest uses Opteron_G3, it will see "AuthenticAMD" >> vendor. All this regardless on the vendor of the host CPU as longs as the host >> CPU is capable enough to support all features of a given guest CPU. > I have tested this (with the qemu driver) and that's not correct. I'm > sure you have to set the vendor attribute in the qemu command line to > set the vendor id. So "kvm -cpu core2duo -cdrom > debian-6.0.5-i386-netinst.iso" on an amd machine results in vendor id = > AuthenticAMD (just as with -cpu 486) Oh, you are right. I tried with Opteron_G1 on Sandy Bridge host and indeed the guest sees it as Opteron made by Intel. I think this is a QEMU bug as its CPU configuration says: [cpudef] name = "Opteron_G1" level = "5" vendor = "AuthenticAMD" ...

>> Anyway, to be honest, I'm not a big fan of the new vendor_id attribute. >> Currently we have >> >> <cpu ...> >> <model vendor_id="bleblablebla">Model</model> >> ... >> </cpu> >> >> to force "bleblablebla" vendor ID on the guest CPU and >> >> <cpu ...> >> <model>Model</model> >> <vendor>Intel</vendor> >> ... >> </cpu> >> >> to make sure the guest will be run only on a host with Intel CPU. >> >> I think it would be much better to reuse the already existing<vendor> >> element. We could perhaps add new force attribute for vendor element. Thus, > These are two different things. One is the vendor_id the guest should > see and the other the vendor id the host should have to start the > domain. So if the CPUID instruction in the guest should return > "NOT-INTEL" and the host cpu should be an intel cpu a force bit is not > enough. Furthermore it would be confusing to use only one attribute to > specify the vendor of the host and the guest cpu. Yes, I know there are two different things here. However, having<vendor> element specifying host's vendor and vendor_id attribute for model element specifying guest's vendor feels a bit odd. Let's see what other thinks about this matter. Jirka