Skip to content

L
linux
Switch branch/tag
  1. 23 Nov, 2008 2 commits
    • Hannes Eder's avatar
      x86: hypervisor - fix sparse warnings · 4e42ebd5
      Hannes Eder authored 
      Impact: fix sparse build warning

Fix the following sparse warnings:

  arch/x86/kernel/cpu/hypervisor.c:37:15: warning: symbol
  'get_hypervisor_tsc_freq' was not declared. Should it be static?
  arch/x86/kernel/cpu/hypervisor.c:53:16: warning: symbol
  'init_hypervisor' was not declared. Should it be static?
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Cc: "Alok N Kataria" <akataria@vmware.com>
Cc: "Dan Hecht" <dhecht@vmware.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4e42ebd5
    • Hannes Eder's avatar
      x86: vmware - fix sparse warnings · c450d780
      Hannes Eder authored 
      Impact: fix sparse build warning

Fix the following sparse warnings:

arch/x86/kernel/cpu/vmware.c:69:5: warning: symbol 'vmware_platform'
was not declared. Should it be static?
arch/x86/kernel/cpu/vmware.c:89:15: warning: symbol
'vmware_get_tsc_khz' was not declared. Should it be static?
arch/x86/kernel/cpu/vmware.c:107:16: warning: symbol
'vmware_set_feature_bits' was not declared. Should it be static?
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Cc: "Alok N Kataria" <akataria@vmware.com>
Cc: "Dan Hecht" <dhecht@vmware.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c450d780
  3. 04 Nov, 2008 1 commit
    • Alok Kataria's avatar
      x86: vmware: look for DMI string in the product serial key · fd8cd7e1
      Alok Kataria authored 
      Impact: Should permit VMware detection on older platforms where the
vendor is changed.  Could theoretically cause a regression if some
weird serial number scheme contains the string "VMware" by pure
chance.  Seems unlikely, especially with the mixed case.

In some user configured cases, VMware may choose not to put a VMware specific
DMI string, but the product serial key is always there and is VMware specific.
Add a interface to check the serial key, when checking for VMware in the DMI
information.
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      fd8cd7e1
  5. 03 Nov, 2008 1 commit
    • Alok Kataria's avatar
      x86: VMware: Fix vmware_get_tsc code · 6bdbfe99
      Alok Kataria authored 
      Impact: Fix possible failure to calibrate the TSC on Vmware near 4 GHz

The current version of the code to get the tsc frequency from
the VMware hypervisor, will be broken on processor with frequency
(4G-1) HZ, because on such processors eax will have UINT_MAX
and that would be legitimate.
We instead check that EBX did change to decide if we were able to
read the frequency from the hypervisor.
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6bdbfe99
  7. 02 Nov, 2008 4 commits
    • Alok Kataria's avatar
      x86: Skip verification by the watchdog for TSC clocksource. · 395628ef
      Alok Kataria authored 
      Impact: Changes timekeeping on Vmware (or with tsc=reliable).

This is achieved by resetting the CLOCKSOURCE_MUST_VERIFY flag.

We add a tsc=reliable commandline option to enable this.
This enables legacy hardware without HPET, LAPIC, or ACPI timers
to enter high-resolution timer mode.

Along with that have extended this to be used in virtualization environement
too. Now we also set this flag if the X86_FEATURE_TSC_RELIABLE bit is set.

This is important since there is a wrap-around problem with the acpi_pm timer.
The acpi_pm counter is just 24bits and this can overflow in ~4 seconds. With
the NO_HZ kernels in virtualized environment, there can be situations when
the guest is descheduled for longer duration, as a result we may miss the wrap
of the acpi counter. When TSC is used as a clocksource and acpi_pm timer is
being used as the watchdog clocksource this error in acpi_pm results in TSC
being marked as unstable, and essentially results in time dropping in chunks
of 4 seconds whenever this wrap is missed. Since the virtualized TSC is
reliable on VMware, we should always use the TSCs clocksource on VMware, so
we skip the verfication at runtime, by checking for the feature bit.

Since we reset the flag for mgeode systems too, i have combined
the mgeode case with the feature bit check.
Signed-off-by: default avatarJeff Hansen <jhansen@cardaccess-inc.com>
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarDan Hecht <dhecht@vmware.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      395628ef
    • Alok Kataria's avatar
      x86: Add a synthetic TSC_RELIABLE feature bit. · eca0cd02
      Alok Kataria authored 
      Impact: Changes timebase calibration on Vmware.

Use the synthetic TSC_RELIABLE bit to workaround virtualization anomalies.

Virtual TSCs can be kept nearly in sync, but because the virtual TSC
offset is set by software, it's not perfect.  So, the TSC
synchronization test can fail. Even then the TSC can be used as a
clocksource since the VMware platform exports a reliable TSC to the
guest for timekeeping purposes. Use this bit to check if we need to
skip the TSC sync checks.

Along with this also set the CONSTANT_TSC bit when on VMware, since we
still want to use TSC as clocksource on VM running over hardware which
has unsynchronized TSC's (opteron's), since the hypervisor will take
care of providing consistent TSC to the guest.
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarDan Hecht <dhecht@vmware.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      eca0cd02
    • Alok Kataria's avatar
      x86: Hypervisor detection and get tsc_freq from hypervisor · 88b094fb
      Alok Kataria authored 
      Impact: Changes timebase calibration on Vmware.

v3->v2 : Abstract the hypervisor detection and feature (tsc_freq) request
	 behind a hypervisor.c file
v2->v1 : Add a x86_hyper_vendor field to the cpuinfo_x86 structure.
	 This avoids multiple calls to the hypervisor detection function.

This patch adds function to detect if we are running under VMware.
The current way to check if we are on VMware is following,
#  check if "hypervisor present bit" is set, if so read the 0x40000000
   cpuid leaf and check for "VMwareVMware" signature.
#  if the above fails, check the DMI vendors name for "VMware" string
   if we find one we query the VMware hypervisor port to check if we are
   under VMware.

The DMI + "VMware hypervisor port check" is needed for older VMware products,
which don't implement the hypervisor signature cpuid leaf.
Also note that since we are checking for the DMI signature the hypervisor
port should never be accessed on native hardware.

This patch also adds a hypervisor_get_tsc_freq function, instead of
calibrating the frequency which can be error prone in virtualized
environment, we ask the hypervisor for it. We get the frequency from
the hypervisor by accessing the hypervisor port if we are running on VMware.
Other hypervisors too can add code to the generic routine to get frequency on
their platform.
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarDan Hecht <dhecht@vmware.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      88b094fb
    • Alok Kataria's avatar
      x86: add X86_FEATURE_HYPERVISOR feature bit · 49ab56ac
      Alok Kataria authored 
      Impact: Number declaration only.

Add X86_FEATURE_HYPERVISOR bit (CPUID level 1, ECX, bit 31).
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      49ab56ac
  9. 31 Oct, 2008 12 commits
  11. 30 Oct, 2008 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7