[Qemu-devel] [PATCH 0/2] VMware ESX guest bringup (partial)

[Qemu-devel] [PATCH 0/2] VMware ESX guest bringup (partial)

[Alexander Graf]

In order to get VMware ESX running as guest OS, some modifications need
to be done in qemu / KVM. As this is work in progress, this is the
current status of what is required to get it to boot at least partially.

FWIW some MTRR MSRs are still missing to make it happy on qemu. The
patches given here should be enough to make it at least boot when using
KVM with NPT though.

Alexander Graf (2):
  Make vmport report the processor speed
  Add phenom CPU descriptor

 hw/vmport.c          |   22 ++++++++++++++++++++++
 target-i386/helper.c |   27 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 0 deletions(-)

[Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

If VMware ESX finds itself virtualized (read: inside VMware), it reads the TSC speed
from its backdoor, because measuring the TSC inside a VM is not exact.

This patch implements a hacky way to detect the TSC speed and passes that through to
the VM. I am open to suggestions on how to improve the behavior.
It also adds a magic return value of 2 on the version return, which is required by
VMware ESX.

WARNING: This implementation breaks on non-x86 hosts!

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/vmport.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/hw/vmport.c b/hw/vmport.c
index 884af3f..825fd92 100644
--- a/hw/vmport.c
+++ b/hw/vmport.c
@@ -28,6 +28,7 @@
 
 //#define VMPORT_DEBUG
 
+#define VMPORT_CMD_GETPROCSPEED 0x01
 #define VMPORT_CMD_GETVERSION 0x0a
 #define VMPORT_CMD_GETRAMSIZE 0x14
 
@@ -87,6 +88,7 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
 {
     CPUState *env = cpu_single_env;
     env->regs[R_EBX] = VMPORT_MAGIC;
+    env->regs[R_ECX] = 2;
     return 6;
 }
 
@@ -97,6 +99,25 @@ static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
     return ram_size;
 }
 
+
+static inline int64_t rdtsc(void)
+{
+    int64_t val;
+    asm volatile ("rdtsc" : "=A" (val));
+    return val;
+}
+
+static uint32_t vmport_cmd_proc_speed(void *opaque, uint32_t addr)
+{
+    static uint64_t tsc = 0;
+    if ( tsc == 0 ) {
+        tsc = rdtsc();
+        usleep(100000);
+        tsc = (rdtsc() - tsc) / 100000;
+    }
+    return (tsc / 66) * 66;
+}
+
 void vmport_init(void)
 {
     register_ioport_read(0x5658, 1, 4, vmport_ioport_read, &port_state);
@@ -105,4 +126,5 @@ void vmport_init(void)
     /* Register some generic port commands */
     vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
     vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
+    vmport_register(VMPORT_CMD_GETPROCSPEED, vmport_cmd_proc_speed, NULL);
 }
-- 
1.5.6

[Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Alexander Graf]

As part of my ongoing effort to make nested SVM useful, I started working to get
VMware ESX run inside KVM.

VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
a machine that officially supports SVM and should thus exploit the powers of
nested virtualization.

This patch adds a Phenom CPU identifier, that resembles a real-world phenom
CPU as closely as possible.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 target-i386/helper.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/target-i386/helper.c b/target-i386/helper.c
index a28ab93..c709ad8 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -137,6 +137,33 @@ static x86_def_t x86_defs[] = {
         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
     },
     {
+        .name = "phenom",
+        .level = 5,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 16,
+        .model = 2,
+        .stepping = 3,
+        /* Missing: CPUID_VME, CPUID_HT */
+        .features = PPRO_FEATURES | 
+            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
+            CPUID_PSE36,
+        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
+        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
+        /* Missing: CPUID_EXT2_FFXSR, CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
+        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) | 
+            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
+            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT | CPUID_EXT2_MMXEXT,
+        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG, CPUID_EXT3_EXTAPIC,
+                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM, CPUID_EXT3_SSE4A,
+                    CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
+                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
+        .ext3_features = CPUID_EXT3_SVM,
+        .xlevel = 0x8000001A,
+        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
+    },
+    {
         .name = "core2duo",
         .level = 10,
         .family = 6,
-- 
1.5.6

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Alexander Graf]

Any reason not to commit this one? It's required for Hyper-V and  
VMware ESX and lives perfectly fine without patch 1/2.

Alex

On 05.01.2009, at 17:11, Alexander Graf wrote:

> As part of my ongoing effort to make nested SVM useful, I started  
> working to get
> VMware ESX run inside KVM.
>
> VMware couples itself pretty tightly to the CPUID, so it's a good  
> idea to emulate
> a machine that officially supports SVM and should thus exploit the  
> powers of
> nested virtualization.
>
> This patch adds a Phenom CPU identifier, that resembles a real-world  
> phenom
> CPU as closely as possible.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> target-i386/helper.c |   27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/target-i386/helper.c b/target-i386/helper.c
> index a28ab93..c709ad8 100644
> --- a/target-i386/helper.c
> +++ b/target-i386/helper.c
> @@ -137,6 +137,33 @@ static x86_def_t x86_defs[] = {
>         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
>     },
>     {
> +        .name = "phenom",
> +        .level = 5,
> +        .vendor1 = CPUID_VENDOR_AMD_1,
> +        .vendor2 = CPUID_VENDOR_AMD_2,
> +        .vendor3 = CPUID_VENDOR_AMD_3,
> +        .family = 16,
> +        .model = 2,
> +        .stepping = 3,
> +        /* Missing: CPUID_VME, CPUID_HT */
> +        .features = PPRO_FEATURES |
> +            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
> +            CPUID_PSE36,
> +        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
> +        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
> +        /* Missing: CPUID_EXT2_FFXSR, CPUID_EXT2_PDPE1GB,  
> CPUID_EXT2_RDTSCP */
> +        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) |
> +            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
> +            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT |  
> CPUID_EXT2_MMXEXT,
> +        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG,  
> CPUID_EXT3_EXTAPIC,
> +                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM,  
> CPUID_EXT3_SSE4A,
> +                    CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
> +                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
> +        .ext3_features = CPUID_EXT3_SVM,
> +        .xlevel = 0x8000001A,
> +        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
> +    },
> +    {
>         .name = "core2duo",
>         .level = 10,
>         .family = 6,
> -- 
> 1.5.6
>
>
>

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Anthony Liguori]

