Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 11 1月, 2018 3 次提交
  3. 10 1月, 2018 11 次提交
    • 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
    • J
      cputest: Fix cpu-cpuid.py diff command · 5ea187bc
      由 Jiri Denemark 提交于 
      The cpuidMap in cpu-cpuid.py was created for converting old data files
(with QEMU's feature-words bits) to the new model-expansion based data.
When I added tests for CPU live update based on disabled/enabled feature
lists I shamelessly used the existing cpuidMap for generating the
*-{enabled,disabled}.xml data files. Thus any new CPUID bits which are
not present in the original cpuidMap would be ignored. The correct thing
to do is to use cpu_map.xml.

All data files were fixed by running the following command:

    ./cpu-cpuid.py diff *.json
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      5ea187bc
    • 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
    • C
      security, apparmor: implement domainSetPathLabel · f436a782
      由 Christian Ehrhardt 提交于 
      This came up in discussions around huge pages, but it will cover
more per guest paths that should be added to the guests apparmor profile:
 - keys via qemuDomainWriteMasterKeyFile
 - per domain dirs via qemuProcessMakeDir
 - memory backing paths via qemuProcessBuildDestroyMemoryPathsImpl
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      f436a782
  5. 09 1月, 2018 10 次提交
  7. 08 1月, 2018 6 次提交
  9. 06 1月, 2018 2 次提交
  11. 05 1月, 2018 3 次提交
  13. 04 1月, 2018 5 次提交