Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 25 1月, 2018 1 次提交
    • S
      cpu: Add support for al57 Intel features · e7cb9c4e
      由 Shaohe Feng 提交于 
      We can start qemu with a "cpu,+la57" to set 57-bit vitrual address
space. So VM can be aware that it need to enable 5-level paging.

Corresponding QEMU commits:
        al57 6c7c3c21f95dd9af8a0691c0dd29b07247984122
      e7cb9c4e
  3. 22 1月, 2018 4 次提交
  5. 21 1月, 2018 1 次提交
    • L
      qemu: assign correct type of PCI address for vhost-scsi when using pcie-root · 18c24bc6
      由 Laine Stump 提交于 
      Commit 10c73bf1 fixed a bug that I had introduced back in commit
70249927 - if a vhost-scsi device had no manually assigned PCI
address, one wouldn't be assigned automatically. There was a slight
problem with the logic of the fix though - in the case of domains with
pcie-root (e.g. those with a q35 machinetype),
qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine
if the host-side PCI device is Express or legacy by examining sysfs
based on the host-side PCI address stored in
hostdev->source.subsys.u.pci.addr, but that part of the union is only
valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying
to read sysfs for some probably-non-existent device, which fails, and
the function virPCIDeviceIsPCIExpress() returns failure (-1).

By coincidence, the return value is being examined as a boolean, and
since -1 is true, we still end up assigning the vhost-scsi device to
an Express slot, but that is just by chance (and could fail in the
case that the gibberish in the "hostside PCI address" was the address
of a real device that happened to be legacy PCI).

Since (according to Paolo Bonzini) vhost-scsi devices appear just like
virtio-scsi devices in the guest, they should follow the same rules as
virtio devices when deciding whether they should be placed in an
Express or a legacy slot. That's accomplished in this patch by
returning early with virtioFlags, rather than erroneously using
hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe
to assure it doesn't get broken in the future.
      18c24bc6
  7. 20 1月, 2018 1 次提交
    • J
      nodedev: Fix failing to parse PCI address for non-PCI network devices · 71d56a39
      由 Jim Fehlig 提交于 
      Commit 8708ca01 added virNetDevSwitchdevFeature() to check if a network
device has Switchdev capabilities. virNetDevSwitchdevFeature() attempts
to retrieve the PCI device associated with the network device, ignoring
non-PCI devices. It does so via the following call chain

  virNetDevSwitchdevFeature()->virNetDevGetPCIDevice()->
  virPCIGetDeviceAddressFromSysfsLink()

For non-PCI network devices (qeth, Xen vif, etc),
virPCIGetDeviceAddressFromSysfsLink() will report an error when
virPCIDeviceAddressParse() fails. virPCIDeviceAddressParse() also
logs an error. After commit 8708ca01 there are now two errors reported
for each non-PCI network device even though the errors are harmless.

To avoid the errors, introduce virNetDevIsPCIDevice() and use it in
virNetDevGetPCIDevice() before attempting to retrieve the associated
PCI device. virNetDevIsPCIDevice() uses the 'subsystem' property of the
device to determine if it is PCI. See the sysfs rules in kernel
documentation for more details

https://www.kernel.org/doc/html/latest/admin-guide/sysfs-rules.html
      71d56a39
  9. 19 1月, 2018 2 次提交
  11. 18 1月, 2018 14 次提交
  13. 17 1月, 2018 1 次提交
  15. 16 1月, 2018 1 次提交
  17. 12 1月, 2018 5 次提交
  19. 11 1月, 2018 1 次提交
  21. 10 1月, 2018 9 次提交
    • J
      storage: Complete implementation volume by hash object · be1bb6c9
      由 John Ferlan 提交于 
      Alter the volume logic to use the hash tables instead of forward
linked lists. There are three hash tables to allow for fast lookup
by name, target.path, and key.

Modify the virStoragePoolObjAddVol to place the object in all 3
tables if possible using self locking RWLock on the volumes object.
Conversely when removing the volume, it's a removal of the object
from the various hash tables.

Implement functions to handle remote ForEach and Search Volume
type helpers. These are used by the disk backend in order to
facilitate adding a primary, extended, or logical partition.

Implement the various VolDefFindBy* helpers as simple (and fast)
hash lookups. The NumOfVolumes, GetNames, and ListExport helpers
are all implemented using standard for each hash table calls.
      be1bb6c9
    • J
      storage: Introduce _virStorageVolObj[List] · f77c898d
      由 John Ferlan 提交于 
      Prepare for hash table volume lists by creating the object infrastructure
for a Volume Object and Volume Object List

The _virStorageVolObj will contain just a pointer to the "current"
(and live) volume definition.

The _virStorageVolObjList will contain three hash tables, one for
each of the lookup options allowed for a volume.
      f77c898d
    • J
      storage: Modify virStorageBackendDiskMakeDataVol logic · 71d80c97
      由 John Ferlan 提交于 
      Alter the logic such that we only add the volume to the pool once
we've filled in all the information and cause failure to go to a
common error: label. Patches to place the @vol into a few hash tables
will soon "require" that at least the keys (name, target.path, and key)
be populated with valid data.
      71d80c97
    • J
      storage: When delete volume avoid disk backend removal · ec24d290
      由 John Ferlan 提交于 
      For a disk backend, the deleteVol code will clear all the
volumes in the pool and perform a pool refresh, thus the
storageVolDeleteInternal should not use access @voldef
after deleteVol succeeds.
      ec24d290
    • J
      cpu_x86: Copy CPU signature from ancestor · b427cf48
      由 Jiri Denemark 提交于 
      When specifying a new CPU model in cpu_map.xml as an extension to an
existing model, we forgot to copy the signature (family + model) from
the original CPU model.

We don't use this way of specifying CPU models, but it's still supported
and it becomes useful when someone wants to quickly hack up a CPU model
for testing or when creating additional variants of existing models to
help with fixing some spectral issues.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      b427cf48
    • J
      cpu_x86: Add debug messages to x86DecodeUseCandidate · ad80ccd3
      由 Jiri Denemark 提交于 
      When translating CPUID data into CPU model + features, the code
sometimes uses an unexpected CPU model. There may be several reasons for
this, starting with wrong expectations and ending with an actual bug in
our code. These debug messages will help determining the reason.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      ad80ccd3
    • C
      apparmor, virt-aa-helper: drop static channel rule · 335ea94e
      由 Christian Ehrhardt 提交于 
      This is now covered by DomainSetPathLabel being implemented in apparmor.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      335ea94e
    • C
      security, apparmor: add (Set|Restore)ChardevLabel · 14b52bb7
      由 Christian Ehrhardt 提交于 
      Since 1b4f66ec "security: introduce virSecurityManager
(Set|Restore)ChardevLabel" this is a public API of security manager.

Implementing this in apparmor avoids miss any rules that should be
added for devices labeled via these calls.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      14b52bb7
    • C
      security: full path option for DomainSetPathLabel · a5486e57
      由 Christian Ehrhardt 提交于 
      virSecurityManagerDomainSetPathLabel is used to make a path known
to the security modules, but today is used interchangably for
 - paths to files/dirs to be accessed directly
 - paths to a dir, but the access will actually be to files therein

Depending on the security module it is important to know which of
these types it will be.

The argument allowSubtree augments the call to the implementations of
DomainSetPathLabel that can - per security module - decide if extra
actions shall be taken.

For now dac/selinux handle this as before, but apparmor will make
use of it to add a wildcard to the path that was passed.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      a5486e57