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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list