Alexander Graf wrote:
> Any reason not to commit this one? It's required for Hyper-V and 
> VMware ESX and lives perfectly fine without patch 1/2.

Because the first one can't be committed and I wasn't sure whether you 
meant for this one to be included to.  I take a look at committing it.

Regards,

Anthony Liguori

> Alex
>
> On 05.01.2009, at 17:11, Alexander Graf wrote:
>
>> As part of my ongoing effort to make nested SVM useful, I started 
>> working to get
>> VMware ESX run inside KVM.
>>
>> VMware couples itself pretty tightly to the CPUID, so it's a good 
>> idea to emulate
>> a machine that officially supports SVM and should thus exploit the 
>> powers of
>> nested virtualization.
>>
>> This patch adds a Phenom CPU identifier, that resembles a real-world 
>> phenom
>> CPU as closely as possible.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> target-i386/helper.c |   27 +++++++++++++++++++++++++++
>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/target-i386/helper.c b/target-i386/helper.c
>> index a28ab93..c709ad8 100644
>> --- a/target-i386/helper.c
>> +++ b/target-i386/helper.c
>> @@ -137,6 +137,33 @@ static x86_def_t x86_defs[] = {
>>         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
>>     },
>>     {
>> +        .name = "phenom",
>> +        .level = 5,
>> +        .vendor1 = CPUID_VENDOR_AMD_1,
>> +        .vendor2 = CPUID_VENDOR_AMD_2,
>> +        .vendor3 = CPUID_VENDOR_AMD_3,
>> +        .family = 16,
>> +        .model = 2,
>> +        .stepping = 3,
>> +        /* Missing: CPUID_VME, CPUID_HT */
>> +        .features = PPRO_FEATURES |
>> +            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
>> +            CPUID_PSE36,
>> +        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
>> +        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
>> +        /* Missing: CPUID_EXT2_FFXSR, CPUID_EXT2_PDPE1GB, 
>> CPUID_EXT2_RDTSCP */
>> +        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) |
>> +            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
>> +            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT | CPUID_EXT2_MMXEXT,
>> +        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG, 
>> CPUID_EXT3_EXTAPIC,
>> +                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM, 
>> CPUID_EXT3_SSE4A,
>> +                    CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
>> +                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
>> +        .ext3_features = CPUID_EXT3_SVM,
>> +        .xlevel = 0x8000001A,
>> +        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
>> +    },
>> +    {
>>         .name = "core2duo",
>>         .level = 10,
>>         .family = 6,
>> -- 
>> 1.5.6
>>
>>
>>
>
>
>

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Anthony Liguori]

Alexander Graf wrote:
> If VMware ESX finds itself virtualized (read: inside VMware), it reads the TSC speed
> from its backdoor, because measuring the TSC inside a VM is not exact.
>
> This patch implements a hacky way to detect the TSC speed and passes that through to
> the VM. I am open to suggestions on how to improve the behavior.
> It also adds a magic return value of 2 on the version return, which is required by
> VMware ESX.
>
> WARNING: This implementation breaks on non-x86 hosts!
>   

Have you tried just disabling vmport?

Regards,

Anthony Liguori

> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  hw/vmport.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/hw/vmport.c b/hw/vmport.c
> index 884af3f..825fd92 100644
> --- a/hw/vmport.c
> +++ b/hw/vmport.c
> @@ -28,6 +28,7 @@
>  
>  //#define VMPORT_DEBUG
>  
> +#define VMPORT_CMD_GETPROCSPEED 0x01
>  #define VMPORT_CMD_GETVERSION 0x0a
>  #define VMPORT_CMD_GETRAMSIZE 0x14
>  
> @@ -87,6 +88,7 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
>  {
>      CPUState *env = cpu_single_env;
>      env->regs[R_EBX] = VMPORT_MAGIC;
> +    env->regs[R_ECX] = 2;
>      return 6;
>  }
>  
> @@ -97,6 +99,25 @@ static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
>      return ram_size;
>  }
>  
> +
> +static inline int64_t rdtsc(void)
> +{
> +    int64_t val;
> +    asm volatile ("rdtsc" : "=A" (val));
> +    return val;
> +}
> +
> +static uint32_t vmport_cmd_proc_speed(void *opaque, uint32_t addr)
> +{
> +    static uint64_t tsc = 0;
> +    if ( tsc == 0 ) {
> +        tsc = rdtsc();
> +        usleep(100000);
> +        tsc = (rdtsc() - tsc) / 100000;
> +    }
> +    return (tsc / 66) * 66;
> +}
> +
>  void vmport_init(void)
>  {
>      register_ioport_read(0x5658, 1, 4, vmport_ioport_read, &port_state);
> @@ -105,4 +126,5 @@ void vmport_init(void)
>      /* Register some generic port commands */
>      vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
>      vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
> +    vmport_register(VMPORT_CMD_GETPROCSPEED, vmport_cmd_proc_speed, NULL);
>  }
>   

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

