1. 27 4月, 2020 2 次提交
  2. 24 4月, 2020 1 次提交
  3. 13 4月, 2020 1 次提交
    • L
      qemu: hook up pcie-root-port hotplug='off' option · 2d3cf603
      Laine Stump 提交于
      If a pcie-root-port or pcie-downstream-port has hotplug='off' in its
      <target> subelement, and if the qemu binary supports the hotplug=false
      option, then it will be added to the commandline for the pcie
      controller. This controller will then not allow any hotplug/unplug of
      devices while the guest is running (and the hotplug capability won't
      be advertised to the guest OS, so the guest OS also won't present
      unplugging of PCI devices as an option).
      
        <controller type='pci' model='pcie-root-port'>
          <target hotplug='off'/>
        </controller>
      
      For any PCI controllers other than pcie-downstream-port and
      pcie-root-port, of for qemu binaries that don't support the hotplug
      commandline option, an error will be logged during validation.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      2d3cf603
  4. 08 4月, 2020 1 次提交
  5. 06 4月, 2020 1 次提交
  6. 01 4月, 2020 1 次提交
  7. 24 3月, 2020 1 次提交
  8. 16 3月, 2020 1 次提交
  9. 04 3月, 2020 2 次提交
  10. 14 2月, 2020 2 次提交
  11. 07 2月, 2020 1 次提交
  12. 06 2月, 2020 1 次提交
  13. 30 1月, 2020 1 次提交
    • L
      qemu: support interface <teaming> functionality · eb9f6cc4
      Laine Stump 提交于
      The QEMU driver uses the <teaming type='persistent|transient'
      persistent='blah'/> element to setup a "failover" pair of devices -
      the persistent device must be a virtio emulated NIC, with the only
      extra configuration being the addition of ",failover=on" to the device
      commandline, and the transient device must be a hostdev NIC
      (<interface type='hostdev'> or <interface type='network'> with a
      network that is a pool of SRIOV VFs) where the extra configuration is
      the addition of ",failover_pair_id=$aliasOfVirtio" to the device
      commandline. These new options are supported in QEMU 4.2.0 and later.
      
      Extra qemu-specific validation is added to ensure that the device
      type/model is appropriate and that the qemu binary supports these
      commandline options.
      
      The result of this will be:
      
      1) The virtio device presented to the guest will have an extra bit set
      in its PCI capabilities indicating that it can be used as a failover
      backup device. The virtio guest driver will need to be equipped to do
      something with this information - this is included in the Linux
      virtio-net driver in kernel 4.18 and above (and also backported to
      some older distro kernels). Unfortunately there is no way for libvirt
      to learn whether or not the guest driver supports failover - if it
      doesn't then the extra PCI capability will be ignored and the guest OS
      will just see two independent devices. (NB: the current virtio guest
      driver also requires that the MAC addresses of the two NICs match in
      order to pair them into a bond).
      
      2) When a migration is requested, QEMu will automatically unplug the
      transient/hostdev NIC from the guest on the source host before
      starting migration, and automatically re-plug a similar device after
      restarting the guest CPUs on the destination host. While the transient
      NIC is unplugged, all network traffic will go through the
      persistent/virtio device, but when the hostdev NIC is plugged in, it
      will get all the traffic. This means that in normal circumstances the
      guest gets the performance advantage of vfio-assigned "real hardware"
      networking, but it can still be migrated with the only downside being
      a performance penalty (due to using an emulated NIC) during the
      migration.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      eb9f6cc4
  14. 27 1月, 2020 2 次提交
  15. 25 1月, 2020 1 次提交
  16. 16 1月, 2020 1 次提交
  17. 13 1月, 2020 2 次提交
  18. 03 1月, 2020 1 次提交
  19. 19 12月, 2019 1 次提交
  20. 17 12月, 2019 7 次提交
  21. 13 12月, 2019 1 次提交
  22. 09 12月, 2019 4 次提交
  23. 28 11月, 2019 1 次提交
  24. 25 11月, 2019 1 次提交
  25. 21 11月, 2019 2 次提交