Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 10 8月, 2015 1 次提交
    • L
      qemu: add capabilities bit for device ioh3420 · 408b100a
      由 Laine Stump 提交于 
      This is a PCIE "root port". It connects only to a port of the
integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and
provides a single PCIe port that can have PCI or PCIe devices
hotplugged into it.

This device will be used to implement the "pcie-root-port" model of
pci controller.
      408b100a
  3. 06 8月, 2015 1 次提交
  5. 24 7月, 2015 1 次提交
  7. 20 7月, 2015 1 次提交
  9. 10 7月, 2015 1 次提交
  11. 30 6月, 2015 1 次提交
  13. 22 6月, 2015 1 次提交
  15. 15 6月, 2015 1 次提交
  17. 11 6月, 2015 1 次提交
  19. 09 6月, 2015 1 次提交
  21. 21 5月, 2015 1 次提交
  23. 18 5月, 2015 1 次提交
  25. 04 5月, 2015 2 次提交
  27. 21 2月, 2015 1 次提交
  29. 20 2月, 2015 2 次提交
  31. 06 2月, 2015 1 次提交
  33. 05 12月, 2014 1 次提交
    • D
      Report original error when QMP probing fails with new QEMU · 25bf888a
      由 Daniel P. Berrange 提交于 
      If probing capabilities via QMP fails, we now have a check
that prevents us falling back to -help parsing. Unfortunately
the error message

  "Failed to probe capabilities for /usr/bin/qemu-kvm:
   unsupported configuration: QEMU 2.1.2 is too new for help parsing"

is proving rather unhelpful to the user. We need to be telling
them why QMP failed (the root cause), rather than they can't
use -help (the side effect).

To do this we should capture stderr during QMP probing, and
if -help parsing then sees a new QEMU version, we know that
QMP should have worked, and so we can show the messages from
stderr. The message thus becomes

  "Failed to probe capabilities for /usr/bin/qemu-kvm:
   internal error: QEMU / QMP failed: Could not access
   KVM kernel module: No such file or directory
   failed to initialize KVM: No such file or directory"
      25bf888a
  35. 25 11月, 2014 1 次提交
  37. 10 11月, 2014 1 次提交
  39. 30 10月, 2014 1 次提交
    • E
      qemu: better error message when block job can't succeed · 00331bfb
      由 Eric Blake 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1140981 reports that
the qemu-kvm shipped as part of RHEL 7.0 intentionally[1] cripples
block jobs by removing the 'block-stream' QMP command, while still
leaving 'block-job-cancel' as an unusable no-op.  Meanwhile, we
already had existing code that checked whether block jobs were
completely missing (such as qemu 0.15), old style (cancel is
synchronous, and all commands spelled with '_'), or new style
(cancel is asynchronous, and all commands spelled with '-'), and
used that three-way probe to give decent error messages.  At the
time that code was added, all existing qemu versions fell in one
of three buckets, and the code was using the presence of
'block-job-cancel' as the witness of which of the three buckets.
But now that RHEL qemu has shipped with intentionally crippled
'block-stream', we have a fourth bucket, which results in ugly
error messages when trying 'virsh blockpull':

 error: Requested operation is not valid: Command 'block-stream' is not found

In reality, the fourth bucket should be treated the same as the
first bucket (no block job support); we can do that by realizing
that no existing build of qemu has working block-stream while
lacking block-job-cancel, so it is easiest to change our witness
to the command that starts a job rather than ends one.  We still
act correctly regarding command spelling and whether cancel is
asynchronous.  And on crippled RHEL builds, we now get the desired:

 error: unsupported configuration: block jobs not supported with this qemu binary

[1] The intentional cripple is limited to qemu-kvm of RHEL; when using
qemu-kvm-rhev of RHEV, block job functionality is supported.  Don't ask
me to explain the "why" behind it all - I'm just dealing with fallout
from someone else's decision.

* src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC): Tweak comment.
* src/qemu/qemu_capabilities.c (virQEMUCapsCommands): Look for stream
rather than cancel when determining the flavor of block jobs supported.
Signed-off-by: NEric Blake <eblake@redhat.com>
      00331bfb
  41. 04 10月, 2014 1 次提交
  43. 23 9月, 2014 1 次提交
  45. 18 9月, 2014 1 次提交
    • R
      Fix build in qemu_capabilities · 3b3947ea
      由 Roman Bogorodskiy 提交于 
      Commit f05b6a91 added virQEMUDriverConfigPtr argument to the
virQEMUCapsFillDomainCaps function and it uses forward declaration
of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang
build to fail:

gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src'
  CC       qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo
In file included from qemu/qemu_capabilities.c:43:
In file included from qemu/qemu_hostdev.h:27:
qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig'
is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^
qemu/qemu_capabilities.h:328:37: note: previous definition is here
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^

Fix that by passing loader and nloader config attributes directly
instead of passing complete config.
      3b3947ea
  47. 17 9月, 2014 2 次提交
  49. 29 8月, 2014 1 次提交
    • J
      qemu: Add support for iothreads · 72edaae7
      由 John Ferlan 提交于 
      Add a new capability to ensure the iothreads feature exists for the qemu
emulator being run - requires the "query-iothreads" QMP command. Using the
domain XML add correspoding command argument in order to generate the
threads. The iothreads will use a name space "iothread#" where, the
future patch to add support for using an iothread to a disk definition to
merely define which of the available threads to use.

Add tests to ensure the xml/argv processing is correct.  Note that no
change was made to qemuargv2xmltest.c as processing the -object element
would require knowing more than just iothreads.
      72edaae7
  51. 25 8月, 2014 1 次提交
  53. 20 8月, 2014 1 次提交
  55. 08 8月, 2014 2 次提交
  57. 29 7月, 2014 1 次提交
  59. 17 7月, 2014 2 次提交
  61. 04 7月, 2014 2 次提交
    • P
      qemu: caps: Add capability for change-backing-file command · b20fb93c
      由 Peter Krempa 提交于 
      This command allows to change the backing file name recorded in the
metadata of a qcow (or other) image. The capability also notifies that
the "block-stream" and "block-commit" commands understand the
"backing-file" attribute.
      b20fb93c
    • E
      blockjob: turn on qemu capability bit for active commit · 40ad7160
      由 Eric Blake 提交于 
      Use the probing functionality added in the last patch to turn on
a capability bit when active commit is present, and gate active
commit on that capability.

For my own reference: the difference between BLOCKJOB_SYNC and
BLOCKJOB_ASYNC is whether qemu generated an event at the
conclusion of blockpull; basically, RHEL 6.2 was the only release
of qemu that has the sync semantics and lacks the event.  RHEL
6.3 added blockcopy, but also picked up on the upstream style
of qemu generating events.  As no one is likely to backport
active commit to RHEL 6.2, it's safe for blockcommit to always
require async blockjob support.

Modifying qemucapabilitiestest is painful; the .replies files would
be so much easier if they had comments correlating which command
generated the given reply.  Maybe I'll fix that up later...

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ACTIVE_COMMIT): New
capability.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Use the new bit
* src/qemu/qemu_capabilities.c (virQEMUCaps): Name the new bit.
(virQEMUCapsProbeQMPCommands): Set it.
* tests/qemucapabilitiesdata/caps_1.3.1-1.replies: Update.
* tests/qemucapabilitiesdata/caps_1.4.2-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.5.3-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.0-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.50-1.replies: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>
      40ad7160
  63. 03 7月, 2014 3 次提交