Anthony Liguori wrote:
> Alexander Graf wrote:
>> If VMware ESX finds itself virtualized (read: inside VMware), it
>> reads the TSC speed
>> from its backdoor, because measuring the TSC inside a VM is not exact.
>>
>> This patch implements a hacky way to detect the TSC speed and passes
>> that through to
>> the VM. I am open to suggestions on how to improve the behavior.
>> It also adds a magic return value of 2 on the version return, which
>> is required by
>> VMware ESX.
>>
>> WARNING: This implementation breaks on non-x86 hosts!
>>   
>
> Have you tried just disabling vmport?

If I don't expose vmport or the command in that patch is not implemented
I get the following error when booting ESX:

Timer: InitPseudoTSC:3940: cpu 0: measured cpu and bus speeds conflict
(PR34866)
0:00:00:00.149 cpu0:1024)ALERT: Timer: InitPseudoTSC:3940: cpu 0:
measured cpu and bus speeds conflict (PR34866)
0:00:00:00.150 cpu0:1024)Timer: InitPseudoTSC:4002: node 0 (cpus 0-0):
consensus bus speed 1051144973 Hz
0:00:00:00.152 cpu0:1024)Timer: InitPseudoTSC:4047: TSC speed=2102289946
Hz, cpu speed=2102289946 Hz, bus speed=1051144973 Hz
0:00:00:00.153 cpu0:1024)Timer: InitPseudoTSC:4075: timerRCToTC
mult=0x1, shift=0, add=0x0
Init: VMKernel:811: Timer_InitPseudoTSC failed:0xbad00c1
0:00:00:00.155 cpu0:1024)ALERT: Init: VMKernel:811: Timer_InitPseudoTSC
failed:0xbad00c1

I don't really think we'll ever get timings accurate enough for such a
check.

Alex

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[François Revol]

> If VMware ESX finds itself virtualized (read: inside VMware),
> it reads the TSC speed
> from its backdoor, because measuring the TSC inside a VM is not
> exact.
>
> This patch implements a hacky way to detect the TSC speed and passes
> that through to
> the VM. I am open to suggestions on how to improve the behavior.
> It also adds a magic return value of 2 on the version return,
> which is required by
> VMware ESX.

Oh this is interesting, I might add some stuff to Haiku to use it.
BeOS (and Haiku) use RDTSC for timing, it's much more precise, but it's
why it runs so strange in VMs... (and will have to be handled when
implementing speedstep)

François.

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Anthony Liguori]

François Revol wrote:
>> If VMware ESX finds itself virtualized (read: inside VMware), 
>> it reads the TSC speed
>> from its backdoor, because measuring the TSC inside a VM is not 
>> exact.
>>
>> This patch implements a hacky way to detect the TSC speed and passes 
>> that through to
>> the VM. I am open to suggestions on how to improve the behavior.
>> It also adds a magic return value of 2 on the version return, 
>> which is required by
>> VMware ESX
>>     
>
> Oh this is interesting, I might add some stuff to Haiku to use it..
> BeOS (and Haiku) use RDTSC for timing, it's much more precise, but it's 
> why it runs so strange in VMs... (and will have to be handled when 
> implementing speedstep)
>   

You should look at KVM_CLOCK in Linux.  We could easily implement it for 
QEMU.  It provides a saner way to use the TSC as a time source in the  
guest.

Regards,

Anthony Liguori

> François.
>
>
>   

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Jamie Lokier]

Alexander Graf wrote:
> If VMware ESX finds itself virtualized (read: inside VMware), it
> reads the TSC speed from its backdoor, because measuring the TSC
> inside a VM is not exact.
> 
> This patch implements a hacky way to detect the TSC speed and passes
> that through to the VM. I am open to suggestions on how to improve
> the behavior.  It also adds a magic return value of 2 on the version
> return, which is required by VMware ESX.  WARNING: This
> implementation breaks on non-x86 hosts!

If you run _this_ code as a guest inside itself, shouldn't it _call_
VMPORT_CMD_GETPROCSPEED to get the value? :-)

-- Jamie

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

On 06.01.2009, at 23:33, Jamie Lokier <jamie@shareable.org> wrote:

> Alexander Graf wrote:
>> If VMware ESX finds itself virtualized (read: inside VMware), it
>> reads the TSC speed from its backdoor, because measuring the TSC
>> inside a VM is not exact.
>>
>> This patch implements a hacky way to detect the TSC speed and passes
>> that through to the VM. I am open to suggestions on how to improve
>> the behavior.  It also adds a magic return value of 2 on the version
>> return, which is required by VMware ESX.  WARNING: This
>> implementation breaks on non-x86 hosts!
>
> If you run _this_ code as a guest inside itself, shouldn't it _call_
> VMPORT_CMD_GETPROCSPEED to get the value? :-)

I don't think doing vmware esx in qemu in vmware us that much of a  
valid scenario right now ;).

But I agree with anthony here - not telling vmware esx that it's  
running virtualized might be the best.

Alex

>
>
> -- Jamie
>
>

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[François Revol]

