Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 09 8月, 2015 1 次提交
    • L
      conf: more useful error message when pci function is out of range · f8fe8f03
      由 Laine Stump 提交于 
      If a pci address had a function number out of range, the error message
would be:

  Insufficient specification for PCI address

which is logged by virDevicePCIAddressParseXML() after
virDevicePCIAddressIsValid returns a failure.

This patch enhances virDevicePCIAddressIsValid() to optionally report
the error itself (since it is the place that decides which part of the
address is "invalid"), and uses that feature when calling from
virDevicePCIAddressParseXML(), so that the error will be more useful,
e.g.:

  Invalid PCI address function=0x8, must be <= 7

Previously, virDevicePCIAddressIsValid didn't check for the
theoretical limits of domain or bus, only for slot or function. While
adding log messages, we also correct that ommission. (The RNG for PCI
addresses already enforces this limit, which by the way means that we
can't add any negative tests for this - as far as I know our
domainschematest has no provisions for passing XML that is supposed to
fail).

Note that virDevicePCIAddressIsValid() can only check against the
absolute maximum attribute values for *any* possible PCI controller,
not for the actual maximums of the specific controller that this
device is attaching to; fortunately there is later more specific
validation for guest-side PCI addresses when building the set of
assigned PCI addresses. For host-side PCI addresses (e.g. for
<hostdev> and for network device pools), we rely on the error that
will be logged when it is found that the device doesn't actually
exist.

This resolves:

  https://bugzilla.redhat.com/show_bug.cgi?id=1004596
      f8fe8f03
  3. 07 8月, 2015 3 次提交
  5. 06 8月, 2015 7 次提交
  7. 05 8月, 2015 7 次提交
  9. 04 8月, 2015 14 次提交
  11. 03 8月, 2015 8 次提交
    • A
      nodeinfo: Fix build failure when KVM headers are not available · 88c4c32a
      由 Andrea Bolognani 提交于 
      Compiler error:

  ../../src/nodeinfo.c: In function 'nodeGetThreadsPerSubcore':
  ../../src/nodeinfo.c:2393: error: label 'out' defined but not used [-Wunused-label]
  ../../src/nodeinfo.c:2352: error: unused parameter 'arch' [-Wunused-parameter]
      88c4c32a
    • M
      qemu: Remove double unlock for domains · c43c661f
      由 Martin Kletzander 提交于 
      The virDomainObjListRemove() function unlocks a domain that it's given
due to legacy code.  And because of that code, which should be
refactored, that last virObjectUnlock() cannot be just removed.  So
instead, lock it right back for qemu for now.  All calls to
qemuDomainRemoveInactive() are followed by code that unlocks the domain
again, plus the domain should be locked during qemuDomainObjEndJob(), so
the right place to lock it is right after virDomainObjListRemove().

The only place where this would cause a problem is the autodestroy
callback, so we need to get another reference there and uref+unlock it
afterwards.  Luckily, returning NULL from that function doesn't mean an
error, and only means that it doesn't need to be unlocked anymore.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      c43c661f
    • A
      tests: Add subcores3 nodeinfo test · b7102e90
      由 Andrea Bolognani 提交于 
      This makes sure the subcore-unaware CPU counting logic is used
whenever the configuration is invalid.
      b7102e90
    • A
      tests: Add subcores2 nodeinfo test · 28616e8e
      由 Andrea Bolognani 提交于 
      This makes sure CPUs are counted correctly when some of the cores are
completely offline.
      28616e8e
    • A
      tests: Add subcores1 nodeinfo test · ad43a09c
      由 Andrea Bolognani 提交于 
      This makes sure CPUs are counted correctly when using the default
configuration, that is, all primary threads are online and all
secondary threads are offline.
      ad43a09c
    • S
      tests: Prepare for subcore tests · 3020f550
      由 Shivaprasad G Bhat 提交于 
      The nodeGetThreadsPerSubcore() function is mocked to return 8 for
ppc64 tests, which corresponds to the default subcore mode.

Update the expected output for the deconfigured-cpus nodeinfo
test to account for this change.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      3020f550
    • S
      nodeinfo: Fix output on PPC64 KVM hosts · 014208c4
      由 Shivaprasad G Bhat 提交于 
      The nodeinfo is reporting incorrect number of cpus and incorrect host
topology on PPC64 KVM hosts. The KVM hypervisor on PPC64 needs only
the primary thread in a core to be online, and the secondaries offlined.
While scheduling a guest in, the kvm scheduler wakes up the secondaries to
run in guest context.

The host scheduling of the guests happen at the core level(as only primary
thread is online). The kvm scheduler exploits as many threads of the core
as needed by guest. Further, starting POWER8, the processor allows splitting
a physical core into multiple subcores with 2 or 4 threads each. Again, only
the primary thread in a subcore is online in the host. The KVM-PPC
scheduler allows guests to exploit all the offline threads in the subcore,
by bringing them online when needed.
(Kernel patches on split-core http://www.spinics.net/lists/kvm-ppc/msg09121.html)

Recently with dynamic micro-threading changes in ppc-kvm, makes sure
to utilize all the offline cpus across guests, and across guests with
different cpu topologies.
(https://www.mail-archive.com/kvm@vger.kernel.org/msg115978.html)

Since the offline cpus are brought online in the guest context, it is safe
to count them as online. Nodeinfo today discounts these offline cpus from
cpu count/topology calclulation, and the nodeinfo output is not of any help
and the host appears overcommited when it is actually not.

The patch carefully counts those offline threads whose primary threads are
online. The host topology displayed by the nodeinfo is also fixed when the
host is in valid kvm state.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      014208c4
    • O
      rpc: Fix slow volume download (virsh vol-download) · d9c9e138
      由 Ossi Herrala 提交于 
      Use I/O vector (iovec) instead of one huge memory buffer as suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1026137#c7. This avoids
doing memmove() to big buffers and performance doesn't degrade if
source (virNetClientStreamQueuePacket()) is faster than sink
(virNetClientStreamRecvPacket()).

Resolves: http://bugzilla.redhat.com/1026137Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      d9c9e138