Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 14 1月, 2019 1 次提交
  3. 07 1月, 2019 1 次提交
  5. 12 12月, 2018 4 次提交
  7. 07 11月, 2018 1 次提交
  9. 31 10月, 2018 5 次提交
  11. 19 10月, 2018 3 次提交
    • M
      cpus hw target: Use warn_report() & friends to report warnings · 0765691e
      由 Markus Armbruster 提交于 
      Calling error_report() in a function that takes an Error ** argument
is suspicious.  Convert a few that are actually warnings to
warn_report().

While there, split a warning consisting of multiple sentences to
conform to conventions spelled out in warn_report()'s contract.

Cc: Alex Bennée <alex.bennee@linaro.org>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Fam Zheng <famz@redhat.com>
Cc: Wei Huang <wei@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Message-Id: <20181017082702.5581-5-armbru@redhat.com>
      0765691e
    • R
      hyperv: only add SynIC in compatible configurations · 9b4cf107
      由 Roman Kagan 提交于 
      Certain configurations do not allow SynIC to be used in QEMU.  In
particular,

- when hyperv_vpindex is off, SINT routes can't be used as they refer to
  the destination vCPU by vp_index

- older KVM (which doesn't expose KVM_CAP_HYPERV_SYNIC2) zeroes out
  SynIC message and event pages on every msr load, breaking migration

OTOH in-KVM users of SynIC -- SynIC timers -- do work in those
configurations, and we shouldn't stop the guest from using them.

To cover both scenarios, introduce an X86CPU property that makes CPU
init code to skip creation of the SynIC object (and thus disables any
SynIC use in QEMU) but keeps the KVM part of the SynIC working.
The property is clear by default but is set via compat logic for older
machine types.

As a result, when hv_synic and a modern machine type are specified, QEMU
will refuse to run unless vp_index is on and the kernel is recent
enough.  OTOH with an older machine type QEMU will run fine with
hv_synic=on against an older kernel and/or without vp_index enabled but
will disallow the in-QEMU uses of SynIC (in e.g. VMBus).
Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com>
Message-Id: <20180921082217.29481-4-rkagan@virtuozzo.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9b4cf107
    • V
      i386/kvm: add support for Hyper-V IPI send · 6b7a9830
      由 Vitaly Kuznetsov 提交于 
      Hyper-V PV IPI support is merged to KVM, enable the feature in Qemu. When
enabled, this allows Windows guests to send IPIs to other vCPUs with a
single hypercall even when there are >64 vCPUs in the request.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NRoman Kagan <rkagan@virtuozzo.com>
Message-Id: <20181009130853.6412-3-vkuznets@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6b7a9830
  13. 03 10月, 2018 1 次提交
    • P
      target/i386: unify masking of interrupts · 92d5f1a4
      由 Paolo Bonzini 提交于 
      Interrupt handling depends on various flags in env->hflags or env->hflags2,
and the exact detail were not exactly replicated between x86_cpu_has_work
and x86_cpu_exec_interrupt.  Create a new function that extracts the
highest-priority non-masked interrupt, and use it in both functions.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      92d5f1a4
  15. 24 8月, 2018 1 次提交
    • E
      i386: Fix arch_query_cpu_model_expansion() leak · e38bf612
      由 Eduardo Habkost 提交于 
      Reported by Coverity:

Error: RESOURCE_LEAK (CWE-772): [#def439]
qemu-2.12.0/target/i386/cpu.c:3179: alloc_fn: Storage is returned from allocation function "qdict_new".
qemu-2.12.0/qobject/qdict.c:34:5: alloc_fn: Storage is returned from allocation function "g_malloc0".
qemu-2.12.0/qobject/qdict.c:34:5: var_assign: Assigning: "qdict" = "g_malloc0(4120UL)".
qemu-2.12.0/qobject/qdict.c:37:5: return_alloc: Returning allocated memory "qdict".
qemu-2.12.0/target/i386/cpu.c:3179: var_assign: Assigning: "props" = storage returned from "qdict_new()".
qemu-2.12.0/target/i386/cpu.c:3217: leaked_storage: Variable "props" going out of scope leaks the storage it points to.

This was introduced by commit b8097deb ("i386: Improve
query-cpu-model-expansion full mode").

The leak is only theoretical: if ret->model->props is set to
props, the qapi_free_CpuModelExpansionInfo() call will free props
too in case of errors.  The only way for this to not happen is if
we enter the default branch of the switch statement, which would
never happen because all CpuModelExpansionType values are being
handled.

It's still worth to change this to make the allocation logic
easier to follow and make the Coverity error go away.  To make
everything simpler, initialize ret->model and ret->model->props
earlier in the function.

While at it, remove redundant check for !prop because prop is
always initialized at the beginning of the function.

Fixes: b8097debSigned-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180816183509.8231-1-ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e38bf612
  17. 17 8月, 2018 6 次提交
  19. 30 7月, 2018 1 次提交
  21. 23 7月, 2018 1 次提交
  23. 07 7月, 2018 1 次提交
    • G
      i386: fix '-cpu ?' output for host cpu type · 02693cc4
      由 Greg Kurz 提交于 
      Since commit d6dcc558, '-cpu ?' shows the description of the
X86_CPU_TYPE_NAME("max") for the host CPU model:

Enables all features supported by the accelerator in the current host

instead of the expected:

KVM processor with all supported host features

or

HVF processor with all supported host features

This is caused by the early use of kvm_enabled() and hvf_enabled() in
a class_init function. Since the accelerator isn't configured yet, both
helpers return false unconditionally.

A QEMU binary will only be compiled with one of these accelerators, not
both. The appropriate description can thus be decided at build time.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <153055056654.212317.4697363278304826913.stgit@bahia.lan>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      02693cc4
  25. 02 7月, 2018 3 次提交
  27. 29 6月, 2018 1 次提交
  29. 23 6月, 2018 10 次提交