>
>
>
>
> On 06.01.2009, at 23:33, Jamie Lokier <jamie@shareable.org> wrote:
>
> > Alexander Graf wrote:
> >> If VMware ESX finds itself virtualized (read: inside VMware), it
> >> reads the TSC speed from its backdoor, because measuring the TSC
> >> inside a VM is not exact.
> >>
> >> This patch implements a hacky way to detect the TSC speed and
> > > passes
> >> that through to the VM. I am open to suggestions on how to improve
> >> the behavior.  It also adds a magic return value of 2 on the
> > > version
> >> return, which is required by VMware ESX.  WARNING: This
> >> implementation breaks on non-x86 hosts!
> >
> > If you run _this_ code as a guest inside itself, shouldn't it
> > _call_
> > VMPORT_CMD_GETPROCSPEED to get the value? :-)
>
> I don't think doing vmware esx in qemu in vmware us that much of a
> valid scenario right now ;).
>
> But I agree with anthony here - not telling vmware esx that it's
> running virtualized might be the best.
>

As I said, it would not only benefit esx.
Haiku also would likely work much better this way, and possibly BeOS
with a small driver to recalibrate it (I already rewrote such a driver
once, but it was just forcing it using a value from some settings that
were to be taken from a real machine).

François.

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

On 07.01.2009, at 11:23, François Revol wrote:

>>
>>
>>
>>
>> On 06.01.2009, at 23:33, Jamie Lokier <jamie@shareable.org> wrote:
>>
>>> Alexander Graf wrote:
>>>> If VMware ESX finds itself virtualized (read: inside VMware), it
>>>> reads the TSC speed from its backdoor, because measuring the TSC
>>>> inside a VM is not exact.
>>>>
>>>> This patch implements a hacky way to detect the TSC speed and
>>>> passes
>>>> that through to the VM. I am open to suggestions on how to improve
>>>> the behavior.  It also adds a magic return value of 2 on the
>>>> version
>>>> return, which is required by VMware ESX.  WARNING: This
>>>> implementation breaks on non-x86 hosts!
>>>
>>> If you run _this_ code as a guest inside itself, shouldn't it
>>> _call_
>>> VMPORT_CMD_GETPROCSPEED to get the value? :-)
>>
>> I don't think doing vmware esx in qemu in vmware us that much of a
>> valid scenario right now ;).
>>
>> But I agree with anthony here - not telling vmware esx that it's
>> running virtualized might be the best.
>>
>
> As I said, it would not only benefit esx.
> Haiku also would likely work much better this way, and possibly BeOS
> with a small driver to recalibrate it (I already rewrote such a driver
> once, but it was just forcing it using a value from some settings that
> were to be taken from a real machine).

If you really need to get the TSC speed, it might be best to use  
official MSRs for that. The Intel documentation definitely includes  
such an MSR.

Alex

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[François Revol]

> >> I don't think doing vmware esx in qemu in vmware us that much of a
> >> valid scenario right now ;).
> >>
> >> But I agree with anthony here - not telling vmware esx that it's
> >> running virtualized might be the best.
> >>
> >
> > As I said, it would not only benefit esx.
> > Haiku also would likely work much better this way, and possibly
> > BeOS
> > with a small driver to recalibrate it (I already rewrote such a
> > driver
> > once, but it was just forcing it using a value from some settings
> > that
> > were to be taken from a real machine).
>
> If you really need to get the TSC speed, it might be best to use
> official MSRs for that. The Intel documentation definitely includes
> such an MSR.

Oh, right then, more portable... though I wonder how they work with
speedstep...
Do we implement them yet ? grep got me some MSR_IA32_TSC in kvm.c, so I
suppose yes.
Oh, I didn't notice rdtscp, might be interesting to use instead for
Haiku.

François.

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

On 07.01.2009, at 12:32, François Revol wrote:

>>>> I don't think doing vmware esx in qemu in vmware us that much of a
>>>> valid scenario right now ;).
>>>>
>>>> But I agree with anthony here - not telling vmware esx that it's
>>>> running virtualized might be the best.
>>>>
>>>
>>> As I said, it would not only benefit esx.
>>> Haiku also would likely work much better this way, and possibly
>>> BeOS
>>> with a small driver to recalibrate it (I already rewrote such a
>>> driver
>>> once, but it was just forcing it using a value from some settings
>>> that
>>> were to be taken from a real machine).
>>
>> If you really need to get the TSC speed, it might be best to use
>> official MSRs for that. The Intel documentation definitely includes
>> such an MSR.
>
> Oh, right then, more portable... though I wonder how they work with
> speedstep...

AFAIK the TSC value register is only available if constant_tsc is  
given. This is pretty much true for all VMX/SVM capable machines I'm  
aware of.

> Do we implement them yet ? grep got me some MSR_IA32_TSC in kvm.c,  
> so I
> suppose yes.

That is the TSC value MSR I guess. So no, we don't implement them yet.  
But that sounds like a way better interface to me than the VMware  
backdoor ;).

> Oh, I didn't notice rdtscp, might be interesting to use instead for
> Haiku.

Maybe using a PV clocksource is even better ...

Alex

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[François Revol]

> > Do we implement them yet ? grep got me some MSR_IA32_TSC in kvm.c,
> > so I
> > suppose yes.
>
> That is the TSC value MSR I guess. So no, we don't implement them
> yet.
> But that sounds like a way better interface to me than the VMware
> backdoor ;).

