[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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:

       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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]