Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 15 11月, 2016 4 次提交
    • L
      qemu: set/use proper pciConnectFlags during hotplug · abb7a4bd
      由 Laine Stump 提交于 
      Before now, all the qemu hotplug functions assumed that all devices to
be hotplugged were legacy PCI endpoint devices
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
and hotplug didn't work properly on machinetypes using PCIe anyway
(hotplugging onto a legacy PCI slot doesn't work, and until commit
b87703cf any attempt to manually specify a PCIe address for a
hotplugged device would be erroneously rejected).

This patch makes all qemu hotplug operations honor the pciConnectFlags
set by the single all-knowing function
qemuDomainDeviceCalculatePCIConnectFlags(). This is done in 3 steps,
but in a single commit since we would have to touch the other points
at each step anyway:

1) add a flags argument to the hypervisor-agnostic
virDomainPCIAddressEnsureAddr() (previously it hardcoded
..._PCI_DEVICE)

2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which
gets the correct pciConnectFlags for the device from
qemuDomainDeviceConnectFlags(), then calls
virDomainPCIAddressEnsureAddr().

3) in qemu_hotplug.c replace all calls to
virDomainPCIAddressEnsureAddr() with calls to
qemuDomainEnsurePCIAddress()

So in effect, we're putting a "shim" on top of all calls to
virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.
      abb7a4bd
    • L
      qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses · 7f784f57
      由 Laine Stump 提交于 
      Set pciConnectFlags in each device's DeviceInfo and then use those
flags later when validating existing addresses in
qemuDomainCollectPCIAddress() and when assigning new addresses with
qemuDomainPCIAddressReserveNextAddr() (rather than scattering the
logic about which devices need which type of slot all over the place).

Note that the exact flags set by
qemuDomainDeviceCalculatePCIConnectFlags() are different from the
flags previously set manually in qemuDomainCollectPCIAddress(), but
this doesn't matter because all validation of addresses in that case
ignores the setting of the HOTPLUGGABLE flag, and treats PCIE_DEVICE
and PCI_DEVICE the same (this lax checking was done on purpose,
because there are some things that we want to allow the user to
specify manually, e.g. assigning a PCIe device to a PCI slot, that we
*don't* ever want libvirt to do automatically. The flag settings that
we *really* want to match are 1) the old flag settings in
qemuDomainAssignDevicePCISlots() (which is HOTPLUGGABLE | PCI_DEVICE
for everything except PCI controllers) and 2) the new flag settings
done by qemuDomainDeviceCalculatePCIConnectFlags() (which are
currently exactly that - HOTPLUGGABLE | PCI_DEVICE for everything
except PCI controllers).
      7f784f57
    • L
      qemu: new functions to calculate/set device pciConnectFlags · bd776c2b
      由 Laine Stump 提交于 
      The lowest level function of this trio
(qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single
authority for the virDomainPCIConnectFlags to use for any given device
using a particular arch/machinetype/qemu-binary.

qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a
single device (unless it has no virDomainDeviceInfo, in which case
it's a NOP).

qemuDomainFillAllPCIConnectFlags() sets info->pciConnectFlags in all
devices that have a virDomainDeviceInfo

The latter two functions aren't called anywhere yet. This commit is
just making them available. Later patches will replace all the current
hodge-podge of flag settings with calls to this single authority.
      bd776c2b
    • L
      qemu: new functions qemuDomainMachineHasPCI[e]Root() · 50adb8a6
      由 Laine Stump 提交于 
      These functions provide a simple one line method of learning if the
current domain has a pci-root or pcie-root bus.
      50adb8a6
  3. 14 11月, 2016 1 次提交
  5. 12 11月, 2016 1 次提交
  7. 11 11月, 2016 4 次提交
    • P
      qemu: Generate memory device aliases according to slot number · b7798a07
      由 Peter Krempa 提交于 
      The memory device alias needs to be treated as machine ABI as qemu is
using it in the migration stream for section labels. To simplify this
generate the alias from the slot number unless an existing broken
configuration is detected.

With this patch the aliases are predictable and even certain
configurations which would not be migratable previously are fixed.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1359135
      b7798a07
    • P
      qemu: Assign slots to memory devices prior to usage · ce1ee02a
      由 Peter Krempa 提交于 
      As with other devices assign the slot number right away when adding the
device. This will make the slot numbers static as we do with other
addressing elements and it will ultimately simplify allocation of the
alias in a static way which does not break with qemu.
      ce1ee02a
    • P
      qemu: process: detect if dimm aliases are broken on reconnect · 93d9ff3d
      由 Peter Krempa 提交于 
      Detect on reconnect to a running qemu VM whether the alias of a
hotpluggable memory device (dimm) does not match the dimm slot number
where it's connected to. This is necessary as qemu is actually
considering the alias as machine ABI used to connect the backend object
to the dimm device.

This will require us to keep them consistent so that we can reliably
restore them on migration. In some situations it was currently possible
to create a mismatched configuration and qemu would refuse to restore
the migration stream.

To avoid breaking existing VMs we'll need to keep the old algorithm
though.
      93d9ff3d
    • P
      conf: Allow specifying only the slot number for hotpluggable memory · 810e9a80
      由 Peter Krempa 提交于 
      Simplify handling of the 'dimm' address element by allowing to specify
the slot number only. This will allow libvirt to allocate slot numbers
before starting qemu.
      810e9a80
  9. 10 11月, 2016 6 次提交
  11. 09 11月, 2016 5 次提交
  13. 08 11月, 2016 1 次提交
  15. 04 11月, 2016 3 次提交
  17. 03 11月, 2016 2 次提交
  19. 02 11月, 2016 5 次提交
  21. 28 10月, 2016 3 次提交
    • C
      qemu_driver: unlink new domain cfg file when rollback · 3b782ce5
      由 Chen Hanxiao 提交于 
      If we failed to unlink old dom cfg file, we goto rollback.
But inside rollback, we fogot to unlink the new dom cfg file.
This patch fixes this issue.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      3b782ce5
    • M
      qemu: Minimalize global driver accesses · 65462b29
      由 Michal Privoznik 提交于 
      Whilst working on another issue, I've noticed that in some
functions we have a local @driver variable among with access to
global @qemu_driver variable. This makes no sense.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      65462b29
    • N
      qemu: Fix crash during qemuStateCleanup · 97338eaa
      由 Nikolay Shirokovskiy 提交于 
      Rather than waiting until we've free'd up all the resources, cause the
'workerPool' thread pool to flush as soon as possible during stateCleanup.
Otherwise, it's possible something waiting to run will SEGV such as is the
case during race conditions of simultaneous exiting libvirtd and qemu process.
Resolves the following crash:

[1] crash backtrace: (bt is shortened a bit):

0  0x00007ffff7282f2b in virClassIsDerivedFrom
   (klass=0xdeadbeef, parent=0x55555581d650) at util/virobject.c:169
1  0x00007ffff72835fd in virObjectIsClass
   (anyobj=0x7fffd024f580, klass=0x55555581d650) at util/virobject.c:365
2  0x00007ffff7283498 in virObjectLock
   (anyobj=0x7fffd024f580) at util/virobject.c:317
3  0x00007ffff722f0a3 in virCloseCallbacksUnset
   (closeCallbacks=0x7fffd024f580, vm=0x7fffd0194db0,
    cb=0x7fffdf1af765 <qemuProcessAutoDestroy>)
   at util/virclosecallbacks.c:164
4  0x00007fffdf1afa7b in qemuProcessAutoDestroyRemove
   (driver=0x7fffd00f3a60, vm=0x7fffd0194db0) at qemu/qemu_process.c:6365
5  0x00007fffdf1adff1 in qemuProcessStop
   (driver=0x7fffd00f3a60, vm=0x7fffd0194db0, reason=VIR_DOMAIN_SHUTOFF_CRASHED,
    asyncJob=QEMU_ASYNC_JOB_NONE, flags=0)
   at qemu/qemu_process.c:5877
6  0x00007fffdf1f711c in processMonitorEOFEvent
   (driver=0x7fffd00f3a60, vm=0x7fffd0194db0) at qemu/qemu_driver.c:4545
7  0x00007fffdf1f7313 in qemuProcessEventHandler
   (data=0x555555832710, opaque=0x7fffd00f3a60) at qemu/qemu_driver.c:4589
8  0x00007ffff72a84c4 in virThreadPoolWorker
   (opaque=0x555555805da0) at util/virthreadpool.c:167

Thread 1 (Thread 0x7ffff7fb1880 (LWP 494472)):
1  0x00007ffff72a7898 in virCondWait
   (c=0x7fffd01c21f8, m=0x7fffd01c21a0) at util/virthread.c:154
2  0x00007ffff72a8a22 in virThreadPoolFree
   (pool=0x7fffd01c2160) at util/virthreadpool.c:290
3  0x00007fffdf1edd44 in qemuStateCleanup ()
   at qemu/qemu_driver.c:1102
4  0x00007ffff736570a in virStateCleanup ()
   at libvirt.c:807
5  0x000055555556f991 in main (argc=1, argv=0x7fffffffe458) at libvirtd.c:1660
      97338eaa
  23. 27 10月, 2016 5 次提交