Maybe implementing it properly would fix running ESX without the need
for vmport ?

>
> > Oh, I didn't notice rdtscp, might be interesting to use instead for
> > Haiku.
>
> Maybe using a PV clocksource is even better ...

?

François.

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Alexander Graf]

François Revol wrote:
>>> Do we implement them yet ? grep got me some MSR_IA32_TSC in kvm.c,  
>>> so I
>>> suppose yes.
>>>       
>> That is the TSC value MSR I guess. So no, we don't implement them 
>> yet.  
>> But that sounds like a way better interface to me than the VMware  
>> backdoor ;).
>>     
>
> Maybe implementing it properly would fix running ESX without the need 
> for vmport ?
>   

I haven't seen VMware accessing the relevant MSR, so I guess no :-(.

>>> Oh, I didn't notice rdtscp, might be interesting to use instead for
>>> Haiku.
>>>       
>> Maybe using a PV clocksource is even better ...
>>     
>
> ?
>   

Xenner for example uses the KVM_CLOCK to do timings, because the guest
never really knows what time it is. There was a comment on that earlier
in this thread by Avi IIRC too. If you're running virtualized, it's
usually best to use a paravirtualized clocksource.

Alex

Re: [Qemu-devel] [PATCH 1/2] [RFC] Make vmport report the processor speed

[Anthony Liguori]

Alexander Graf wrote:
> If VMware ESX finds itself virtualized (read: inside VMware), it reads the TSC speed
> from its backdoor, because measuring the TSC inside a VM is not exact.
>
> This patch implements a hacky way to detect the TSC speed and passes that through to
> the VM. I am open to suggestions on how to improve the behavior.
> It also adds a magic return value of 2 on the version return, which is required by
> VMware ESX.
>
> WARNING: This implementation breaks on non-x86 hosts!
>   

BTW, this is very broken because of CPU migration or TSC frequency 
scaling.  In general, there's no way to do this correctly from 
userspace.  Looking at /proc/cpuinfo bogomips is probably more accurate.

Regards,

Anthony Liguori

> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  hw/vmport.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/hw/vmport.c b/hw/vmport.c
> index 884af3f..825fd92 100644
> --- a/hw/vmport.c
> +++ b/hw/vmport.c
> @@ -28,6 +28,7 @@
>  
>  //#define VMPORT_DEBUG
>  
> +#define VMPORT_CMD_GETPROCSPEED 0x01
>  #define VMPORT_CMD_GETVERSION 0x0a
>  #define VMPORT_CMD_GETRAMSIZE 0x14
>  
> @@ -87,6 +88,7 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
>  {
>      CPUState *env = cpu_single_env;
>      env->regs[R_EBX] = VMPORT_MAGIC;
> +    env->regs[R_ECX] = 2;
>      return 6;
>  }
>  
> @@ -97,6 +99,25 @@ static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
>      return ram_size;
>  }
>  
> +
> +static inline int64_t rdtsc(void)
> +{
> +    int64_t val;
> +    asm volatile ("rdtsc" : "=A" (val));
> +    return val;
> +}
> +
> +static uint32_t vmport_cmd_proc_speed(void *opaque, uint32_t addr)
> +{
> +    static uint64_t tsc = 0;
> +    if ( tsc == 0 ) {
> +        tsc = rdtsc();
> +        usleep(100000);
> +        tsc = (rdtsc() - tsc) / 100000;
> +    }
> +    return (tsc / 66) * 66;
> +}
> +
>  void vmport_init(void)
>  {
>      register_ioport_read(0x5658, 1, 4, vmport_ioport_read, &port_state);
> @@ -105,4 +126,5 @@ void vmport_init(void)
>      /* Register some generic port commands */
>      vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
>      vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
> +    vmport_register(VMPORT_CMD_GETPROCSPEED, vmport_cmd_proc_speed, NULL);
>  }
>   

[Qemu-devel] [PATCH 0/2] Add Phenom CPU Descriptor

[Alexander Graf]

Having multiple different CPUs can be very conventient when trying out
if some things don't work because they require special features.

Mac OS X only running on modern Intel CPUs is an example for this. Another
example is Hyper-V, which needs a current Barcelona/Phenom CPU to run
on when it's supposed to use SVM.

This patchset implements FFXSR which is required by Hyper-V and the
Phenom CPU description. It is not sufficient to make Hyper-V boot yet,
but at least brings us one step closer to it.

Alexander Graf (2):
  Implement FFXSR
  Add phenom CPU descriptor

 target-i386/helper.c    |   28 ++++++++++++++++++++++++++++
 target-i386/op_helper.c |   28 ++++++++++++++++++++--------
 2 files changed, 48 insertions(+), 8 deletions(-)

[Qemu-devel] [PATCH 1/2] Implement FFXSR

[Alexander Graf]

Newer AMD CPUs have the FFXSR capability. This leaves out XMM
register in FXSAVE/FXRESTORE when in CPL=0 and 64-bit mode.

This is required for Hyper-V.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 target-i386/op_helper.c |   28 ++++++++++++++++++++--------
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index 8cf3bb2..c69328a 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -3030,6 +3030,8 @@ void helper_wrmsr(void)
                 update_mask |= MSR_EFER_NXE;
             if (env->cpuid_ext3_features & CPUID_EXT3_SVM)
                 update_mask |= MSR_EFER_SVME;
