[libvirt] [PATCH 09/17] cpu: Add SandyBridge-IBRS CPU model

This is a variant of SandyBridge with indirect branch prediction protection. The only difference between SandyBridge and SandyBridge-IBRS is the added "spec-ctrl" feature. The SandyBridge-IBRS model in QEMU is a bit different since SandyBridge got several additional features since we added it in

[libvirt] [PATCH 05/17] cputest: Add data for updated AMD EPYC 7601 32-Core Processor

The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: Jiri Denemark --- tests/cputest.c| 1 + ...86_64-cpuid-EPYC-7601-32-Core-ibpb-disabled.xml | 7 + ...x86_64-cpuid-EPYC-7601-32-Core-ibpb-enabled.xml | 9 +

[libvirt] [PATCH 07/17] cpu: Add Nehalem-IBRS CPU model

This is a variant of Nehalem with indirect branch prediction protection. The only difference between Nehalem and Nehalem-IBRS is the added "spec-ctrl" feature. Thus the diff matches QEMU, but the new CPU model itself is different. The QEMU's versions of both models contain "vme" feature, while

[libvirt] [PATCH 17/17] cpu: Add EPYC-IBPB CPU model

This is a variant of EPYC with indirect branch prediction protection. The only difference between EPYC and EPYC-IBPB is the added "ibpb" feature. Signed-off-by: Jiri Denemark --- src/cpu/cpu_map.xml| 72 ++

[libvirt] [PATCH 08/17] cpu: Add Westmere-IBRS CPU model

This is a variant of Westmere with indirect branch prediction protection. The only difference between Westmere and Westmere-IBRS is the added "spec-ctrl" feature. The Westmere-IBRS model in QEMU is a bit different since Westmere got several additional features since we added it in cpu_map.xml:

[libvirt] [PATCH 13/17] cpu: Add Broadwell-noTSX-IBRS CPU model

This is a variant of Broadwell-noTSX with indirect branch prediction protection. The only difference between Broadwell-noTSX and Broadwell-noTSX-IBRS is the added "spec-ctrl" feature. The Broadwell-noTSX-IBRS model in QEMU is a bit different since Broadwell-noTSX got several additional features

[libvirt] [PATCH 15/17] cpu: Add Skylake-Client-IBRS CPU model

This is a variant of Skylake-Client with indirect branch prediction protection. The only difference between Skylake-Client and Skylake-Client-IBRS is the added "spec-ctrl" feature. Signed-off-by: Jiri Denemark --- src/cpu/cpu_map.xml| 69

[libvirt] [PATCH 10/17] cpu: Add IvyBridge-IBRS CPU model

This is a variant of IvyBridge with indirect branch prediction protection. The only difference between IvyBridge and IvyBridge-IBRS is the added "spec-ctrl" feature. The IvyBridge-IBRS model in QEMU is a bit different since IvyBridge got several additional features since we added it in

[libvirt] [PATCH 04/17] cputest: Add data for Intel(R) Xeon(R) Gold 5115 CPU

The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: Jiri Denemark --- tests/cputest.c| 1 + .../x86_64-cpuid-Xeon-Gold-5115-disabled.xml | 8 + .../x86_64-cpuid-Xeon-Gold-5115-enabled.xml| 8 +

[libvirt] [PATCH 11/17] cpu: Add Haswell-noTSX-IBRS CPU model

This is a variant of Haswell-noTSX with indirect branch prediction protection. The only difference between Haswell-noTSX and Haswell-noTSX-IBRS is the added "spec-ctrl" feature. The Haswell-noTSX-IBRS model in QEMU is a bit different since Haswell-noTSX got several additional features since we

[libvirt] [PATCH 14/17] cpu: Add Broadwell-IBRS CPU model

This is a variant of Broadwell with indirect branch prediction protection. The only difference between Broadwell and Broadwell-IBRS is the added "spec-ctrl" feature. The Broadwell-IBRS model in QEMU is a bit different since Broadwell got several additional features since we added it in

