1. 24 Nov, 2014 1 commit
    • Paolo Bonzini's avatar
      apic: avoid getting out of halted state on masked PIC interrupts · 60e68042
      Paolo Bonzini authored
      After the next patch, if a masked PIC interrupts causes CPU_INTERRUPT_POLL
      to be set, the CPU will spuriously get out of halted state.  While this
      is technically valid, we should avoid that.
      
      Make CPU_INTERRUPT_POLL run apic_update_irq in the right thread and then
      look at CPU_INTERRUPT_HARD.  If CPU_INTERRUPT_HARD does not get set,
      do not report the CPU as having work.
      
      Also move the handling of software-disabled APIC from apic_update_irq
      to apic_irq_pending, and always trigger CPU_INTERRUPT_POLL.  This will
      be important once we will add a case that resets CPU_INTERRUPT_HARD
      from apic_update_irq.  We want to run it even if we go through
      CPU_INTERRUPT_POLL, and even if the local APIC is software disabled.
      Reported-by: default avatarRichard Bilson <rbilson@qnx.com>
      Tested-by: default avatarRichard Bilson <rbilson@qnx.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      60e68042
  2. 13 Nov, 2014 1 commit
  3. 12 Nov, 2014 1 commit
  4. 11 Nov, 2014 1 commit
  5. 04 Nov, 2014 4 commits
    • Eduardo Habkost's avatar
      target-i386: Disable SVM by default in KVM mode · 75d373ef
      Eduardo Habkost authored
      Make SVM be disabled by default on all CPU models when in KVM mode.
      Nested SVM is enabled by default in the KVM kernel module, but it is
      probably less stable than nested VMX (which is already disabled by
      default).
      
      Add a new compat function, x86_cpu_compat_kvm_no_autodisable(), to keep
      compatibility on previous machine-types.
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      75d373ef
    • Eduardo Habkost's avatar
      target-i386: Don't enable nested VMX by default · e93abc14
      Eduardo Habkost authored
      TCG doesn't support VMX, and nested VMX is not enabled by default in the
      KVM kernel module.
      
      So, there's no reason to have VMX enabled by default on the core2duo and
      coreduo CPU models, today. Even the newer Intel CPU model definitions
      don't have it enabled.
      
      In this case, we need machine-type compat code, as people may be running
      the older machine-types on hosts that had VMX nesting enabled.
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      e93abc14
    • Eduardo Habkost's avatar
      target-i386: Remove unsupported bits from all CPU models · b9fc20bc
      Eduardo Habkost authored
      The following CPU features were never supported by neither TCG or KVM,
      so they are useless on the CPU model definitions, today:
      
       * CPUID_DTS (DS)
       * CPUID_HT
       * CPUID_TM
       * CPUID_PBE
       * CPUID_EXT_DTES64
       * CPUID_EXT_DSCPL
       * CPUID_EXT_EST
       * CPUID_EXT_TM2
       * CPUID_EXT_XTPR
       * CPUID_EXT_PDCM
       * CPUID_SVM_LBRV
      
      As using "enforce" mode is the only way to ensure guest ABI doesn't
      change when moving to a different host, we should make "enforce" mode
      the default or at least encourage management software to always use it.
      
      In turn, to make "enforce" usable, we need CPU models that work without
      always requiring some features to be explicitly disabled. This patch
      removes the above features from all CPU model definitions.
      
      We won't need any machine-type compat code for those changes, because it
      is impossible to have existing VMs with those features enabled.
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      b9fc20bc
    • Eduardo Habkost's avatar
      target-i386: Disable CPUID_ACPI by default in KVM mode · 864867b9
      Eduardo Habkost authored
      KVM never supported the CPUID_ACPI flag, so it doesn't make sense to
      have it enabled by default when KVM is enabled.
      
      The motivation here is exactly the same we had for the MONITOR flag
      (disabled by commit 136a7e9a).
      
      And like in the MONITOR flag case, we don't need machine-type compat code
      because it is currently impossible to run a KVM VM with the ACPI flag set.
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      864867b9
  6. 03 Nov, 2014 1 commit
  7. 02 Nov, 2014 1 commit
  8. 31 Oct, 2014 1 commit
  9. 24 Oct, 2014 1 commit
  10. 23 Oct, 2014 1 commit
  11. 25 Sep, 2014 2 commits
  12. 18 Sep, 2014 1 commit
  13. 12 Sep, 2014 1 commit
  14. 05 Sep, 2014 2 commits
  15. 26 Aug, 2014 2 commits
  16. 25 Aug, 2014 4 commits
    • Alex Williamson's avatar
      x86: Clear MTRRs on vCPU reset · 9db2efd9
      Alex Williamson authored
      The SDM specifies (June 2014 Vol3 11.11.5):
      
          On a hardware reset, the P6 and more recent processors clear the
          valid flags in variable-range MTRRs and clear the E flag in the
          IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
          MTRRs are undefined.
      
      We currently do none of that, so whatever MTRR settings you had prior
      to reset is what you have after reset.  Usually this doesn't matter
      because KVM often ignores the guest mappings and uses write-back
      anyway.  However, if you have an assigned device and an IOMMU that
      allows NoSnoop for that device, KVM defers to the guest memory
      mappings which are now stale after reset.  The result is that OVMF
      rebooting on such a configuration takes a full minute to LZMA
      decompress the firmware volume, a process that is nearly instant on
      the initial boot.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9db2efd9
    • Alex Williamson's avatar
      x86: kvm: Add MTRR support for kvm_get|put_msrs() · d1ae67f6
      Alex Williamson authored
      The MTRR state in KVM currently runs completely independent of the
      QEMU state in CPUX86State.mtrr_*.  This means that on migration, the
      target loses MTRR state from the source.  Generally that's ok though
      because KVM ignores it and maps everything as write-back anyway.  The
      exception to this rule is when we have an assigned device and an IOMMU
      that doesn't promote NoSnoop transactions from that device to be cache
      coherent.  In that case KVM trusts the guest mapping of memory as
      configured in the MTRR.
      
      This patch updates kvm_get|put_msrs() so that we retrieve the actual
      vCPU MTRR settings and therefore keep CPUX86State synchronized for
      migration.  kvm_put_msrs() is also used on vCPU reset and therefore
      allows future modificaitons of MTRR state at reset to be realized.
      
      Note that the entries array used by both functions was already
      slightly undersized for holding every possible MSR, so this patch
      increases it beyond the 28 new entries necessary for MTRR state.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d1ae67f6
    • Alex Williamson's avatar
      x86: Use common variable range MTRR counts · d8b5c67b
      Alex Williamson authored
      We currently define the number of variable range MTRR registers as 8
      in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
      (also 8) to report to guests the number available.  Change this to
      use MSR_MTRRcap_VCNT consistently.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d8b5c67b
    • William Grant's avatar
      target-i386: Don't forbid NX bit on PAE PDEs and PTEs · 1844e68e
      William Grant authored
      Commit e8f6d00c ("target-i386: raise
      page fault for reserved physical address bits") added a check that the
      NX bit is not set on PAE PDPEs, but it also added it to rsvd_mask for
      the rest of the function. This caused any PDEs or PTEs with NX set to be
      erroneously rejected, making PAE guests with NX support unusable.
      Signed-off-by: default avatarWilliam Grant <wgrant@ubuntu.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1844e68e
  17. 22 Aug, 2014 1 commit
  18. 12 Aug, 2014 1 commit
  19. 08 Aug, 2014 1 commit
  20. 15 Jul, 2014 1 commit
  21. 10 Jul, 2014 1 commit
  22. 25 Jun, 2014 10 commits