+            if (env->cpuid_ext2_features & CPUID_EXT2_FFXSR)
+                update_mask |= MSR_EFER_FFXSR;
             cpu_load_efer(env, (env->efer & ~update_mask) |
                           (val & update_mask));
         }
@@ -4345,10 +4347,15 @@ void helper_fxsave(target_ulong ptr, int data64)
         else
             nb_xmm_regs = 8;
         addr = ptr + 0xa0;
-        for(i = 0; i < nb_xmm_regs; i++) {
-            stq(addr, env->xmm_regs[i].XMM_Q(0));
-            stq(addr + 8, env->xmm_regs[i].XMM_Q(1));
-            addr += 16;
+        /* Fast FXSAVE leaves out the XMM registers */
+        if (!(env->efer & MSR_EFER_FFXSR)
+          || (env->hflags & HF_CPL_MASK)
+          || !(env->hflags & HF_LMA_MASK)) {
+            for(i = 0; i < nb_xmm_regs; i++) {
+                stq(addr, env->xmm_regs[i].XMM_Q(0));
+                stq(addr + 8, env->xmm_regs[i].XMM_Q(1));
+                addr += 16;
+            }
         }
     }
 }
@@ -4385,10 +4392,15 @@ void helper_fxrstor(target_ulong ptr, int data64)
         else
             nb_xmm_regs = 8;
         addr = ptr + 0xa0;
-        for(i = 0; i < nb_xmm_regs; i++) {
-            env->xmm_regs[i].XMM_Q(0) = ldq(addr);
-            env->xmm_regs[i].XMM_Q(1) = ldq(addr + 8);
-            addr += 16;
+        /* Fast FXRESTORE leaves out the XMM registers */
+        if (!(env->efer & MSR_EFER_FFXSR)
+          || (env->hflags & HF_CPL_MASK)
+          || !(env->hflags & HF_LMA_MASK)) {
+            for(i = 0; i < nb_xmm_regs; i++) {
+                env->xmm_regs[i].XMM_Q(0) = ldq(addr);
+                env->xmm_regs[i].XMM_Q(1) = ldq(addr + 8);
+                addr += 16;
+            }
         }
     }
 }
-- 
1.6.0.2

[Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Alexander Graf]

As part of my ongoing effort to make nested SVM useful, I started working to get
VMware ESX run inside KVM.

VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
a machine that officially supports SVM and should thus exploit the powers of
nested virtualization.

This patch adds a Phenom CPU identifier, that resembles a real-world phenom
CPU as closely as possible.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 target-i386/helper.c |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/target-i386/helper.c b/target-i386/helper.c
index c2da767..636a02d 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -137,6 +137,34 @@ static x86_def_t x86_defs[] = {
         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
     },
     {
+        .name = "phenom",
+        .level = 5,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 16,
+        .model = 2,
+        .stepping = 3,
+        /* Missing: CPUID_VME, CPUID_HT */
+        .features = PPRO_FEATURES | 
+            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
+            CPUID_PSE36,
+        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
+        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
+        /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
+        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) | 
+            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
+            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT | CPUID_EXT2_MMXEXT |
+            CPUID_EXT2_FFXSR,
+        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG, CPUID_EXT3_EXTAPIC,
+                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM, CPUID_EXT3_SSE4A,
+                    CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
+                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
+        .ext3_features = CPUID_EXT3_SVM,
+        .xlevel = 0x8000001A,
+        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
+    },
+    {
         .name = "core2duo",
         .level = 10,
         .family = 6,
-- 
1.6.0.2

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Anthony Liguori]

Alexander Graf wrote:
> As part of my ongoing effort to make nested SVM useful, I started working to get
> VMware ESX run inside KVM.
>
> VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
> a machine that officially supports SVM and should thus exploit the powers of
> nested virtualization.
>
> This patch adds a Phenom CPU identifier, that resembles a real-world phenom
> CPU as closely as possible.
>   

I didn't apply this last time because I dislike the idea of adding 
oodles of CPU definitions for x86.  The proper thing to do here is to 
have an fdt based description of CPU model.  That's not to say I won't 
apply this patch, but I don't like the idea of adding more and more of 
these things.

Regards,

Anthony Liguori

> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  target-i386/helper.c |   28 ++++++++++++++++++++++++++++
>  1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/target-i386/helper.c b/target-i386/helper.c
> index c2da767..636a02d 100644
> --- a/target-i386/helper.c
> +++ b/target-i386/helper.c
> @@ -137,6 +137,34 @@ static x86_def_t x86_defs[] = {
>          .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
>      },
>      {
> +        .name = "phenom",
> +        .level = 5,
> +        .vendor1 = CPUID_VENDOR_AMD_1,
> +        .vendor2 = CPUID_VENDOR_AMD_2,
> +        .vendor3 = CPUID_VENDOR_AMD_3,
> +        .family = 16,
> +        .model = 2,
> +        .stepping = 3,
> +        /* Missing: CPUID_VME, CPUID_HT */
> +        .features = PPRO_FEATURES | 
> +            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
> +            CPUID_PSE36,
> +        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
> +        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
> +        /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
> +        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) | 
> +            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
> +            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT | CPUID_EXT2_MMXEXT |
> +            CPUID_EXT2_FFXSR,
> +        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG, CPUID_EXT3_EXTAPIC,
> +                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM, CPUID_EXT3_SSE4A,
> +                    CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
> +                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
> +        .ext3_features = CPUID_EXT3_SVM,
> +        .xlevel = 0x8000001A,
> +        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
> +    },
> +    {
>          .name = "core2duo",
>          .level = 10,
>          .family = 6,
>   

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Alexander Graf]