[libvirt] [PATCH 16/17] cpu: Add Skylake-Server-IBRS CPU model

This is a variant of Skylake-Server with indirect branch prediction protection. The only difference between Skylake-Server and Skylake-Server-IBRS is the added "spec-ctrl" feature. Signed-off-by: Jiri Denemark --- src/cpu/cpu_map.xml| 76

[libvirt] [PATCH 12/17] cpu: Add Haswell-IBRS CPU model

This is a variant of Haswell with indirect branch prediction protection. The only difference between Haswell and Haswell-IBRS is the added "spec-ctrl" feature. The Haswell-IBRS model in QEMU is a bit different since Haswell got several additional features since we added it in cpu_map.xml:

[libvirt] [PATCH 02/17] cputest: Add data for Intel(R) Xeon(R) CPU E5-2609 v3

The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: Jiri Denemark --- tests/cputest.c| 1 + .../x86_64-cpuid-Xeon-E5-2609-v3-disabled.xml | 6 + .../x86_64-cpuid-Xeon-E5-2609-v3-enabled.xml | 8 +

[libvirt] [PATCH 06/17] cputest: Add data for updated Intel(R) Core(TM) i7-5600U CPU

The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: Jiri Denemark --- tests/cputest.c| 1 + .../x86_64-cpuid-Core-i7-5600U-ibrs-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-5600U-ibrs-enabled.xml| 8 +

[libvirt] [PATCH 03/17] cputest: Add data for Intel(R) Xeon(R) CPU E5-2623 v4

