1. 04 11月, 2008 1 次提交
    • A
      x86: VMware: Fix vmware_get_tsc code · 6bdbfe99
      Alok Kataria 提交于
      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: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6bdbfe99
  2. 02 11月, 2008 4 次提交
    • A
      x86: Skip verification by the watchdog for TSC clocksource. · 395628ef
      Alok Kataria 提交于
      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: NJeff Hansen <jhansen@cardaccess-inc.com>
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NDan Hecht <dhecht@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      395628ef
    • A
      x86: Add a synthetic TSC_RELIABLE feature bit. · eca0cd02
      Alok Kataria 提交于
      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: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NDan Hecht <dhecht@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      eca0cd02
    • A
      x86: Hypervisor detection and get tsc_freq from hypervisor · 88b094fb
      Alok Kataria 提交于
      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: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NDan Hecht <dhecht@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      88b094fb
    • A
      x86: add X86_FEATURE_HYPERVISOR feature bit · 49ab56ac
      Alok Kataria 提交于
      Impact: Number declaration only.
      
      Add X86_FEATURE_HYPERVISOR bit (CPUID level 1, ECX, bit 31).
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      49ab56ac
  3. 01 11月, 2008 1 次提交
  4. 31 10月, 2008 34 次提交