On 27.01.2009, at 15:37, Anthony Liguori wrote:

> Alexander Graf wrote:
>> As part of my ongoing effort to make nested SVM useful, I started  
>> working to get
>> VMware ESX run inside KVM.
>>
>> VMware couples itself pretty tightly to the CPUID, so it's a good  
>> idea to emulate
>> a machine that officially supports SVM and should thus exploit the  
>> powers of
>> nested virtualization.
>>
>> This patch adds a Phenom CPU identifier, that resembles a real- 
>> world phenom
>> CPU as closely as possible.
>>
>
> I didn't apply this last time because I dislike the idea of adding  
> oodles of CPU definitions for x86.  The proper thing to do here is  
> to have an fdt based description of CPU model.  That's not to say I  
> won't apply this patch, but I don't like the idea of adding more and  
> more of these things.

I don't think an fdt based machine description is the right place to  
model CPUs. CPU capabilities are tightly coupled to qemu capabilities.  
Looking at coreduo/phenom descriptors as they are now, we are lacking  
quite some features. These might come in later, but I would guess  
machine descriptions should be rather static and user creatable.

So FWIW the fdt should rather contain a pointer to "phenom" CPU  
instead of describing every single CPUID feature.

Though honestly - we only have a "current Intel" and "current  
migratable" CPU, so we're missing a "current AMD" one just to be  
fair ;-). It's also pretty necessary for nested SVM wizardry whenever  
a guest checks which CPU it runs on (opposed to only the SVM bit like  
KVM).

Alex

>
>
> Regards,
>
> Anthony Liguori
>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> target-i386/helper.c |   28 ++++++++++++++++++++++++++++
>> 1 files changed, 28 insertions(+), 0 deletions(-)
>>
>> diff --git a/target-i386/helper.c b/target-i386/helper.c
>> index c2da767..636a02d 100644
>> --- a/target-i386/helper.c
>> +++ b/target-i386/helper.c
>> @@ -137,6 +137,34 @@ static x86_def_t x86_defs[] = {
>>         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
>>     },
>>     {
>> +        .name = "phenom",
>> +        .level = 5,
>> +        .vendor1 = CPUID_VENDOR_AMD_1,
>> +        .vendor2 = CPUID_VENDOR_AMD_2,
>> +        .vendor3 = CPUID_VENDOR_AMD_3,
>> +        .family = 16,
>> +        .model = 2,
>> +        .stepping = 3,
>> +        /* Missing: CPUID_VME, CPUID_HT */
>> +        .features = PPRO_FEATURES | +            CPUID_MTRR |  
>> CPUID_CLFLUSH | CPUID_MCA |
>> +            CPUID_PSE36,
>> +        /* Missing: CPUID_EXT_CX16, CPUID_EXT_POPCNT */
>> +        .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR,
>> +        /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
>> +        .ext2_features = (PPRO_FEATURES & 0x0183F3FF) |  
>> +            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
>> +            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT |  
>> CPUID_EXT2_MMXEXT |
>> +            CPUID_EXT2_FFXSR,
>> +        /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG,  
>> CPUID_EXT3_EXTAPIC,
>> +                    CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM,  
>> CPUID_EXT3_SSE4A,
>> +                    CPUID_EXT3_MISALIGNSSE,  
>> CPUID_EXT3_3DNOWPREFETCH,
>> +                    CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
>> +        .ext3_features = CPUID_EXT3_SVM,
>> +        .xlevel = 0x8000001A,
>> +        .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
>> +    },
>> +    {
>>         .name = "core2duo",
>>         .level = 10,
>>         .family = 6,
>>
>
>
>

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Laurent Vivier]

Le mardi 27 janvier 2009 à 08:37 -0600, Anthony Liguori a écrit :
> Alexander Graf wrote:
> > As part of my ongoing effort to make nested SVM useful, I started working to get
> > VMware ESX run inside KVM.
> >
> > VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
> > a machine that officially supports SVM and should thus exploit the powers of
> > nested virtualization.
> >
> > This patch adds a Phenom CPU identifier, that resembles a real-world phenom
> > CPU as closely as possible.
> >   
> 
> I didn't apply this last time because I dislike the idea of adding 
> oodles of CPU definitions for x86.  The proper thing to do here is to 
> have an fdt based description of CPU model.  That's not to say I won't 
> apply this patch, but I don't like the idea of adding more and more of 
> these things.

Did you try "qemu-system-ppc -cpu ?" ;-) ?
 
Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Anthony Liguori]

Laurent Vivier wrote:
> Le mardi 27 janvier 2009 à 08:37 -0600, Anthony Liguori a écrit :
>   
>> Alexander Graf wrote:
>>     
>>> As part of my ongoing effort to make nested SVM useful, I started working to get
>>> VMware ESX run inside KVM.
>>>
>>> VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
>>> a machine that officially supports SVM and should thus exploit the powers of
>>> nested virtualization.
>>>
>>> This patch adds a Phenom CPU identifier, that resembles a real-world phenom
>>> CPU as closely as possible.
>>>   
>>>       
>> I didn't apply this last time because I dislike the idea of adding 
>> oodles of CPU definitions for x86.  The proper thing to do here is to 
>> have an fdt based description of CPU model.  That's not to say I won't 
>> apply this patch, but I don't like the idea of adding more and more of 
>> these things.
>>     
>
> Did you try "qemu-system-ppc -cpu ?" ;-) ?
>   

