Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 26 8月, 2019 4 次提交
  3. 23 8月, 2019 6 次提交
  5. 22 8月, 2019 2 次提交
  7. 21 8月, 2019 5 次提交
  9. 20 8月, 2019 2 次提交
  11. 17 8月, 2019 2 次提交
    • M
      virhostdev: Unify virHostdevPreparePCIDevices behaviour for KVM and VFIO cases · 5cd4606e
      由 Michal Privoznik 提交于 
      The virHostdevPreparePCIDevices() function works in several
steps. In the very first one, it checks if devices we want to
detach from the host are not taken already by some other domain.
However, this piece of code returns different results depending
on the stub driver used (which is not wrong per se, but keep on
reading). If the stub driver is KVM then
virHostdevIsPCINodeDeviceUsed() is called which basically checks
if a PCI device from the detach list is not used by any domain
(including the one we are preparing the device for). If that is
the case, an error is reported ("device in use") and -1 is
returned.

However, that is not what happens if the stub driver is VFIO. If
the stub driver is VFIO, then we iterate over all PCI devices
from the same IOMMU group and check if they are taken by some
other domain (because a PCI device, well IOMMU group, can't be
shared between two or more qemu processes). But we fail to check,
if the device we are trying to detach from the host is not
already taken by a domain. That is, calling
virHostdevPreparePCIDevices() over a hostdev device twice
succeeds the first time and fails too late in the second run
(fortunately, virHostdevResetAllPCIDevices() will throw an error,
but this is already too late because the PCI device in question
was moved to the list of inactive PCI devices and now it appears
in both lists).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      5cd4606e
    • M
      virhostdev: Check driver name too in virHostdevIsPCINodeDeviceUsed() · a307143e
      由 Michal Privoznik 提交于 
      It may happen that there are two domains with the same name in
two separate drivers (e.g. qemu and lxc). That is why for PCI
devices we track both names of driver and domain combination
which has taken the device. However, when we check if given PCI
device is in use (or PCI devices from the same IOMMU group) we
compare only domain name. This means that we can mistakenly claim
device as free to use while in fact it isn't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      a307143e
  13. 16 8月, 2019 4 次提交
  15. 15 8月, 2019 2 次提交
  17. 14 8月, 2019 11 次提交
  19. 13 8月, 2019 1 次提交
    • L
      util: allow tap-based guest interfaces to have MAC address prefix 0xFE · a60ee914
      由 Laine Stump 提交于 
      Back in July 2010, commit 6ea90b84 (meant to resolve
https://bugzilla.redhat.com/571991 ) added code to set the MAC address
of any tap device to the associated guest interface's MAC, but with
the first byte replaced with 0xFE. This was done in order to assure
that

1) the tap MAC and guest interface MAC were different (otherwise L2
   forwarding through the tap would not work, and the kernel would
   repeatedly issue a warning stating as much).

2) any bridge device that had one of these taps attached would *not*
   take on the MAC of the tap (leading to network instability as
   guests started and stopped)

A couple years later, https://bugzilla.redhat.com/798467 was filed,
complaining that a user could configure a tap-based guest interface to
have a MAC address that itself had a first byte of 0xFE, silently
(other than the kernel warning messages) resulting in a non-working
configuration. This was fixed by commit 5d571045, which logged an
error and failed the guest start / interface attach if the MAC's first
byte was 0xFE.

Although this restriction only reduces the potential pool of MAC
addresses from 2^46 (last two bits of byte 1 must be set to 10) by
2^32 (still 4 orders of magnitude larger than the entire IPv4 address
space), it also means that management software that autogenerates MAC
addresses must have special code to avoid an 0xFE prefix. Now after 7
years, someone has noticed this restriction and requested that we
remove it.

So instead of failing when 0xFE is found as the first byte, this patch
removes the restriction by just replacing the first byte in the tap
device MAC with 0xFA if the first byte in the guest interface is
0xFE. 0xFA is the next-highest value that still has 10 as the lowest
two bits, and still

2) meets the requirement of "tap MAC must be different from guest
   interface MAC", and

3) is high enough that there should never be an issue of the attached
   bridge device taking on the MAC of the tap.

The result is that *any* MAC can be chosen by management software
(although it would still not work correctly if a multicast MAC (lowest
bit of first byte set to 1) was chosen), but that's a different
issue).
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com
      a60ee914
  21. 10 8月, 2019 1 次提交
    • D
      build: bump min libxml2 to 2.9.1 · e4c05240
      由 Daniel P. Berrangé 提交于 
      The various distros have the following libxml2 vesions:

        CentOS 7: 2.9.1
  Debian Stretch: 2.9.4
   FreeBSD Ports: 2.9.9
Ubuntu 16.04 LTS: 2.9.3

Based on this sampling, we can reasonably bump libxml2 min
version to 2.9.1

The 'query_raw' struct field was added in version 2.6.28,
so can be assumed to exist.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e4c05240