1. 03 7月, 2010 2 次提交
  2. 29 6月, 2010 1 次提交
  3. 19 6月, 2010 3 次提交
  4. 13 3月, 2010 2 次提交
  5. 23 2月, 2010 1 次提交
    • J
      Add cpu model configuration support.. · b5ec5ce0
      john cooper 提交于
      This is a reimplementation of prior versions which adds
      the ability to define cpu models for contemporary processors.
      The added models are likewise selected via -cpu <name>,
      and are intended to displace the existing convention
      of "-cpu qemu64" augmented with a series of feature flags.
      
      A primary motivation was determination of a least common
      denominator within a given processor class to simplify guest
      migration.  It is still possible to modify an arbitrary model
      via additional feature flags however the goal here was to
      make doing so unnecessary in typical usage.  The other
      consideration was providing models names reflective of
      current processors.  Both AMD and Intel have reviewed the
      models in terms of balancing generality of migration vs.
      excessive feature downgrade relative to released silicon.
      
      This version of the patch replaces the prior hard wired
      definitions with a configuration file approach for new
      models.  Existing models are thus far left as-is but may
      easily be transitioned to (or may be overridden by) the
      configuration file representation.
      
      Proposed new model definitions are provided here for current
      AMD and Intel processors.  Each model consists of a name
      used to select it on the command line (-cpu <name>), and a
      model_id which corresponds to a least common denominator
      commercial instance of the processor class.
      
      A table of names/model_ids may be queried via "-cpu ?model":
      
              :
          x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
          x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
          x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
          x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
          x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
          x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
              :
      
      Also added is "-cpu ?dump" which exhaustively outputs all config
      data for all defined models, and "-cpu ?cpuid" which enumerates
      all qemu recognized CPUID feature flags.
      
      The pseudo cpuid flag 'check' when added to the feature flag list
      will warn when feature flags (either implicit in a cpu model or
      explicit on the command line) would have otherwise been quietly
      unavailable to a guest:
      
          # qemu-system-x86_64 ... -cpu Nehalem,check
          warning: host cpuid 0000_0001 lacks requested flag 'sse4.2|sse4_2' [0x00100000]
          warning: host cpuid 0000_0001 lacks requested flag 'popcnt' [0x00800000]
      
      A similar 'enforce' pseudo flag exists which in addition
      to the above causes qemu to error exit if requested flags are
      unavailable.
      
      Configuration data for a cpu model resides in the target config
      file which by default will be installed as:
      
          /usr/local/etc/qemu/target-<arch>.conf
      
      The format of this file should be self explanatory given the
      definitions for the above six models and essentially mimics
      the structure of the static x86_def_t x86_defs.
      
      Encoding of cpuid flags names now allows aliases for both the
      configuration file and the command line which reconciles some
      Intel/AMD/Linux/Qemu naming differences.
      
      This patch was tested relative to qemu.git.
      Signed-off-by: Njohn cooper <john.cooper@redhat.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      b5ec5ce0
  6. 14 1月, 2010 1 次提交
  7. 19 12月, 2009 2 次提交
  8. 12 12月, 2009 1 次提交
  9. 04 12月, 2009 1 次提交
  10. 17 11月, 2009 1 次提交
  11. 06 10月, 2009 1 次提交
  12. 05 10月, 2009 10 次提交
  13. 04 10月, 2009 1 次提交
    • A
      target-i386: add RDTSCP support · 1b050077
      Andre Przywara 提交于
      RDTSCP reads the time stamp counter and atomically also the content
      of a 32-bit MSR, which can be freely set by the OS. This allows CPU
      local data to be queried by userspace.
      Linux uses this to allow a fast implementation of the getcpu()
      syscall, which uses the vsyscall page to avoid a context switch.
      AMD CPUs since K8RevF and Intel CPUs since Nehalem support this
      instruction.
      RDTSCP is guarded by the RDTSCP CPUID bit (Fn8000_0001:EDX[27]).
      Signed-off-by: NAndre Przywara <andre.przywara@amd.com>
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      1b050077
  14. 24 8月, 2009 2 次提交
    • N
      cleanup cpu-exec.c, part 0/N: consolidate handle_cpu_signal · 0b5c1ce8
      Nathan Froyd 提交于
      handle_cpu_signal is very nearly copy-paste code for each target, with a
      few minor variations.  This patch sets up appropriate defaults for a
      generic handle_cpu_signal and provides overrides for particular targets
      that did things differently.  Fixing things like the persistent (XXX:
      use sigsetjmp) should now become somewhat easier.
      
      Previous comments on this patch suggest that the "activate soft MMU for
      this block" comments refer to defunct functionality.  I have removed
      such blocks for the appropriate targets in this patch.
      Signed-off-by: NNathan Froyd <froydnj@codesourcery.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      0b5c1ce8
    • A
      Unbreak large mem support by removing kqemu · 4a1418e0
      Anthony Liguori 提交于
      kqemu introduces a number of restrictions on the i386 target.  The worst is that
      it prevents large memory from working in the default build.
      
      Furthermore, kqemu is fundamentally flawed in a number of ways.  It relies on
      the TSC as a time source which will not be reliable on a multiple processor
      system in userspace.  Since most modern processors are multicore, this severely
      limits the utility of kqemu.
      
      kvm is a viable alternative for people looking to accelerate qemu and has the
      benefit of being supported by the upstream Linux kernel.  If someone can
      implement work arounds to remove the restrictions introduced by kqemu, I'm
      happy to avoid and/or revert this patch.
      
      N.B. kqemu will still function in the 0.11 series but this patch removes it from
      the 0.12 series.
      
      Paul, please Ack or Nack this patch.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4a1418e0
  15. 28 7月, 2009 1 次提交
  16. 17 7月, 2009 1 次提交
  17. 16 7月, 2009 1 次提交
  18. 11 7月, 2009 1 次提交
  19. 10 7月, 2009 1 次提交
  20. 30 6月, 2009 1 次提交
  21. 22 6月, 2009 1 次提交
    • G
      Handle init/sipi in a main cpu exec loop. (v2) · b09ea7d5
      Gleb Natapov 提交于
      This should fix compilation problem in case of CONFIG_USER_ONLY.
      
      Currently INIT/SIPI is handled in the context of CPU that sends IPI.
      This patch changes this to handle them like all other events in a main
      cpu exec loop. When KVM will gain thread per vcpu capability it will
      be much more clear to handle those event by cpu thread itself and not
      modify one cpu's state from the context of the other.
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      b09ea7d5
  22. 17 6月, 2009 1 次提交
  23. 22 5月, 2009 2 次提交
  24. 19 4月, 2009 1 次提交