Which is precisely what I'd like to avoid :-)

Although this is a bit different.  We aren't actually emulating a 
phenom.  We're just taking what we have and calling it a phenom.  I 
suspect there's going to be a desire to call whatever we emulate 
arbitrary things.

Regards,

Anthony LIguori

> Regards,
> Laurent
>   

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Paul Brook]

> >> I didn't apply this last time because I dislike the idea of adding
> >> oodles of CPU definitions for x86.  The proper thing to do here is to
> >> have an fdt based description of CPU model.  That's not to say I won't
> >> apply this patch, but I don't like the idea of adding more and more of
> >> these things.
> >
> > Did you try "qemu-system-ppc -cpu ?" ;-) ?
>
> Which is precisely what I'd like to avoid :-)
>
> Although this is a bit different.  We aren't actually emulating a
> phenom.  We're just taking what we have and calling it a phenom.  I
> suspect there's going to be a desire to call whatever we emulate
> arbitrary things.

I don't think we're likely to want the big list of cpus anyway.

The real problem is that the x86 translation code ignores most of the CPU 
feature bits, and implements everything all the time.

Paul

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Paul Brook]

> > Although this is a bit different.  We aren't actually emulating a
> > phenom.  We're just taking what we have and calling it a phenom.  I
> > suspect there's going to be a desire to call whatever we emulate
> > arbitrary things.
>
> I don't think we're likely to want the big list of cpus anyway.

Argh. I got that completely wrong.I mean we *are* likely to want a big list of 
cpus anyway. If done properly it should be fairly easy to maintain.
e.g. instead of missing out unimplemented feature flags in each cpu, add them 
all, then have qemu mask out the ones it doesn't implement.

Paul

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Jamie Lokier]

Paul Brook wrote:
> > > Although this is a bit different.  We aren't actually emulating a
> > > phenom.  We're just taking what we have and calling it a phenom.  I
> > > suspect there's going to be a desire to call whatever we emulate
> > > arbitrary things.
> >
> > I don't think we're likely to want the big list of cpus anyway.
> 
> Argh. I got that completely wrong.I mean we *are* likely to want a
> big list of cpus anyway. If done properly it should be fairly easy
> to maintain.  e.g. instead of missing out unimplemented feature
> flags in each cpu, add them all, then have qemu mask out the ones it
> doesn't implement.

That's an excellent idea.  The CPU list is a bit of historical
documentation of real CPU capabilities among other things, and not all
easy to verify, so having it be correct, and then QEMU masking things
out, sounds good to me.

-- Jamie

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Amit Shah]

On (Tue) Jan 27 2009 [22:56:40], Paul Brook wrote:
> > > Although this is a bit different.  We aren't actually emulating a
> > > phenom.  We're just taking what we have and calling it a phenom.  I
> > > suspect there's going to be a desire to call whatever we emulate
> > > arbitrary things.
> >
> > I don't think we're likely to want the big list of cpus anyway.
> 
> Argh. I got that completely wrong.I mean we *are* likely to want a big list of 
> cpus anyway. If done properly it should be fairly easy to maintain.
> e.g. instead of missing out unimplemented feature flags in each cpu, add them 
> all, then have qemu mask out the ones it doesn't implement.

What I'm thinking of is moving all the CPU definitions out from helper.c
into $(PREFIX)/usr/share/qemu/cpu-defs/... with one file holding one
definition, like
$ cat core2duo.def
model= 15
family = 16
stepping = 11
level = 10
.
.
.

Adding a new def then just becomes a matter of submitting a text file
for inclusion and doesn't need any recompilation.

Also, there are many details not captured in a CPU def, like the cache
sizes and types. They're hard-coded for all the CPUs in the cpuid helper
function. So we could have those values too incorporated in the CPU def
file an fall back to the defaults when not available.

When we do get some kind of a machine FDT, we can specify the cpu type
by either pointing to one of these files or by constructing a new CPU
type by specifying individual values.

Amit

Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor

[Alexander Graf]

On 27.01.2009, at 23:39, Paul Brook <paul@codesourcery.com> wrote:

>>>> I didn't apply this last time because I dislike the idea of adding
>>>> oodles of CPU definitions for x86.  The proper thing to do here  
>>>> is to
>>>> have an fdt based description of CPU model.  That's not to say I  
>>>> won't
>>>> apply this patch, but I don't like the idea of adding more and  
>>>> more of
>>>> these things.
>>>
>>> Did you try "qemu-system-ppc -cpu ?" ;-) ?
>>
>> Which is precisely what I'd like to avoid :-)
>>
>> Although this is a bit different.  We aren't actually emulating a
>> phenom.  We're just taking what we have and calling it a phenom.  I
>> suspect there's going to be a desire to call whatever we emulate
>> arbitrary things.
>
> I don't think we're likely to want the big list of cpus anyway.
>
> The real problem is that the x86 translation code ignores most of  
> the CPU
> feature bits, and implements everything all the time.

While that's true for quite some old features, at least x86_64/amd  
extensions are usually guarded by efer, which does read the cpuid  
bits. I'm also trying to do those checks with new features, like the  
ffxsr one.

(that is btw the reason, applying 1/2 of this series doesn't hurt  
anyone)

But yes, decoupling the cpu descriptors from qemu emulation  
capabilities sounds like a good idea. Kqemu and kvm certainly have  
different masks here ;).

Alex

>
>
> Paul
>
>