Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 10 11月, 2015 3 次提交
  3. 07 10月, 2015 2 次提交
    • A
      qemu: Fix indentation issue · 7cdf944b
      由 Andrea Bolognani 提交于 
      Two #define lines introduced by b527aa09 did not respect the
indentation rules, thus breaking syntax-check.
      7cdf944b
    • A
      qemu: Remove explicit values from virQEMUCapsFlags · b527aa09
      由 Andrea Bolognani 提交于 
      This gets rid of the partially enforced alignment and makes it less
likely for a bogus value to be introduced in the enumeration.
Capabilities are divided in five-element groups for better readability.

Use #define for QEMU_CAPS_NET_NAME and QEMU_CAPS_HOST_NET_ADD, both
of which are aliases for QEMU_CAPS_0_10.
      b527aa09
  5. 02 10月, 2015 1 次提交
  7. 10 9月, 2015 3 次提交
  9. 10 8月, 2015 3 次提交
    • L
      qemu: add capabilities bit for device xio3130-downstream · ad1748a1
      由 Laine Stump 提交于 
      The downstream ports of an x3130-upstream switch can each have one of
these plugged into them (and that is the only place they can be
connected). Each xio3130-downstream provides a single PCIe port that
can have PCI or PCIe devices hotplugged into it. Apparently an entire
set of x3130-upstream + several xio3130-downstreams can be hotplugged
as a unit, but it's not clear to me yet how that would be done, since
qemu only allows attaching a single device at a time.

This device will be used to implement the
"pcie-switch-downstream-port" model of pci controller.
      ad1748a1
    • L
      qemu: add capabilities bit for device x3130-upstream · 4cde7588
      由 Laine Stump 提交于 
      This is the upstream part of a PCIe switch. It connects to a PCIe port
(but not PCI) on the upstream side, and can have up to 31
xio3130-downstream controllers (but no other types of devices)
connected to its downstream side.

This device will be used to implement the "pcie-switch-upstream-port"
model of pci controller.
      4cde7588
    • 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
  11. 06 8月, 2015 1 次提交
  13. 24 7月, 2015 1 次提交
  15. 20 7月, 2015 1 次提交
  17. 10 7月, 2015 1 次提交
  19. 30 6月, 2015 1 次提交
  21. 22 6月, 2015 1 次提交
  23. 15 6月, 2015 1 次提交
  25. 11 6月, 2015 1 次提交
  27. 09 6月, 2015 1 次提交
  29. 21 5月, 2015 1 次提交
  31. 18 5月, 2015 1 次提交
  33. 04 5月, 2015 2 次提交
  35. 21 2月, 2015 1 次提交
  37. 20 2月, 2015 2 次提交
  39. 06 2月, 2015 1 次提交
  41. 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
  43. 25 11月, 2014 1 次提交
  45. 10 11月, 2014 1 次提交
  47. 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
  49. 04 10月, 2014 1 次提交
  51. 23 9月, 2014 1 次提交
  53. 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
  55. 17 9月, 2014 2 次提交
  57. 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
  59. 25 8月, 2014 1 次提交