The CPU contains the updated microcode for CVE-2017-5715. The *-guest.xml and *-json.xml CPU definitions use Skylake-Client CPU model rather than Broadwell. This is similar to Xeon-E5-2650-v4 and it is caused by our CPU model selection code when no model matches the CPU signature (family +

[libvirt] [PATCH 01/17] cpu: add CPU features for indirect branch prediction protection

From: Paolo Bonzini Added in QEMU commits TBD and TBD. Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Denemark --- src/cpu/cpu_map.xml | 8 1 file changed, 8 insertions(+) diff --git a/src/cpu/cpu_map.xml

[libvirt] [PATCH 00/17] CPU models and features for Spectre, CVE-2017-5715

This is the libvirt's part of the changes related to CVE-2017-5715. The new models can be used to pass the protective CPU features to guests. But remember, the host CPU microcode, host kernel, QEMU, and libvirt all need to be updated for this to be any useful. Based on a patch from Paolo Bonzini.

[libvirt] [PATCH 3/4] storage: Introduce _virStorageVolObj[List]

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

[libvirt] [PATCH 2/4] storage: Modify virStorageBackendDiskMakeDataVol logic

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

[libvirt] [PATCH 0/4] Alter Disk Volume logic to use objects

This series converts the storage volume forward linked list into an object that contains hash tables of volume objects. The first two patches resolve issues seen during testing with the Disk backend which had some special cased code to handle the Create/Delete paths and interactions with the

[libvirt] [PATCH 4/4] storage: Complete implementation volume by hash object

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.

[libvirt] [PATCH 1/4] storage: When delete volume avoid disk backend removal

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. Signed-off-by: John Ferlan --- src/storage/storage_driver.c | 14 ++

Re: [libvirt] [PATCH] docs: formatdomain: Specify the default value of 'check' attribute

On Tue, Jan 09, 2018 at 19:44:18 +0100, Kashyap Chamarthy wrote: > On Tue, Jan 09, 2018 at 04:37:10PM +0100, Jiri Denemark wrote: > > On Tue, Jan 09, 2018 at 15:32:54 +0100, Kashyap Chamarthy wrote: > > [...] > > > > But doesn't tell *what* the default value is. It is check='partial'. > > >

Re: [libvirt] [PATCH] docs: formatdomain: Specify the default value of 'check' attribute

On Tue, Jan 09, 2018 at 04:37:10PM +0100, Jiri Denemark wrote: > On Tue, Jan 09, 2018 at 15:32:54 +0100, Kashyap Chamarthy wrote: [...] > > But doesn't tell *what* the default value is. It is check='partial'. > > Mention it so. [...] > NACK > > As I said on IRC, the default differs with guest

Re: [libvirt] [PATCH v2] nodedev: update mdev_types caps before dumpxml

On Mon, Jan 08, 2018 at 07:35:22PM +0800, Wu Zongyong wrote: > In current implemention, mdev_types caps keep constant all > the time. But, it is possible that a device capable of > mdev_types sometime(for example:bind to proper driver) and > incapable of mdev_types at other times(for example:

Re: [libvirt] [PATCH v2 2/4] security: full path option for DomainSetPathLabel

On Tue, Jan 9, 2018 at 5:31 PM, Michal Privoznik wrote: > On 01/09/2018 04:04 PM, Christian Ehrhardt wrote: >> virSecurityManagerDomainSetPathLabel is used to make a path known >> to the security modules, but today is used interchangably for >> - paths to files/dirs to be

Re: [libvirt] [PATCH v2 2/4] security: full path option for DomainSetPathLabel

On 01/09/2018 04:04 PM, Christian Ehrhardt wrote: > 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

Re: [libvirt] [PATCH v2 0/4] apparmor: implement more domain callbacks

On 01/09/2018 04:04 PM, Christian Ehrhardt wrote: > Based on a discussion in [1] I found that the AppArmor security > module lacked some callbacks. Implementing those not only fixes > the issue I had before but will also cover a few more cases I > didn't even run into so far. > > [1]:

Re: [libvirt] [PATCH] docs: formatdomain: Specify the default value of 'check' attribute

On Tue, Jan 09, 2018 at 15:32:54 +0100, Kashyap Chamarthy wrote: > The 'check' attribute is referring to this: > > > > Upstream documentation says, it is: > > used to request a specific way of checking whether the virtual CPU > matches the specification. It is usually safe to omit

[libvirt] Ping Re: [PATCH V4] blockjob: Fix error checking of blockjob status

Ping On 2018/1/5 10:53, Jie Wang wrote: > offset and len can also be equal to 0 on failed if blockjob return > status:"BLOCK_JOB_COMPLETED" with error:"File descriptor in bad state", > so we need to check 'error' in this case. > --- > src/qemu/qemu_monitor_json.c | 2 +- > 1 file changed, 1

[libvirt] [PATCH v2 0/4] apparmor: implement more domain callbacks

Based on a discussion in [1] I found that the AppArmor security module lacked some callbacks. Implementing those not only fixes the issue I had before but will also cover a few more cases I didn't even run into so far. [1]: https://www.redhat.com/archives/libvir-list/2017-December/msg00726.html

[libvirt] [PATCH v2 2/4] security: full path option for DomainSetPathLabel

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

[libvirt] [PATCH v2 3/4] security, apparmor: add (Set|Restore)ChardevLabel

Since 1b4f66e "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: Christian Ehrhardt

[libvirt] [PATCH v2 1/4] security, apparmor: implement domainSetPathLabel

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

[libvirt] [PATCH v2 4/4] apparmor, virt-aa-helper: drop static channel rule

This is now covered by DomainSetPathLabel being implemented in apparmor. Signed-off-by: Christian Ehrhardt --- src/security/virt-aa-helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index

Re: [libvirt] [PATCH 3/4] security, apparmor: add (Set|Restore)ChardevLabel

>> +char *in = NULL, *out = NULL; >> +int ret = -1; >> + >> +virSecurityLabelDefPtr secdef = virDomainDefGetSecurityLabelDef(def, >> +SECURITY_APPARMOR_NAME); >> +if (!secdef) >> +return 0; > > There shouldn't be empty line in

Re: [libvirt] [PATCH 2/4] security: full path option for DomainSetPathLabel

On Tue, Jan 9, 2018 at 11:02 AM, Michal Privoznik wrote: > On 01/03/2018 06:00 PM, Christian Ehrhardt wrote: [...] >> AppArmorSetPathLabel(virSecurityManagerPtr mgr, >> virDomainDefPtr def, >> - const char *path) >> +

Re: [libvirt] [PATCH] usb: allow host devices to be specified by port

> [libvirt] [PATCH] usb: allow host devices to be specified by port > > > > From: Thomas Hebb To: libvir-list redhat comCc: > Thomas Hebb Subject: [libvirt] [PATCH] usb: allow > host devices to be specified by portDate: Tue, 5 Jul

Re: [libvirt] [PATCH 0/4] apparmor: implement more domain callbacks

On Tue, Jan 9, 2018 at 11:02 AM, Michal Privoznik wrote: > On 01/03/2018 06:00 PM, Christian Ehrhardt wrote: >> Based on a discussion in [1] I found that the AppArmor security >> module lacked some callbacks. Implementing those not only fixes >> the issue I had before but

[libvirt] [PATCH] docs: formatdomain: Specify the default value of 'check' attribute

The 'check' attribute is referring to this: Upstream documentation says, it is: used to request a specific way of checking whether the virtual CPU matches the specification. It is usually safe to omit this attribute when starting a domain and stick with the default value. But

Re: [libvirt] [PATCH 5/5] qemu: implement the 'libvirt_qemu' shim for launching guests externally

On Wed, Dec 20, 2017 at 04:47:50PM +, Daniel P. Berrange wrote: This introduces a new binary 'libvirt_qemu' which can be used to launch guests externally from libvirtd. eg libvirt_qemu -c qemu:///system /path/to/xml/file This will launch a guest from the requested XML file and then

Re: [libvirt] [PATCH 4/5] qemu: implement the new virDomainQemuReconnect method

On Wed, Dec 20, 2017 at 04:47:49PM +, Daniel P. Berrange wrote: Signed-off-by: Daniel P. Berrange --- src/qemu/qemu_driver.c | 57 + src/qemu/qemu_process.c | 31 ++- src/qemu/qemu_process.h | 1 + 3

Re: [libvirt] [PATCH 1/5] conf: allow different resource registration modes

I'm so sorry for not getting to this earlier. I though I'll get to this over the holidays, but they were very busy with no free time for me. On Wed, Dec 20, 2017 at 04:47:46PM +, Daniel P. Berrange wrote: Currently the QEMU driver has three ways of setting up cgroups. It either skips them

[libvirt] [PATCH 1/2] Fix memory leak in set_other_id_info

model was allocated by asprintf but never freed after usage and assignment. Signed-off-by: Adam Majer --- src/Virt_ComputerSystem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/Virt_ComputerSystem.c b/src/Virt_ComputerSystem.c index da07f93..b4930ac 100644 ---

[libvirt] [cim][PATCH 0/2] memory leak fixes in CIM provider

In some instances, asprintf allocated memory is not freed resulting in a slow memory leak. Adam Majer (2): Fix memory leak in set_other_id_info Fix memory leak in set_input_props src/Virt_ComputerSystem.c | 2 ++ src/Virt_SettingsDefineCapabilities.c | 6 -- 2 files changed,

[libvirt] [PATCH 2/2] Fix memory leak in set_input_props

When caption is specified, cap was allocated and assigned a new pointer while the old never freed. Free cap before replacing it. get_input_dev_caption only returns valid cap pointer on success, so do not try to free it on failure. Signed-off-by: Adam Majer ---

Re: [libvirt] [cim][PATCH 1/2] Fix memory leak in set_other_id_info

On 12/18/2017 02:31 PM, John Ferlan wrote: > Looks OK; however, there hasn't been a non build related source code > change to libvirt-cim since June 2014. So while this could be pushed, > I'm curious to understand why the "sudden interest" in CIM? The last > release was July 2013! I'm not sure

Re: [libvirt] [PATCH V2] nodedev: Fix failing to parse PCI address for non-PCI network devices

On Mon, Jan 08, 2018 at 10:08:59AM -0700, Jim Fehlig wrote: > Based loosely on a patch from Fei Li . > > Commit 8708ca01c added virNetDevSwitchdevFeature() to check if a network > device has Switchdev capabilities. virNetDevSwitchdevFeature() attempts > to retrieve the PCI device

Re: [libvirt] [PATCH] tests: Only format the CPU frequency if it's known

On 01/09/2018 04:06 AM, Andrea Bolognani wrote: > On Mon, 2018-01-08 at 11:19 -0500, John Ferlan wrote: >> On 01/08/2018 09:50 AM, Peter Krempa wrote: >>> On Mon, Jan 08, 2018 at 15:10:29 +0100, Andrea Bolognani wrote: Instead of formatting 'MHz: 0', which can be confusing, skip the

Re: [libvirt] [PATCH 06/12] apparmor, libvirt-qemu: Allow access to hugepage mounts

On Tue, Jan 9, 2018 at 11:02 AM, Cedric Bosdonnat wrote: > On Wed, 2018-01-03 at 17:55 +0100, Christian Ehrhardt wrote: >> [...] >> >> > > To me, 1 feels most correct cause while the other two fix hugepages, >> > > there seem to be lurking bugs since we aren't implementing >>

Re: [libvirt] [PATCH] add support of iSER transport type in qemu with libiscsi

Hello, I have not got revert back since I sent last patch on 12/22/2017, just want to know how it is going on? Regards, Charles. On Fri, Dec 22, 2017 at 3:08 PM, Charles Kelimod wrote: > Hi Peter, > > I will remove the comment. > I did the test and noticed the issue, then

Re: [libvirt] [PATCH] cpu: Add support for al57 Intel features

On Mon, Jan 08, 2018 at 19:06:43 +0800, Feng, Shaohe wrote: > On 2018年01月05日 02:52, John Ferlan wrote: > > > > On 12/17/2017 06:02 PM, Shaohe Feng wrote: > >> 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. >

Re: [libvirt] [PATCH 3/4] security, apparmor: add (Set|Restore)ChardevLabel

On 01/03/2018 06:00 PM, Christian Ehrhardt wrote: > Since 1b4f66e "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. I

Re: [libvirt] [PATCH 06/12] apparmor, libvirt-qemu: Allow access to hugepage mounts

On Wed, 2018-01-03 at 17:55 +0100, Christian Ehrhardt wrote: > [...] > > > > To me, 1 feels most correct cause while the other two fix hugepages, > > > there seem to be lurking bugs since we aren't implementing > > > domainSetPathLabel. > > > > > > > I work on #1 a while and I think we can do a

Re: [libvirt] [PATCH 2/4] security: full path option for DomainSetPathLabel

On 01/03/2018 06:00 PM, Christian Ehrhardt wrote: > 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

Re: [libvirt] [PATCH 0/4] apparmor: implement more domain callbacks

On 01/03/2018 06:00 PM, Christian Ehrhardt wrote: > Based on a discussion in [1] I found that the AppArmor security > module lacked some callbacks. Implementing those not only fixes > the issue I had before but will also cover a few more cases I > didn't even run into so far. > > [1]:

Re: [libvirt] [PATCH 3/3] util: virsysinfo: parse frequency information on S390

John Ferlan [2018-01-08, 07:55AM -0500]: > > > On 01/08/2018 03:39 AM, Bjoern Walk wrote: > > John Ferlan [2018-01-04, 03:56PM -0500]: > >> On 12/19/2017 05:08 AM, Bjoern Walk wrote: > >>> diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c > >>>

Re: [libvirt] [PATCH] tests: Only format the CPU frequency if it's known

On Mon, 2018-01-08 at 11:19 -0500, John Ferlan wrote: > On 01/08/2018 09:50 AM, Peter Krempa wrote: > > On Mon, Jan 08, 2018 at 15:10:29 +0100, Andrea Bolognani wrote: > > > Instead of formatting 'MHz: 0', which can be confusing, skip the > > > field altogether. This behavior is consistent with