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

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

 



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.

> 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.

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,

    <cpu>
      <model>Model</model>
      <vendor force='bleblablebla'/>
    </cpu>

would force "bleblablebla" vendor ID,

    <cpu>
      <model>Model</model>
      <vendor>Intel</vendor>
    </cpu>

would just check that host CPU is made by Intel, and

    <cpu>
      <model>Model</model>
      <vendor force='bleblablebla'>Intel</vendor>
    </cpu>

would check that host CPU is made by Intel but the guest CPU will have
"bleblablebla" vendor ID.

I was also thinking about making use of our vendor aliases (Intel for
GenuineIntel and AMD for AuthenticAMD, and we are free to add others) but
since vendor ID forcing seems to be only useful for testing, I think it's fine
if we require full vendor ID to be used. At least I don't see another reason
why anyone would want to confuse a guest OS by giving it Opteron_G4 CPU made
by VIA.

What other think about this?

Jirka

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]