qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] resent: fix CPUID vendor override
@ 2010-05-21  5:58 Andre Przywara
  2010-05-24 22:12 ` Anthony Liguori
  0 siblings, 1 reply; 2+ messages in thread
From: Andre Przywara @ 2010-05-21  5:58 UTC (permalink / raw)
  To: anthony; +Cc: Andre Przywara, qemu-devel, aurelien

the meaning of vendor_override is actually the opposite of how it
is currently used :-(
Fix it to allow KVM to export the non-native CPUID vendor if
explicitly requested by the user.
The semantic is now as intended:
- With TCG, the guest always sees the configured vendor.
- With KVM, the default is to propagate the host's vendor
  - when explicitly requested via -cpu <base>,vendor=xxx obey this
    and use the specified vendor

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 target-i386/cpuid.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Hi,

this hasn't been picked up the last time I sent it out, are there any
objections?

Regards,
Andre.

diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 56938e2..99d1f44 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -962,7 +962,7 @@ static void get_cpuid_vendor(CPUX86State *env, uint32_t *ebx,
      * this if you want to use KVM's sysenter/syscall emulation
      * in compatibility mode and when doing cross vendor migration
      */
-    if (kvm_enabled() && env->cpuid_vendor_override) {
+    if (kvm_enabled() && ! env->cpuid_vendor_override) {
         host_cpuid(0, 0, NULL, ebx, ecx, edx);
     }
 }
-- 
1.6.4

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [Qemu-devel] [PATCH] resent: fix CPUID vendor override
  2010-05-21  5:58 [Qemu-devel] [PATCH] resent: fix CPUID vendor override Andre Przywara
@ 2010-05-24 22:12 ` Anthony Liguori
  0 siblings, 0 replies; 2+ messages in thread
From: Anthony Liguori @ 2010-05-24 22:12 UTC (permalink / raw)
  To: Andre Przywara; +Cc: qemu-devel, aurelien, kvm-devel

On 05/21/2010 12:58 AM, Andre Przywara wrote:
> the meaning of vendor_override is actually the opposite of how it
> is currently used :-(
> Fix it to allow KVM to export the non-native CPUID vendor if
> explicitly requested by the user.
> The semantic is now as intended:
> - With TCG, the guest always sees the configured vendor.
> - With KVM, the default is to propagate the host's vendor
>    - when explicitly requested via -cpu<base>,vendor=xxx obey this
>      and use the specified vendor
>
> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>    

This should go through uq/master.  But I'm not sure that the new 
behavior is really what's desired.  It's certainly going to break 
compatibility since -M pc-0.12 is going to show a different vendor_id by 
default.

Regards,

Anthony Liguori

> ---
>   target-i386/cpuid.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> Hi,
>
> this hasn't been picked up the last time I sent it out, are there any
> objections?
>
> Regards,
> Andre.
>
> diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
> index 56938e2..99d1f44 100644
> --- a/target-i386/cpuid.c
> +++ b/target-i386/cpuid.c
> @@ -962,7 +962,7 @@ static void get_cpuid_vendor(CPUX86State *env, uint32_t *ebx,
>        * this if you want to use KVM's sysenter/syscall emulation
>        * in compatibility mode and when doing cross vendor migration
>        */
> -    if (kvm_enabled()&&  env->cpuid_vendor_override) {
> +    if (kvm_enabled()&&  ! env->cpuid_vendor_override) {
>           host_cpuid(0, 0, NULL, ebx, ecx, edx);
>       }
>   }
>    

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-05-24 22:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-21  5:58 [Qemu-devel] [PATCH] resent: fix CPUID vendor override Andre Przywara
2010-05-24 22:12 ` Anthony Liguori

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).