[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);
>  }
>