1. 30 Aug, 2012 1 commit
  2. 29 Aug, 2012 1 commit
    • Anthony Liguori's avatar
      target-i386: disable pv eoi to fix migration across QEMU versions · ef8621b1
      Anthony Liguori authored
      
      
      We have a problem with how we handle migration with KVM paravirt features.
      We unconditionally enable paravirt features regardless of whether we know how
      to migrate them.
      
      We also don't tie paravirt features to specific machine types so an old QEMU on
      a new kernel would expose features that never existed.
      
      The 1.2 cycle is over and as things stand, migration is broken.  Michael has
      another series that adds support for migrating PV EOI and attempts to make it
      work correctly for different machine types.
      
      After speaking with Michael on IRC, we agreed to take this patch plus 1 & 4
      from his series.  This makes sure QEMU can migrate PV EOI if it's enabled, but
      does not enable it by default.
      
      This also means that we won't unconditionally enable new features for guests
      future proofing us from this happening again in the future.
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      ef8621b1
  3. 15 Aug, 2012 1 commit
  4. 13 Aug, 2012 1 commit
  5. 01 Aug, 2012 2 commits
  6. 21 Jul, 2012 1 commit
  7. 03 Jul, 2012 1 commit
  8. 25 Jun, 2012 1 commit
  9. 22 Jun, 2012 1 commit
  10. 19 Jun, 2012 1 commit
  11. 08 Jun, 2012 1 commit
  12. 29 May, 2012 1 commit
    • Eduardo Habkost's avatar
      Expose CPUID leaf 7 only for -cpu host · 13526728
      Eduardo Habkost authored
      
      
      Changes v2 -> v3;
        - Check for kvm_enabled() before setting cpuid_7_0_ebx_features
      
      Changes v1 -> v2:
        - Use kvm_arch_get_supported_cpuid() instead of host_cpuid() on
          cpu_x86_fill_host().
      
        We should use GET_SUPPORTED_CPUID for all bits on "-cpu host"
        eventually, but I am not changing all the other CPUID leaves because
        we may not be able to test such an intrusive change in time for 1.1.
      
      Description of the bug:
      
      Since QEMU 0.15, the CPUID information on CPUID[EAX=7,ECX=0] is being
      returned unfiltered to the guest, directly from the GET_SUPPORTED_CPUID
      return value.
      
      The problem is that this makes the resulting CPU feature flags
      unpredictable and dependent on the host CPU and kernel version. This
      breaks live-migration badly if migrating from a host CPU that supports
      some features on that CPUID leaf (running a recent kernel) to a kernel
      or host CPU that doesn't support it.
      
      Migration also is incorrect (the virtual CPU changes under the guest's
      feet) if you migrate in the opposite direction (from an old CPU/kernel
      to a new CPU/kernel), but with less serious consequences (guests
      normally query CPUID information only once on boot).
      
      Fortunately, the bug affects only users using cpudefs with level >= 7.
      
      The right behavior should be to explicitly enable those features on
      [cpudef] config sections or on the "-cpu" command-line arguments. Right
      now there is no predefined CPU model on QEMU that has those features:
      the latest Intel model we have is Sandy Bridge.
      
      I would like to get this fixed on 1.1, so I am submitting this patch,
      that enables those features only if "-cpu host" is being used (as we
      don't have any pre-defined CPU model that actually have those features).
      After 1.1 is released, we can make those features properly configurable
      on [cpudef] and -cpu configuration.
      
      One problem is: with this patch, users with the following setup:
      - Running QEMU 1.0;
      - Using a cpudef having level >= 7;
      - Running a kernel that supports the features on CPUID leaf 7; and
      - Running on a CPU that supports some features on CPUID leaf 7
      won't be able to live-migrate to QEMU 1.1. But for these users
      live-migration is already broken (they can't live-migrate to hosts with
      older CPUs or older kernels, already), I don't see how to avoid this
      problem.
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      13526728
  13. 12 May, 2012 1 commit
    • Andreas Färber's avatar
      target-i386: Defer MCE init · 7a059953
      Andreas Färber authored
      Commit de024815
      
       (target-i386: QOM'ify
      CPU init) moved mce_init() call from helper.c:cpu_x86_init() into
      X86CPU's cpu.c:x86_cpu_initfn().
      mce_init() checks for a family >= 6 though, so we could end up with a
      sequence such as for -cpu somecpu,family=6:
      
        x86_cpu_initfn => X86CPU::family == 5
          mce_init => no-op
        cpu_x86_register => X86CPU::family = 6
        => MCE unexpectedly not init'ed
      
      or for -cpu someothercpu,family=5:
      
        x86_cpu_initfn => X86CPU::family == 6
          mce_init => init'ed
        cpu_x86_register => X86CPU::family = 5
        => MCE unexpectedly init'ed
      
      Therefore partially revert the above commit. To avoid moving
      mce_init() back into helper.c, foresightedly move it into a
      new x86_cpu_realize() function and, in lack of ObjectClass::realize,
      call it directly from cpu_x86_init().
      
      While at it, move the qemu_init_vcpu() call that used to follow
      mce_init() in cpu_x86_init() into the new realizefn as well.
      Reported-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-by: default avatarIgor Mammedov <imammedo@redhat.com>
      7a059953
  14. 26 Apr, 2012 1 commit
  15. 25 Apr, 2012 15 commits
  16. 10 Apr, 2012 4 commits
  17. 12 Mar, 2012 1 commit
  18. 24 Feb, 2012 4 commits
  19. 22 Feb, 2012 1 commit