Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 11 1月, 2016 2 次提交
    • C
      qemu: command: wire up usage of q35/ich9 disable s3/s4 · fde937bd
      由 Cole Robinson 提交于 
      If the q35 specific disable s3/s4 setting isn't supported, fallback to
specifying the PIIX setting, which is the previous behavior. It doesn't
have any effect, but qemu will just warn about it rather than error:

  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s3=1 not used
  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s4=1 not used

Since it doesn't error, I don't think we should either, since there
may be configs in the wild that already have q35 + disable_s3/4 (via
virt-manager)
      fde937bd
    • C
      qemu: caps: Rename CAPS_DISABLE_S[34] to CAPS_PIIX_DISABLE_S[34] · 5900356e
      由 Cole Robinson 提交于 
      These settings are specific to PIIX, so clarify it
      5900356e
  3. 10 1月, 2016 1 次提交
    • M
      Fix USB model defaults for ppc64 · 8156493d
      由 Martin Kletzander 提交于 
      The condition was checking for UHCI (and OHCI for ppc64) availability so
that it can specify the proper device instead of legacy usb.  However,
for ppc64, we don't need to check both OHCI and UHCI, but only OHCI as
that is the legacy default.  The condition is so big that it was just a
matter of time when someone will make a mistake there, so let's use more
lines so that it is visible what the condition checks for.

This fixes usage of -device instead of -usb for ppc64 that supports
pci-usb-ohci and does not support piix3-usb-uhci.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1297020Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      8156493d
  5. 09 1月, 2016 1 次提交
  7. 24 12月, 2015 1 次提交
  9. 04 12月, 2015 1 次提交
  11. 30 11月, 2015 2 次提交
  13. 27 11月, 2015 2 次提交
  15. 25 11月, 2015 2 次提交
    • D
      Allow multiple panic devices · 59fc0d06
      由 Dmitry Andreev 提交于 
      'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.
      59fc0d06
    • D
      qemu: add support for hv_crash feature as a panic device · ca6ddffe
      由 Dmitry Andreev 提交于 
      Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash
      ca6ddffe
  17. 19 11月, 2015 2 次提交
  19. 18 11月, 2015 1 次提交
  21. 12 11月, 2015 1 次提交
  23. 10 11月, 2015 11 次提交
  25. 16 10月, 2015 1 次提交
    • J
      qemu: Fix qemu startup check for QEMU_CAPS_OBJECT_IOTHREAD · cc2d49f9
      由 John Ferlan 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1249981

When qemuDomainPinIOThread was added in commit id 'fb562614', a check
for the IOThread capability was not needed since a check for iothreadpids
covered the condition where the support for IOThreads was not present.
The iothreadpids array was only created if qemuProcessDetectIOThreadPIDs
was able to query the monitor for IOThreads. It would only do that if
the QEMU_CAPS_OBJECT_IOTHREAD capability was set.

However, when iothreadids were added in commit id '8d4614a5' and the
check for iothreadpids was replaced by a search through the iothreadids[]
array for the matching iothread_id that left open the possibility that
an iothreadids[] array was defined, but the entries essentially pointed
to elements with only the 'iothread_id' defined leaving the 'thread_id'
value of 0 and eventually the cpumap entry of NULL.

This was because, the original IOThreads commit id '72edaae7' only
checked if IOThreads were defined and if the emulator had the IOThreads
capability, then IOThread objects were added at startup. The "capability
failure" check was only done when a disk was assigned to an IOThread in
qemuCheckIOThreads. This was because the initial implementation had no way
to dynamically add IOThreads, but it was possible to dynamically add a
disk to the domain. So the decision was if the domain supported it, then
add the IOThread objects. Then if a disk with an IOThread defined was
added, it could check the capability and fail to add if not there. This
just meant the 'iothreads' value was essentially ignored.

Eventually commit id 'a27ed6e7' allowed for the dynamic addition and
deletion of IOThread objects. So it was no longer necessary to generate
IOThread objects to dynamically attach a disk to. However, the startup
and disk check code was not modified to reflect this.

This patch will move the capability failure check to when IOThread
objects are being added to the command line. Thus a domain that has
IOThreads defined will not be started if the emulator doesn't support
the capability. This means when qemuCheckIOThreads is called to add
a disk, it's no longer necessary to check the capability. Instead the
code can use the IOThreadFind call to indicate that the IOThread
doesn't exist.

Finally because it could be possible to have a domain running with the
iothreadids[] defined prior to this change if libvirtd is restarted each
having mostly empty elements, qemuProcessDetectIOThreadPIDs will check
if there are niothreadids when the QEMU_CAPS_OBJECT_IOTHREAD capability
check fails and remove the elements and array if it exists.

With these changes in place, it turns out the cputune-numatune test
was failing because the right bit wasn't set in the test. So used the
opportunity to fix that and create a test that would expect to fail
with some sort of iothreads defined and used, but not having the
correct capability.
      cc2d49f9
  27. 06 10月, 2015 1 次提交
    • C
      tests: qemu: Add aarch64 virtio pci tests · 1a83a068
      由 Cole Robinson 提交于 
      - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default
  to virtio-mmio even if qemu is new enough to support PCI
- qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
      1a83a068
  29. 02 10月, 2015 1 次提交
  31. 22 9月, 2015 3 次提交
  33. 02 9月, 2015 1 次提交
    • J
      qemu: add udp interface support · 5c668a78
      由 Jonathan Toppins 提交于 
      Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.

The interface type required the addition of a "localaddr" (local
address), this then maps into the following xml and qemu call.

<interface type='udp'>
  <mac address='52:54:00:5c:67:56'/>
  <source address='127.0.0.1' port='11112'>
    <local address='127.0.0.1' port='22222'/>
  </source>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>

QEMU call:
	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222

Notice the xml "local" entry becomes the "localaddr" for the qemu call.

reference:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
      5c668a78
  35. 10 8月, 2015 4 次提交
  37. 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
  39. 04 8月, 2015 1 次提交