Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 31 10月, 2012 2 次提交
    • E
      i386: kvm: reformat filter_features_for_kvm() code · b8091f24
      由 Eduardo Habkost 提交于 
      Cosmetic, but it will also help to make futher patches easier to review.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      b8091f24
    • E
      i386: kvm: filter CPUID feature words earlier, on cpu.c · bc74b7db
      由 Eduardo Habkost 提交于 
      cpu.c contains the code that will check if all requested CPU features
are available, so the filtering of KVM features must be there, so we can
implement "check" and "enforce" properly.

The only point where kvm_arch_init_vcpu() is called on i386 is:

- cpu_x86_init()
  - x86_cpu_realize() (after cpu_x86_register() is called)
    - qemu_init_vcpu()
      - qemu_kvm_start_vcpu()
        - qemu_kvm_thread_fn() (on a new thread)
          - kvm_init_vcpu()
            - kvm_arch_init_vcpu()

With this patch, the filtering will be done earlier, at:
- cpu_x86_init()
  - cpu_x86_register() (before x86_cpu_realize() is called)

Also, the KVM CPUID filtering will now be done at the same place where
the TCG CPUID feature filtering is done. Later, the code can be changed
to use the same filtering code for the "check" and "enforce" modes, as
now the cpu.c code knows exactly which CPU features are going to be
exposed to the guest (and much earlier).

One thing I was worrying about when doing this is that
kvm_arch_get_supported_cpuid() depends on kvm_irqchip_in_kernel(), and
maybe the 'kvm_kernel_irqchip' global variable wasn't initialized yet at
CPU creation time. But kvm_kernel_irqchip is initialized during
kvm_init(), that is called very early (much earlier than the machine
init function), and kvm_init() is already a requirement to run the
GET_SUPPORTED_CPUID ioctl() (as kvm_init() initializes the kvm_state
global variable).

Side note: it would be nice to keep KVM-specific code inside kvm.c. The
problem is that properly implementing -cpu check/enforce code (that's
inside cpu.c) depends directly on the feature bit filtering done using
kvm_arch_get_supported_cpuid(). Currently -cpu check/enforce is broken
because it simply uses the host CPU feature bits instead of
GET_SUPPORTED_CPUID, and we need to fix that.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      bc74b7db
  3. 29 10月, 2012 1 次提交
  5. 28 10月, 2012 1 次提交
  7. 05 10月, 2012 1 次提交
  9. 01 10月, 2012 1 次提交
    • H
      x86: Implement SMEP and SMAP · a9321a4d
      由 H. Peter Anvin 提交于 
      This patch implements Supervisor Mode Execution Prevention (SMEP) and
Supervisor Mode Access Prevention (SMAP) for x86.  The purpose of the
patch, obviously, is to help kernel developers debug the support for
those features.

A fair bit of the code relates to the handling of CPUID features.  The
CPUID code probably would get greatly simplified if all the feature
bit words were unified into a single vector object, but in the
interest of producing a minimal patch for SMEP/SMAP, and because I had
very limited time for this project, I followed the existing style.

[ v2: don't change the definition of the qemu64 CPU shorthand, since
  that breaks loading old snapshots.  Per Anthony Liguori this can be
  fixed once the CPU feature set is snapshot.

  Change the coding style slightly to conform to checkpatch.pl. ]
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      a9321a4d
  11. 30 9月, 2012 3 次提交
  13. 23 9月, 2012 1 次提交
  15. 21 9月, 2012 6 次提交
  17. 31 8月, 2012 1 次提交
  19. 29 8月, 2012 1 次提交
    • A
      target-i386: disable pv eoi to fix migration across QEMU versions · ef8621b1
      由 Anthony Liguori 提交于 
      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: NAnthony Liguori <aliguori@us.ibm.com>
      ef8621b1
  21. 16 8月, 2012 1 次提交
  23. 14 8月, 2012 1 次提交
  25. 01 8月, 2012 2 次提交
  27. 21 7月, 2012 1 次提交
  29. 04 7月, 2012 1 次提交
  31. 25 6月, 2012 1 次提交
  33. 22 6月, 2012 1 次提交
  35. 20 6月, 2012 1 次提交
  37. 08 6月, 2012 1 次提交
  39. 30 5月, 2012 1 次提交
    • E
      Expose CPUID leaf 7 only for -cpu host · 13526728
      由 Eduardo Habkost 提交于 
      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: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      13526728
  41. 12 5月, 2012 1 次提交
    • A
      target-i386: Defer MCE init · 7a059953
      由 Andreas Färber 提交于 
      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: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
      7a059953
  43. 27 4月, 2012 1 次提交
  45. 25 4月, 2012 9 次提交