[libvirt] [PATCH] docs: added description of the vendor_id attribute
--- docs/formatdomain.html.in | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) 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 -- 1.7.9.5
On 10.07.2012 10:01, Hendrik Schwartke wrote:
--- docs/formatdomain.html.in | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
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
ACKed and pushed. Thanks. Michal
On 07/10/2012 03:26 AM, Michal Privoznik wrote:
On 10.07.2012 10:01, Hendrik Schwartke wrote:
--- docs/formatdomain.html.in | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
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
I think our goal is to number the next release 0.10.0 (thanks to the addition of a new driver); but we can do a global search-and-replace of any 0.9.14 stragglers at once. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
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) 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. <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. Well, there are some special cases where migrating guest from one host to another with different cpu vendors is a problem. Using a windows 7 or 8 image on different cpus could for example require a (re-)activation. So this feature could be quite important not only for testing. What other think about this? One idea is to rename vendor_id to guest_vendor_id or to fake_vendor_id. Jirka
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
On 11.07.2012 14:03, Jiri Denemark wrote:
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" ...
No, it's not a bug it's a feature ;). There are a few instructions that are implemented differently on intel and amd cpus (e.g.SYSENTER and SYSCALL). So in the past it was important for the guest to know the correct cpu vendor and therefor it wasn't possible to fake it. But since a while these few instructions can be emulated by qemu, so that it's know unproblematic to change it. (See http://developer.amd.com/assets/CrossVendorMigration.pdf) I'm not sure but I'm supposing that the old behavior of qemu to set all cpu properties with the exception of the vendor id is still in use to avoid compatibility issues. If you want to specify a guest cpu *including* the vendor id you have to set the additional vendor attribute.
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
participants (4)
-
Eric Blake -
Hendrik Schwartke -
Jiri Denemark -
Michal Privoznik