date:20181114

[libvirt] [libvirt-go PATCH] build: Fix the go build caused by a missing commentary end sequence

2018-11-14 Thread Erik Skultety

Commit 20ab0c4d added a new constant to reflect recent libvirt upstream
changes. However, it also introduced a tiny typo which caused the build
to fail.

Signed-off-by: Erik Skultety 
---
Pushed both under trivial and build-breaker rules.

 domain_compat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/domain_compat.h b/domain_compat.h
index 5069ea2..371bcc4 100644
--- a/domain_compat.h
+++ b/domain_compat.h
@@ -911,7 +911,7 @@ struct _virDomainInterface {
 #define VIR_DOMAIN_MEMORY_STAT_DISK_CACHES 10
 #endif

-/* 4.10.0
+/* 4.10.0 */

 #ifndef VIR_DOMAIN_SHUTOFF_DAEMON
 #define VIR_DOMAIN_SHUTOFF_DAEMON 8
--
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices

2018-11-14 Thread Eduardo Habkost

Many of the current virtio-*-pci device types actually represent
3 different types of devices:
* virtio 1.0 non-transitional devices
* virtio 1.0 transitional devices
* virtio 0.9 ("legacy device" in virtio 1.0 terminology)

That would be just an annoyance if it didn't break our device/bus
compatibility QMP interfaces.  With this multi-purpose device
type, there's no way to tell management software that
transitional devices and legacy devices require a Conventional
PCI bus.

The multi-purpose device types would also prevent us from telling
management software what's the PCI vendor/device ID for them,
because their PCI IDs change at runtime depending on the bus
where they were plugged.

This patch adds separate device types for each of those virtio
device flavors:

- virtio-*-pci: the existing multi-purpose device types
  - Configurable using `disable-legacy` and `disable-modern`
properties
  - Legacy driver support is automatically enabled/disabled
depending on the bus where it is plugged
  - Supports Conventional PCI and PCI Express buses
(but Conventional PCI is incompatible with
disable-legacy=off)
  - Changes PCI vendor/device IDs at runtime
- virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
  - Supports Conventional PCI buses only, because
it has a PIO BAR
- virtio-*-pci-non-transitional: modern-only
  - Supports both Conventional PCI and PCI Express buses

All the types above will inherit from an abstract
"virtio-*-pci-base" type, so existing code that doesn't care
about the virtio version can use "virtio-*-pci-base" on type
casts.

Note that devices that are always non-transitional won't have the
-non-transitional variants added, because it would be redundant.

A simple test script (tests/acceptance/virtio_version.py) is
included, to check if the new device types are equivalent to
using the `disable-legacy` and `disable-modern` options.

Signed-off-by: Eduardo Habkost 
---
Reference to previous discussion that originated this idea:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg558389.html

Changes v1 -> v2:
* Removed *-0.9 devices.  Nobody will want to use them, if
  transitional devices work with legacy drivers
  (Gerd Hoffmann, Michael S. Tsirkin)
* Drop virtio version from name: rename -1.0-transitional to
  -transitional (Michael S. Tsirkin)
* Renamed -1.0 to -non-transitional
* Don't add any extra variants to modern-only device types
  (they don't need it)
* Fix typo on TYPE_VIRTIO_INPUT_HOST_PCI (crash reported by
  Cornelia Huck)
* No need to change cast macros for modern-only devices
* Rename virtio_register_types() to virtio_pci_types_register()

Note about points discussed in the v1 thread:

Andrea suggested making separate transitional Conventional PCi
and transitional PCI Express device types[1].  I didn't do that
because I don't see which problems this solves.  We have many
other device types that are hybrid (support both PCI Express and
Conventional PCI) and this was never a problem for us[2].

[1] 
http://mid.mail-archive.com/6f8d59b8ee2d92d73d2957b520bd8bac989fc796.camel@redhat.com
[2] http://mid.mail-archive.com/20181017155637.GC31060@habkost.net
---
 hw/virtio/virtio-pci.h |  80 +--
 hw/display/virtio-gpu-pci.c|   8 +-
 hw/display/virtio-vga.c|   8 +-
 hw/virtio/virtio-crypto-pci.c  |   8 +-
 hw/virtio/virtio-pci.c | 215 -
 tests/acceptance/virtio_version.py | 177 
 6 files changed, 406 insertions(+), 90 deletions(-)
 create mode 100644 tests/acceptance/virtio_version.py

diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 813082b0d7..1d2a11504f 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -216,7 +216,8 @@ static inline void virtio_pci_disable_modern(VirtIOPCIProxy 
*proxy)
 /*
  * virtio-scsi-pci: This extends VirtioPCIProxy.
  */
-#define TYPE_VIRTIO_SCSI_PCI "virtio-scsi-pci"
+#define TYPE_VIRTIO_SCSI_PCI_PREFIX "virtio-scsi-pci"
+#define TYPE_VIRTIO_SCSI_PCI (TYPE_VIRTIO_SCSI_PCI_PREFIX "-base")
 #define VIRTIO_SCSI_PCI(obj) \
 OBJECT_CHECK(VirtIOSCSIPCI, (obj), TYPE_VIRTIO_SCSI_PCI)
 
@@ -229,7 +230,8 @@ struct VirtIOSCSIPCI {
 /*
  * vhost-scsi-pci: This extends VirtioPCIProxy.
  */
-#define TYPE_VHOST_SCSI_PCI "vhost-scsi-pci"
+#define TYPE_VHOST_SCSI_PCI_PREFIX "vhost-scsi-pci"
+#define TYPE_VHOST_SCSI_PCI (TYPE_VHOST_SCSI_PCI_PREFIX "-base")
 #define VHOST_SCSI_PCI(obj) \
 OBJECT_CHECK(VHostSCSIPCI, (obj), TYPE_VHOST_SCSI_PCI)
 
@@ -239,7 +241,8 @@ struct VHostSCSIPCI {
 };
 #endif
 
-#define TYPE_VHOST_USER_SCSI_PCI "vhost-user-scsi-pci"
+#define TYPE_VHOST_USER_SCSI_PCI_PREFIX "vhost-user-scsi-pci"
+#define TYPE_VHOST_USER_SCSI_PCI (TYPE_VHOST_USER_SCSI_PCI_PREFIX "-base")
 #define VHOST_USER_SCSI_PCI(obj) \
 OBJECT_CHECK(VHostUserSCSIPCI, (obj), TYPE_VHOST_USER_SCSI_PCI)
 
@@ -252,7 +255,8 @@ struct VHostUserSCSIPCI {
 /*
  * vhost-user-blk-pci: This

[libvirt] [PATCH v3 6/6] news: mention Hyper-V PV IPI and Enlightened VMCS support

2018-11-14 Thread Vitaly Kuznetsov

The QEMU driver now has support for Hyper-V PV IPI and Enlightened VMCS
for Windows and Hyper-V guests.

Suggested-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 docs/news.xml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 88774c55ae..0f603f568c 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -35,6 +35,15 @@
 
   
 
+  
+
+  qemu: Add Hyper-V PV IPI and Enlightened VMCS support
+
+
+  The QEMU driver now has support for Hyper-V PV IPI and Enlightened 
VMCS
+  for Windows and Hyper-V guests.
+
+  
 
 
 
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v3 5/6] qemu: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Vitaly Kuznetsov

QEMU 3.1 supports Hyper-V Enlightened VMCS feature which significantly
speeds up nested Hyper-V on KVM environments.

Signed-off-by: Vitaly Kuznetsov 
---
 src/qemu/qemu_command.c | 2 +-
 src/qemu/qemu_parse_command.c   | 2 +-
 src/qemu/qemu_process.c | 2 +-
 tests/qemuxml2argvdata/hyperv-off.xml   | 1 +
 tests/qemuxml2argvdata/hyperv.args  | 2 +-
 tests/qemuxml2argvdata/hyperv.xml   | 1 +
 tests/qemuxml2xmloutdata/hyperv-off.xml | 1 +
 tests/qemuxml2xmloutdata/hyperv.xml | 1 +
 8 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 27e77f7d66..d543ada2a1 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6883,6 +6883,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (def->hyperv_features[i] == VIR_TRISTATE_SWITCH_ON)
 virBufferAsprintf(, ",hv_%s",
   virDomainHypervTypeToString(i));
@@ -6900,7 +6901,6 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);
 break;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_LAST:
 break;
diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
index a1f8369919..d91fc8d901 100644
--- a/src/qemu/qemu_parse_command.c
+++ b/src/qemu/qemu_parse_command.c
@@ -1540,6 +1540,7 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (value) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("HyperV feature '%s' should not "
@@ -1580,7 +1581,6 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 
 break;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 case VIR_DOMAIN_HYPERV_LAST:
 break;
 }
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index ed8bcf7f76..ebe8e244ae 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3954,12 +3954,12 @@ qemuProcessVerifyHypervFeatures(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("host doesn't support hyperv '%s' feature"),
virDomainHypervTypeToString(i));
 return -1;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_VENDOR_ID:
 case VIR_DOMAIN_HYPERV_LAST:
diff --git a/tests/qemuxml2argvdata/hyperv-off.xml 
b/tests/qemuxml2argvdata/hyperv-off.xml
index e51cca45b5..59c1e17ccd 100644
--- a/tests/qemuxml2argvdata/hyperv-off.xml
+++ b/tests/qemuxml2argvdata/hyperv-off.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2argvdata/hyperv.args 
b/tests/qemuxml2argvdata/hyperv.args
index 0800e4f79d..5d59788e14 100644
--- a/tests/qemuxml2argvdata/hyperv.args
+++ b/tests/qemuxml2argvdata/hyperv.args
@@ -10,7 +10,7 @@ QEMU_AUDIO_DRV=none \
 -machine pc,accel=tcg,usb=off,dump-guest-core=off \
 -cpu 'qemu32,hv_relaxed,hv_vapic,hv_spinlocks=0x2fff,hv_vpindex,hv_runtime,\
 hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv,hv_frequencies,\
-hv_reenlightenment,hv_tlbflush,hv_ipi' \
+hv_reenlightenment,hv_tlbflush,hv_ipi,hv_evmcs' \
 -m 214 \
 -smp 6,sockets=6,cores=1,threads=1 \
 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
diff --git a/tests/qemuxml2argvdata/hyperv.xml 
b/tests/qemuxml2argvdata/hyperv.xml
index 05c7d478f7..c6feaed528 100644
--- a/tests/qemuxml2argvdata/hyperv.xml
+++ b/tests/qemuxml2argvdata/hyperv.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv-off.xml 
b/tests/qemuxml2xmloutdata/hyperv-off.xml
index 2282b763b5..1b7d82b14a 100644
--- a/tests/qemuxml2xmloutdata/hyperv-off.xml
+++ b/tests/qemuxml2xmloutdata/hyperv-off.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv.xml 
b/tests/qemuxml2xmloutdata/hyperv.xml
index 97f387c172..5510d3dfad 100644
--- a/tests/qemuxml2xmloutdata/hyperv.xml
+++ b/tests/qemuxml2xmloutdata/hyperv.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v3 2/6] conf: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

Support Hyper-V PV IPI enlightenment in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI cases
to src/qemu/* for now.

Reviewed-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 7 +++
 docs/schemas/domaincommon.rng | 5 +
 src/conf/domain_conf.c| 7 ++-
 src/conf/domain_conf.h| 1 +
 src/cpu/cpu_x86.c | 3 +++
 src/cpu/cpu_x86_data.h| 1 +
 src/qemu/qemu_command.c   | 1 +
 src/qemu/qemu_parse_command.c | 1 +
 src/qemu/qemu_process.c   | 1 +
 9 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 28246deb63..7592f13a84 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1981,6 +1981,7 @@
 frequencies state='on'/
 reenlightenment state='on'/
 tlbflush state='on'/
+ipi state='on'/
   /hyperv
   kvm
 hidden state='on'/
@@ -2121,6 +2122,12 @@
   on, off
   4.7.0 (QEMU 3.0)
 
+
+  ipi
+  Enable PV IPI support
+  on, off
+  4.10.0 (QEMU 3.1)
+
   
   
   pvspinlock
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index b9ac5df479..26019b3279 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -5769,6 +5769,11 @@
 
   
 
+
+  
+
+  
+
   
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e8e0adc819..24876994c5 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -172,7 +172,9 @@ VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
   "vendor_id",
   "frequencies",
   "reenlightenment",
-  "tlbflush")
+  "tlbflush",
+  "ipi",
+);
 
 VIR_ENUM_IMPL(virDomainKVM, VIR_DOMAIN_KVM_LAST,
   "hidden")
@@ -19990,6 +19992,7 @@ virDomainDefParseXML(xmlDocPtr xml,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
@@ -22184,6 +22187,7 @@ virDomainDefFeaturesCheckABIStability(virDomainDefPtr 
src,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (src->hyperv_features[i] != dst->hyperv_features[i]) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("State of HyperV enlightenment "
@@ -27948,6 +27952,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e30a4b2fe7..9eea75548d 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1795,6 +1795,7 @@ typedef enum {
 VIR_DOMAIN_HYPERV_FREQUENCIES,
 VIR_DOMAIN_HYPERV_REENLIGHTENMENT,
 VIR_DOMAIN_HYPERV_TLBFLUSH,
+VIR_DOMAIN_HYPERV_IPI,
 
 VIR_DOMAIN_HYPERV_LAST
 } virDomainHyperv;
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 69a0c8db28..33252e927e 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -114,6 +114,8 @@ KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT,
 0x4003, 0x2000);
 KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_TLBFLUSH,
 0x4004, 0x0004);
+KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_IPI,
+0x4004, 0x0400);
 
 static virCPUx86Feature x86_kvm_features[] =
 {
@@ -137,6 +139,7 @@ static virCPUx86Feature x86_kvm_features[] =
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_FREQUENCIES),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_TLBFLUSH),
+KVM_FEATURE(VIR_CPU_x86_KVM_HV_IPI),
 };
 
 typedef struct _virCPUx86Model virCPUx86Model;
diff --git a/src/cpu/cpu_x86_data.h b/src/cpu/cpu_x86_data.h
index e75b3a2d0d..8c51d88e1a 100644
--- a/src/cpu/cpu_x86_data.h
+++ b/src/cpu/cpu_x86_data.h
@@ -65,6 +65,7 @@ struct _virCPUx86CPUID {
 # define VIR_CPU_x86_KVM_HV_FREQUENCIES "__kvm_hv_frequencies"
 # define VIR_CPU_x86_KVM_HV_REENLIGHTENMENT "__kvm_hv_reenlightenment"
 # define VIR_CPU_x86_KVM_HV_TLBFLUSH  "__kvm_hv_tlbflush"
+# define VIR_CPU_x86_KVM_HV_IPI   "__kvm_hv_ipi"
 
 
 # define VIR_CPU_X86_DATA_INIT { 0 }
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f59cbf559e..b4d3f1ee35 100644
--- a/src/qemu/qemu_command.c
+++

[libvirt] [PATCH v3 3/6] qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

QEMU 3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows
guests to send an IPI, especially when it targets many CPUs.

Reviewed-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 src/qemu/qemu_command.c | 2 +-
 src/qemu/qemu_parse_command.c   | 2 +-
 src/qemu/qemu_process.c | 2 +-
 tests/qemuxml2argvdata/hyperv-off.xml   | 1 +
 tests/qemuxml2argvdata/hyperv.args  | 2 +-
 tests/qemuxml2argvdata/hyperv.xml   | 1 +
 tests/qemuxml2xmloutdata/hyperv-off.xml | 1 +
 tests/qemuxml2xmloutdata/hyperv.xml | 1 +
 8 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index b4d3f1ee35..6fc8deff00 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6882,6 +6882,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (def->hyperv_features[i] == VIR_TRISTATE_SWITCH_ON)
 virBufferAsprintf(, ",hv_%s",
   virDomainHypervTypeToString(i));
@@ -6899,7 +6900,6 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);
 break;
 
-case VIR_DOMAIN_HYPERV_IPI:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_LAST:
 break;
diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
index ab418432af..a15f4d1121 100644
--- a/src/qemu/qemu_parse_command.c
+++ b/src/qemu/qemu_parse_command.c
@@ -1539,6 +1539,7 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (value) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("HyperV feature '%s' should not "
@@ -1579,7 +1580,6 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 
 break;
 
-case VIR_DOMAIN_HYPERV_IPI:
 case VIR_DOMAIN_HYPERV_LAST:
 break;
 }
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 3291d3f439..85e2f7046b 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3953,12 +3953,12 @@ qemuProcessVerifyHypervFeatures(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("host doesn't support hyperv '%s' feature"),
virDomainHypervTypeToString(i));
 return -1;
 
-case VIR_DOMAIN_HYPERV_IPI:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_VENDOR_ID:
 case VIR_DOMAIN_HYPERV_LAST:
diff --git a/tests/qemuxml2argvdata/hyperv-off.xml 
b/tests/qemuxml2argvdata/hyperv-off.xml
index dc5777355f..e51cca45b5 100644
--- a/tests/qemuxml2argvdata/hyperv-off.xml
+++ b/tests/qemuxml2argvdata/hyperv-off.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2argvdata/hyperv.args 
b/tests/qemuxml2argvdata/hyperv.args
index c55204b0c8..0800e4f79d 100644
--- a/tests/qemuxml2argvdata/hyperv.args
+++ b/tests/qemuxml2argvdata/hyperv.args
@@ -10,7 +10,7 @@ QEMU_AUDIO_DRV=none \
 -machine pc,accel=tcg,usb=off,dump-guest-core=off \
 -cpu 'qemu32,hv_relaxed,hv_vapic,hv_spinlocks=0x2fff,hv_vpindex,hv_runtime,\
 hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv,hv_frequencies,\
-hv_reenlightenment,hv_tlbflush' \
+hv_reenlightenment,hv_tlbflush,hv_ipi' \
 -m 214 \
 -smp 6,sockets=6,cores=1,threads=1 \
 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
diff --git a/tests/qemuxml2argvdata/hyperv.xml 
b/tests/qemuxml2argvdata/hyperv.xml
index 816adf6907..05c7d478f7 100644
--- a/tests/qemuxml2argvdata/hyperv.xml
+++ b/tests/qemuxml2argvdata/hyperv.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv-off.xml 
b/tests/qemuxml2xmloutdata/hyperv-off.xml
index 77a8dac810..2282b763b5 100644
--- a/tests/qemuxml2xmloutdata/hyperv-off.xml
+++ b/tests/qemuxml2xmloutdata/hyperv-off.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv.xml 
b/tests/qemuxml2xmloutdata/hyperv.xml
index fc8c59a557..97f387c172 100644
--- a/tests/qemuxml2xmloutdata/hyperv.xml
+++ b/tests/qemuxml2xmloutdata/hyperv.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v3 1/6] docs: remove extra whitespace from Hyper-V enlightenments options

2018-11-14 Thread Vitaly Kuznetsov

Remove redundant leading whitespaces from " on, off".

Suggested-by: Andrea Bolognani 
Reviewed-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 269741a690..28246deb63 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -2052,7 +2052,7 @@
 
   relaxed
   Relax constraints on timers
-   on, off
+  on, off
   1.0.0 (QEMU 2.0)
 
 
@@ -2070,31 +2070,31 @@
 
   vpindex
   Virtual processor index
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
   runtime
   Processor time spent on running guest code and on behalf of 
guest code
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
   synic
   Enable Synthetic Interrupt Controller (SyNIC)
-   on, off
+  on, off
   1.3.3 (QEMU 2.6)
 
 
   stimer
   Enable SyNIC timers
-   on, off
+  on, off
   1.3.3 (QEMU 2.6)
 
 
   reset
   Enable hypervisor reset
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
@@ -2106,19 +2106,19 @@
 
   frequencies
   Expose frequency MSRs
-   on, off
+  on, off
   4.7.0 (QEMU 2.12)
 
 
   reenlightenment
   Enable re-enlightenment notification on migration
-   on, off
+  on, off
   4.7.0 (QEMU 3.0)
 
 
   tlbflush
   Enable PV TLB flush support
-   on, off
+  on, off
   4.7.0 (QEMU 3.0)
 
   
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 3/5] qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

Andrea Bolognani  writes:

> On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
>> Qemu 3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows
>
> s/Qemu/QEMU/
>
> Better than in v1 but not quite perfect yet ;)
>
> [...]
>> +  
>> +
>> +  qemu: Add Hyper-V PV IPI support
>> +
>> +
>> +  The QEMU driver now has support for Hyper-V PV IPI enlightenment
>> +  for Windows guests.
>> +
>> +  
>
> Okay, not your fault at all, just something that I failed to
> communicate properly: updates to the release notes are supposed to
> always go in their own commit. The rationale for that is making it
> easy for downstreams to cherry-pick the code changes without having
> to worry about conflicts in the documentation.
>
> Additionally, and again I'm at fault for not communicating it
> adequately, I kinda expected to have a single entry in the release
> notes covering both changes. Does that sound reasonable?
>
> Since everything else looks good and I'd rather not have you go
> through more trouble than you already have, if you're okay with it
> I can just drop this hunk from the patch, slap a
>
>   Reviewed-by: Andrea Bolognani 
>
> on it and push it; you can then re-post the release note update
> as a separate follow up patch. Let me know if that works for you.

No problem at all, I can do v3 fixing stuff like Qemu/QEMU, separate
docs/news.xml hunks into their own patch (squashing together as a single
).

Thanks for the review!

-- 
Vitaly

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v3 4/6] conf: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Vitaly Kuznetsov

Support Hyper-V Enlightened VMCS in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_EVMCS
cases to src/qemu/* for now.

Reviewed-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 7 +++
 docs/schemas/domaincommon.rng | 5 +
 src/conf/domain_conf.c| 4 
 src/conf/domain_conf.h| 1 +
 src/cpu/cpu_x86.c | 3 +++
 src/cpu/cpu_x86_data.h| 1 +
 src/qemu/qemu_command.c   | 1 +
 src/qemu/qemu_parse_command.c | 1 +
 src/qemu/qemu_process.c   | 1 +
 9 files changed, 24 insertions(+)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 7592f13a84..1b1518f465 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1982,6 +1982,7 @@
 reenlightenment state='on'/
 tlbflush state='on'/
 ipi state='on'/
+evmcs state='on'/
   /hyperv
   kvm
 hidden state='on'/
@@ -2128,6 +2129,12 @@
   on, off
   4.10.0 (QEMU 3.1)
 
+
+  evmcs
+  Enable Enlightened VMCS
+  on, off
+  4.10.0 (QEMU 3.1)
+
   
   
   pvspinlock
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 26019b3279..ff57ce1015 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -5774,6 +5774,11 @@
 
   
 
+
+  
+
+  
+
   
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 24876994c5..18d235872f 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -174,6 +174,7 @@ VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
   "reenlightenment",
   "tlbflush",
   "ipi",
+  "evmcs",
 );
 
 VIR_ENUM_IMPL(virDomainKVM, VIR_DOMAIN_KVM_LAST,
@@ -19993,6 +19994,7 @@ virDomainDefParseXML(xmlDocPtr xml,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
@@ -22188,6 +22190,7 @@ virDomainDefFeaturesCheckABIStability(virDomainDefPtr 
src,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (src->hyperv_features[i] != dst->hyperv_features[i]) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("State of HyperV enlightenment "
@@ -27953,6 +27956,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 9eea75548d..061185e779 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1796,6 +1796,7 @@ typedef enum {
 VIR_DOMAIN_HYPERV_REENLIGHTENMENT,
 VIR_DOMAIN_HYPERV_TLBFLUSH,
 VIR_DOMAIN_HYPERV_IPI,
+VIR_DOMAIN_HYPERV_EVMCS,
 
 VIR_DOMAIN_HYPERV_LAST
 } virDomainHyperv;
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 33252e927e..ebfa74fccd 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -116,6 +116,8 @@ KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_TLBFLUSH,
 0x4004, 0x0004);
 KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_IPI,
 0x4004, 0x0400);
+KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_EVMCS,
+0x4004, 0x4000);
 
 static virCPUx86Feature x86_kvm_features[] =
 {
@@ -140,6 +142,7 @@ static virCPUx86Feature x86_kvm_features[] =
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_TLBFLUSH),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_IPI),
+KVM_FEATURE(VIR_CPU_x86_KVM_HV_EVMCS),
 };
 
 typedef struct _virCPUx86Model virCPUx86Model;
diff --git a/src/cpu/cpu_x86_data.h b/src/cpu/cpu_x86_data.h
index 8c51d88e1a..f52bba821f 100644
--- a/src/cpu/cpu_x86_data.h
+++ b/src/cpu/cpu_x86_data.h
@@ -66,6 +66,7 @@ struct _virCPUx86CPUID {
 # define VIR_CPU_x86_KVM_HV_REENLIGHTENMENT "__kvm_hv_reenlightenment"
 # define VIR_CPU_x86_KVM_HV_TLBFLUSH  "__kvm_hv_tlbflush"
 # define VIR_CPU_x86_KVM_HV_IPI   "__kvm_hv_ipi"
+# define VIR_CPU_x86_KVM_HV_EVMCS "__kvm_hv_evmcs"
 
 
 # define VIR_CPU_X86_DATA_INIT { 0 }
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6fc8deff00..27e77f7d66 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6900,6 +6900,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);

[libvirt] [PATCH v3 0/6] conf: qemu: support new Hyper-V enlightenments in QEMU 3.1

2018-11-14 Thread Vitaly Kuznetsov

The upcoming QEMU 3.1 release will bring us two new Hyper-V enlightenments:
hv_ipi and hv_evmcs. Support these in libvirt.

Changes since v2:
- Separate docs/news.xml hunks in their own PATCH6, squash both
  changes together [Andrea Bolognani]
- s/Qemu/QEMU/g + 'whitespate' typo [Andrea Bolognani]

Vitaly Kuznetsov (6):
  docs: remove extra whitespace from Hyper-V enlightenments options
  conf: add support for Hyper-V PV IPIs
  qemu: add support for Hyper-V PV IPIs
  conf: add support for Hyper-V Enlightened VMCS
  qemu: add support for Hyper-V Enlightened VMCS
  news: mention Hyper-V PV IPI and Enlightened VMCS support

 docs/formatdomain.html.in   | 32 ++---
 docs/news.xml   |  9 +++
 docs/schemas/domaincommon.rng   | 10 
 src/conf/domain_conf.c  | 11 -
 src/conf/domain_conf.h  |  2 ++
 src/cpu/cpu_x86.c   |  6 +
 src/cpu/cpu_x86_data.h  |  2 ++
 src/qemu/qemu_command.c |  2 ++
 src/qemu/qemu_parse_command.c   |  2 ++
 src/qemu/qemu_process.c |  2 ++
 tests/qemuxml2argvdata/hyperv-off.xml   |  2 ++
 tests/qemuxml2argvdata/hyperv.args  |  2 +-
 tests/qemuxml2argvdata/hyperv.xml   |  2 ++
 tests/qemuxml2xmloutdata/hyperv-off.xml |  2 ++
 tests/qemuxml2xmloutdata/hyperv.xml |  2 ++
 15 files changed, 77 insertions(+), 11 deletions(-)

-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] rpc: Remove duplicate check from filter function return.

2018-11-14 Thread John Ferlan




On 11/14/18 12:49 PM, Julio Faracco wrote:
> This is a simple removal of a duplicated check of the return of the
> filter function. There is a nested conditional checking exactly the same
> thing.

s/./ since commit c9ede1cf removed the (ret > 0) check condition./

> 
> Signed-off-by: Julio Faracco 
> ---
>  src/rpc/virnetserverclient.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 


Reviewed-by: John Ferlan 

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: Using virStringListFreeCount instead VIR_FREE to free tmpPaths.

2018-11-14 Thread John Ferlan




On 11/14/18 12:32 PM, Julio Faracco wrote:
> The function qemuDomainGetHostdevPath() is using VIR_FREE to free the
> paths stored in tmpPaths. Both syntax analyzer are reporting a warning
> about this. Replacing the old method to function
> virStringListFreeCount() fixes the warnings/errors.
> 
> Signed-off-by: Julio Faracco 
> ---
>  src/qemu/qemu_domain.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

Reviewed-by: John Ferlan 

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 3/5] qemu_domain.c: moving maxCpu validation to qemuDomainDefValidate

2018-11-14 Thread Daniel Henrique Barboza

Adding maxCpu validation in qemuDomainDefValidate allows the user to
spot over the board maxCpus counts at editing time, instead of
facing a runtime error when starting the domain. This check is also
arch independent.

This leaves us with 2 calls to qemuProcessValidateCpuCount: one in
qemuProcessStartValidateXML and the new one at qemuDomainDefValidate.

The call in qemuProcessStartValidateXML is redundant. Following
up in that code, there is a call to virDomainDefValidate, which
in turn will call config.domainValidateCallback. In this case, the
callback function is qemuDomainDefValidate. This means that, on startup
time, qemuProcessValidateCpuCount will be called twice.

To avoid that, let's also remove the qemuProcessValidateCpuCount call
from qemuProcessStartValidateXML.

Signed-off-by: Daniel Henrique Barboza 
---
 src/qemu/qemu_domain.c  |  4 
 src/qemu/qemu_process.c | 14 +-
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 37926850b2..3b86d28216 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4084,6 +4084,10 @@ qemuDomainDefValidate(const virDomainDef *def,
 }
 }
 
+if (qemuProcessValidateCpuCount(def, qemuCaps) < 0) {
+goto cleanup;
+}
+
 if (ARCH_IS_X86(def->os.arch) &&
 virDomainDefGetVcpusMax(def) > QEMU_MAX_VCPUS_WITHOUT_EIM) {
 if (!qemuDomainIsQ35(def)) {
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 4d134bd7be..2adbf375ee 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5140,21 +5140,9 @@ qemuProcessStartValidateDisks(virDomainObjPtr vm,
 static int
 qemuProcessStartValidateXML(virQEMUDriverPtr driver,
 virDomainObjPtr vm,
-virQEMUCapsPtr qemuCaps,
 virCapsPtr caps,
 unsigned int flags)
 {
-/* The bits we validate here are XML configs that we previously
- * accepted. We reject them at VM startup time rather than parse
- * time so that pre-existing VMs aren't rejected and dropped from
- * the VM list when libvirt is updated.
- *
- * If back compat isn't a concern, XML validation should probably
- * be done at parse time.
- */
-if (qemuProcessValidateCpuCount(vm->def, qemuCaps) < 0)
-return -1;
-
 /* checks below should not be executed when starting a qemu process for a
  * VM that was running before (migration, snapshots, save). It's more
  * important to start such VM than keep the configuration clean */
@@ -5204,7 +5192,7 @@ qemuProcessStartValidate(virQEMUDriverPtr driver,
 
 }
 
-if (qemuProcessStartValidateXML(driver, vm, qemuCaps, caps, flags) < 0)
+if (qemuProcessStartValidateXML(driver, vm, caps, flags) < 0)
 return -1;
 
 if (qemuProcessStartValidateGraphics(vm) < 0)
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 5/5] qemu_process.c: removing qemuProcessStartValidateXML

2018-11-14 Thread Daniel Henrique Barboza

Commit ("qemu_domain.c: moving maxCpu validation to
qemuDomainDefValidate") shortened the code of qemuProcessStartValidateXML.
The function is called only by qemuProcessStartValidate, in the
same file, and its code is now a single check that calls virDomainDefValidate.

Instead of leaving a function call just to execute a single check,
this patch puts the check in the body of qemuProcessStartValidate in the
place where qemuProcessStartValidateXML was being called. The function can
now be removed.

Signed-off-by: Daniel Henrique Barboza 
---
 src/qemu/qemu_process.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 0d1dc7ed35..c9ef2050a1 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5114,23 +5114,6 @@ qemuProcessStartValidateDisks(virDomainObjPtr vm,
 }
 
 
-static int
-qemuProcessStartValidateXML(virQEMUDriverPtr driver,
-virDomainObjPtr vm,
-virCapsPtr caps,
-unsigned int flags)
-{
-/* checks below should not be executed when starting a qemu process for a
- * VM that was running before (migration, snapshots, save). It's more
- * important to start such VM than keep the configuration clean */
-if ((flags & VIR_QEMU_PROCESS_START_NEW) &&
-virDomainDefValidate(vm->def, caps, 0, driver->xmlopt) < 0)
-return -1;
-
-return 0;
-}
-
-
 /**
  * qemuProcessStartValidate:
  * @vm: domain object
@@ -5169,7 +5152,11 @@ qemuProcessStartValidate(virQEMUDriverPtr driver,
 
 }
 
-if (qemuProcessStartValidateXML(driver, vm, caps, flags) < 0)
+/* Checks below should not be executed when starting a qemu process for a
+ * VM that was running before (migration, snapshots, save). It's more
+ * important to start such VM than keep the configuration clean */
+if ((flags & VIR_QEMU_PROCESS_START_NEW) &&
+virDomainDefValidate(vm->def, caps, 0, driver->xmlopt) < 0)
 return -1;
 
 if (qemuProcessStartValidateGraphics(vm) < 0)
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 2/5] qemu_process.c: make qemuValidateCpuCount public

2018-11-14 Thread Daniel Henrique Barboza

qemuValidateCpuCount validates the maxCpus value of a domain at
startup time, preventing it to start if the value exceeds a maximum.

This checking is also done at qemu_domain.c, qemuDomainDefValidate.
However, it is done only for x86 (and even then, in a specific
scenario). We want this check to be done for all archs.

To accomplish this, let's first make qemuValidateCpuCount public so
it can be used inside qemuDomainDefValidate. The function was renamed
to qemuProcessValidateCpuCount to be compliant with the other public
methods at qemu_process.h. The method signature was slightly adapted
to fit the const 'def' variable used in qemuDomainDefValidate. This
change has no downside in in its original usage at
qemuProcessStartValidateXML.

Signed-off-by: Daniel Henrique Barboza 
---
 src/qemu/qemu_process.c | 8 
 src/qemu/qemu_process.h | 3 +++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 84a2163743..4d134bd7be 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3887,9 +3887,9 @@ qemuProcessSPICEAllocatePorts(virQEMUDriverPtr driver,
 }
 
 
-static int
-qemuValidateCpuCount(virDomainDefPtr def,
- virQEMUCapsPtr qemuCaps)
+int
+qemuProcessValidateCpuCount(const virDomainDef *def,
+virQEMUCapsPtr qemuCaps)
 {
 unsigned int maxCpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, 
def->os.machine);
 
@@ -5152,7 +5152,7 @@ qemuProcessStartValidateXML(virQEMUDriverPtr driver,
  * If back compat isn't a concern, XML validation should probably
  * be done at parse time.
  */
-if (qemuValidateCpuCount(vm->def, qemuCaps) < 0)
+if (qemuProcessValidateCpuCount(vm->def, qemuCaps) < 0)
 return -1;
 
 /* checks below should not be executed when starting a qemu process for a
diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h
index 2037467c94..d3b2baac51 100644
--- a/src/qemu/qemu_process.h
+++ b/src/qemu/qemu_process.h
@@ -47,6 +47,9 @@ int qemuProcessDestroyMemoryBackingPath(virQEMUDriverPtr 
driver,
 virDomainObjPtr vm,
 virDomainMemoryDefPtr mem);
 
+int qemuProcessValidateCpuCount(const virDomainDef *def,
+virQEMUCapsPtr qemuCaps);
+
 void qemuProcessReconnectAll(virQEMUDriverPtr driver);
 
 typedef struct _qemuProcessIncomingDef qemuProcessIncomingDef;
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 0/2] Adding partial support for LXC 3.0 rebased configs.

2018-11-14 Thread John Ferlan




On 11/14/18 12:25 PM, Julio Faracco wrote:
> This series adds enhacements for LXC to cover rebased config settings
> for version 3.0 without remove legacy ones. This serie includes some
> test cases to cover new config files too. The title mentions the word
> "partial" because there is a huge change with network settings which
> this commit does not cover.
> 
> History:
>   v1-v2: Michal's suggestions to handle differences between versions.
>   v2-v3: Adding suggestions from Pino and John too.
>   v3-v4: Appluing tests for LXC v3.
> 
> Julio Faracco (2):
>   lxc: Include support to lxc version 3.0 or higher.
>   tests: Adding tests cases to cover rebased settings for LXC 3.0.
> 
>  src/lxc/lxc_native.c  | 52 ++-
>  .../lxcconf2xml-blkiotune-v3.config   | 11 
>  .../lxcconf2xml-cpusettune-v3.config  |  6 +++
>  .../lxcconf2xml-cputune-v3.config |  7 +++
>  .../lxcconf2xml-ethernet-v3.config| 44 
>  .../lxcconf2xml-fstab-v3.config   | 37 +
>  .../lxcconf2xml-idmap-v3.config   |  5 ++
>  .../lxcconf2xml-macvlannetwork-v3.config  | 13 +
>  .../lxcconf2xml-memtune-v3.config | 10 
>  .../lxcconf2xml-nonenetwork-v3.config |  4 ++
>  .../lxcconf2xml-nonetwork-v3.config   |  3 ++
>  .../lxcconf2xml-physnetwork-v3.config | 11 
>  .../lxcconf2xml-simple-v3.config  | 45 
>  .../lxcconf2xml-vlannetwork-v3.config | 12 +
>  tests/lxcconf2xmltest.c   | 51 +-
>  15 files changed, 295 insertions(+), 16 deletions(-)
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-fstab-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork-v3.config
> 

Reviewed-by: John Ferlan 
(and pushed)

John

(now let's see if the various CI builders are happy too)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 4/5] qemu_process.c: moving qemuValidateCpuCount to qemu_domain.c

2018-11-14 Thread Daniel Henrique Barboza

Previous patch removed the call to qemuProcessValidateCpuCount
from qemuProcessStartValidateXML, in qemu_process.c. The only
caller left is qemuDomainDefValidate, in qemu_domain.c.

Instead of having a public function declared inside qemu_process.c
that isn't used in that file, this patch moves the function to
qemu_domain.c, making in static and renaming it to
qemuDomainValidateCpuCount to be compliant with other static
functions names in the file.

Signed-off-by: Daniel Henrique Barboza 
---
 src/qemu/qemu_domain.c  | 25 -
 src/qemu/qemu_process.c | 23 ---
 src/qemu/qemu_process.h |  3 ---
 3 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 3b86d28216..a0d69da646 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3990,6 +3990,29 @@ qemuDomainDefValidateMemory(const virDomainDef *def)
 }
 
 
+static int
+qemuDomainValidateCpuCount(const virDomainDef *def,
+virQEMUCapsPtr qemuCaps)
+{
+unsigned int maxCpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, 
def->os.machine);
+
+if (virDomainDefGetVcpus(def) == 0) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("Domain requires at least 1 vCPU"));
+return -1;
+}
+
+if (maxCpus > 0 && virDomainDefGetVcpusMax(def) > maxCpus) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("Maximum CPUs greater than specified machine "
+ "type limit %u"), maxCpus);
+return -1;
+}
+
+return 0;
+}
+
+
 static int
 qemuDomainDefValidate(const virDomainDef *def,
   virCapsPtr caps ATTRIBUTE_UNUSED,
@@ -4084,7 +4107,7 @@ qemuDomainDefValidate(const virDomainDef *def,
 }
 }
 
-if (qemuProcessValidateCpuCount(def, qemuCaps) < 0) {
+if (qemuDomainValidateCpuCount(def, qemuCaps) < 0) {
 goto cleanup;
 }
 
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 2adbf375ee..0d1dc7ed35 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3887,29 +3887,6 @@ qemuProcessSPICEAllocatePorts(virQEMUDriverPtr driver,
 }
 
 
-int
-qemuProcessValidateCpuCount(const virDomainDef *def,
-virQEMUCapsPtr qemuCaps)
-{
-unsigned int maxCpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, 
def->os.machine);
-
-if (virDomainDefGetVcpus(def) == 0) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("Domain requires at least 1 vCPU"));
-return -1;
-}
-
-if (maxCpus > 0 && virDomainDefGetVcpusMax(def) > maxCpus) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("Maximum CPUs greater than specified machine "
- "type limit %u"), maxCpus);
-return -1;
-}
-
-return 0;
-}
-
-
 static int
 qemuProcessVerifyHypervFeatures(virDomainDefPtr def,
 virCPUDataPtr cpu)
diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h
index d3b2baac51..2037467c94 100644
--- a/src/qemu/qemu_process.h
+++ b/src/qemu/qemu_process.h
@@ -47,9 +47,6 @@ int qemuProcessDestroyMemoryBackingPath(virQEMUDriverPtr 
driver,
 virDomainObjPtr vm,
 virDomainMemoryDefPtr mem);
 
-int qemuProcessValidateCpuCount(const virDomainDef *def,
-virQEMUCapsPtr qemuCaps);
-
 void qemuProcessReconnectAll(virQEMUDriverPtr driver);
 
 typedef struct _qemuProcessIncomingDef qemuProcessIncomingDef;
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 1/5] qemu_process.c: adding maxCpus value to error message

2018-11-14 Thread Daniel Henrique Barboza

Adding the maxCpus value in the error message of qemuValidateCpuCount
allows the user to set an acceptable maxCpus count without knowing
QEMU internals.

x86 guests, that might have been created prior to the x86
qemuDomainDefValidate maxCpus check code (that validates the maxCpus value
in editing time), will also benefit from this change.

Signed-off-by: Daniel Henrique Barboza 
---
 src/qemu/qemu_process.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 1850923914..84a2163743 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3900,8 +3900,9 @@ qemuValidateCpuCount(virDomainDefPtr def,
 }
 
 if (maxCpus > 0 && virDomainDefGetVcpusMax(def) > maxCpus) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("Maximum CPUs greater than specified machine type 
limit"));
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("Maximum CPUs greater than specified machine "
+ "type limit %u"), maxCpus);
 return -1;
 }
 
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 0/5] qemu_domain, qemu_process: maxCpus check to non-x86 guests

2018-11-14 Thread Daniel Henrique Barboza

v2:
- original patch was split in 3 patches as John Ferlan requested;
- patches 4 and 5 are cleanups;
- first patch link:
https://www.redhat.com/archives/libvir-list/2018-October/msg00251.html



Daniel Henrique Barboza (5):
  qemu_process.c: adding maxCpus value to error message
  qemu_process.c: make qemuValidateCpuCount public
  qemu_domain.c: moving maxCpu validation to qemuDomainDefValidate
  qemu_process.c: moving qemuValidateCpuCount to qemu_domain.c
  qemu_process.c: removing qemuProcessStartValidateXML

 src/qemu/qemu_domain.c  | 27 +++
 src/qemu/qemu_process.c | 57 -
 2 files changed, 32 insertions(+), 52 deletions(-)

-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC 0/3] Add mechanisms to force QEMU capabilities refetches

2018-11-14 Thread John Ferlan



On 11/14/18 4:25 AM, Daniel P. Berrangé wrote:
> On Tue, Nov 13, 2018 at 03:21:03PM -0500, John Ferlan wrote:
>> Sending as an RFC primarily because I'm looking for whether either
>> or both mechanisms in the series is more or less desired. Likewise,
>> if it's felt that the current process of telling customers to just
>> delete the cache is acceptible, then so be it. If there's other ideas
>> I'm willing to give them a go too. I did consider adding a virsh
>> option to "virsh capabilities" (still possible) and/or a virt-admin
>> option to force the refresh. These just were "easier" and didn't
>> require an API adjustment to implement.
>>
>> Patch1 is essentially a means to determine if the kernel config
>> was changed to allow nested virtualization and to force a refresh
>> of the capabilities in that case. Without doing so the CPU settings
>> for a guest may not add the vmx=on depending on configuration and
>> for the user that doesn't make sense. There is a private bz on this
>> so I won't bother posting it.
>>
>> Patch2 and Patch3 make use of the 'service libvirtd reload' function
>> in order to invalidate all the entries in the internal QEMU capabilities
>> hash table and then to force a reread. This perhaps has downsides related
>> to guest usage and previous means to use reload and not refresh if a guest
>> was running. On the other hand, we tell people to just clear the QEMU
>> capabilities cache (e.g. rm /var/cache/libvirt/qemu/capabilities/*.xml)
>> and restart libvirtd, so in essence, the same result. It's not clear
>> how frequently this is used (it's essentially a SIGHUP to libvirtd).
> 
> IMHO the fact that we cache stuff should be completely invisible outside
> of libvirt. Sure we've had some bugs in this area, but they are not very
> frequent so I'm not enthusiastic to expose any knob to force rebuild beyond
> just deleting files.
> 

OK - so that more or less obviates patch2 and patch3...

Of course the fact that we cache stuff hasn't been completely invisible
and telling someone to fix the problem by "simply" removing the cache
files and pointing them to the cache location seems a bit "awkward" once
you figure out that is the problem of course. Many times it's just not
intuitively obvious!

OTOH, baking in the idea that a "reload" could remove the chance that
caching was the problem could be useful. I guess it just felt like it
was a perhaps less used option. Assuming of course most would use
stop/start or restart instead.

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] util: Change usage of ent->d_type != DT_DIR

2018-11-14 Thread John Ferlan

Fix a broken non-Linux build to use the !virFileIsDir instead

Signed-off-by: John Ferlan 
---
 Pushed as build breaker fix for 

   https://travis-ci.org/libvirt/libvirt/builds/455121079

 All I can say is, well that wasn't obvious... Who knew!

 src/util/virresctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c
index f7481a1036..ef5c668921 100644
--- a/src/util/virresctrl.c
+++ b/src/util/virresctrl.c
@@ -2693,7 +2693,7 @@ virResctrlMonitorGetStats(virResctrlMonitorPtr monitor,
  * "mon_L3_01" are two target directories for a two nodes system
  * with resource utilization data file for each node respectively.
  */
-if (ent->d_type != DT_DIR)
+if (!virFileIsDir(ent->d_name))
 continue;
 
 /* Looking for directory has a prefix 'mon_L' */
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] util: Fix memory leak in virResctrlMonitorGetStats

2018-11-14 Thread John Ferlan

Missed during review and surprisingly my run through Coverity also
didn't see this. I only noticed it when reading the code while fixing
the build breaker for commit 36780a86a.

With all those continues we would leak @stats.

Signed-off-by: John Ferlan 
---
 Pushing under trivial rule.

 src/util/virresctrl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c
index ef5c668921..7aeca9d287 100644
--- a/src/util/virresctrl.c
+++ b/src/util/virresctrl.c
@@ -2684,9 +2684,6 @@ virResctrlMonitorGetStats(virResctrlMonitorPtr monitor,
 while (virDirRead(dirp, , datapath) > 0) {
 char *node_id = NULL;
 
-if (VIR_ALLOC(stat) < 0)
-goto cleanup;
-
 /* Looking for directory that contains resource utilization
  * information file. The directory name is arranged in format
  * "mon__". For example, "mon_L3_00" and
@@ -2709,6 +2706,9 @@ virResctrlMonitorGetStats(virResctrlMonitorPtr monitor,
 if (!(node_id = STRSKIP(node_id, "_")))
 continue;
 
+if (VIR_ALLOC(stat) < 0)
+goto cleanup;
+
 /* The node ID number should be here, parsing it. */
 if (virStrToLong_uip(node_id, NULL, 0, >id) < 0)
 goto cleanup;
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH] Add new migration flag VIR_MIGRATE_DRY_RUN

2018-11-14 Thread Jim Fehlig


On 11/13/18 3:29 AM, Daniel P. Berrangé wrote:

On Mon, Nov 12, 2018 at 11:33:04AM -0700, Jim Fehlig wrote:

On 11/12/18 4:26 AM, Daniel P. Berrangé wrote:

On Fri, Nov 02, 2018 at 04:34:02PM -0600, Jim Fehlig wrote:

A dry run can be used as a best-effort check that a migration command
will succeed. The destination host will be checked to see if it can
accommodate the resources required by the domain. DRY_RUN will fail if
the destination host is not capable of running the domain. Although a
subsequent migration will likely succeed, the success of DRY_RUN does not
ensure a future migration will succeed. Resources on the destination host
could become unavailable between a DRY_RUN and actual migration.


I'm not really convinced this is a particularly useful concept,
as it is only going to catch a very small number of the reasons
why migration can fail. So you still have to expect the real
migration invokation to have a strong chance of failing.


I agree it is difficult to reliably check that a migration will succeed.
TBH, I was expecting opposition due to libvirt already providing info for
applications to do the check themselves. E.g. as nova has done with
check_can_live_migrate_{source,destination} APIs.

Do you think libvirt provides enough information for an app to determine if
a VM can be migrated between two hosts? Or maybe better asked: What info is
currently missing for an app to reliably check if a VM can be migrated
between two hosts?


There's probably two classes of problem here

  - Things that would prevent the QEMU process being started.
  
* XML points to host resources that don't exist (block devices,

  files, nics, host devs, etc, NUMA/CPU pinning)

* Use of QEMU features that aren't supported by this QEMU version

* Insufficient free resources. Principally lack of RAM,
  both normal and huge pages.

These problems are not really anthing todo with live migration
as they impact normal guest startup to exactly the same degree.

Libvirt will already report on the first two problems during
its normal QEMU setup process. During live migration you'll
see these problems reported quite quickly in the prepare phase
before any data is sent.


Right. These are the ones that would be easy to detect with dry run, which I 
envisioned would terminate after the prepare phase.



Insufficient resources is really hard to report on with any
useful accuracy. We can't even predict reliably how much RAM
any given QEMU config will need, let alone measure whether
the host is able to provide that much. If you're lucky QEMU
may simply fail to start due to insufficient RAM/huge pages.
This would abort the live migration early on before much data
is sent.


Inability to predict qemu memory overhead is indeed unfortunate. E.g. SEV 
encrypted VMs must (at the moment) have all their memory regions locked: guest 
RAM, ROM(s), pflash, video RAM, and any qemu overhead. The last one is an 
"undecidable problem" (from libvirt docs) and makes it difficult to calculate a 
suitable value for /domain/memtune/hard_limit. If the value is too small the VM 
will fail to start.


nova also has a 'reserved_host_memory_mb' setting which should include the qemu 
overhead IMO. But the docs have no guidance on how to set that, likely because 
there is no known way to reliably calculate the overhead.



  - Things that interfere with the live migration operation

 * Firewall blocks libvirtd <-> libvirtd comms

 * Firewall blocks QEMU <-> QEMU comms

 * Storage copy is not requested and disks are not
   on shared storage


I think these could be successfully checked in dry run too.



 * Network connectivity won't seemlessly switch for
   guest NICs

 * Bugs in QEMU when loading device state causing
   failure

 * Bugs in libvirt not correctly configuring QEMU
   to ensure stable ABI

 * Live migration never converging


I've no illusions that these can be checked in dry run :-).



Some of these get seen quite quickly such as firewall
issues. Bugs in device state are only seen durnig the
main data transfer. Problems with storage/network
setup are only seen when the guest crashes & burns
after migration is complete & are hard to diagnose
earlier from libvirt's POV. Apps like nova can
diagnose this kind of thing better as they have a
higher level view of the storage/network connectivity
that libvirt can't see.

Live migration convergance is the real hard one
that causes alot of pain for people. Personally I
recommend that people use post-copy by defalt
to guarantee convergance in finite time, with
low impact on guest performance. There was an
interesting presentation at KVM Forum this year
about doing workload prediction for VMs to identify
which time/day has a workload that most friendly
towards convergance.


Ah, interesting. I've watched some of the

Re: [libvirt] [PATCH RFC 00/22] Move process code to qemu_process

2018-11-14 Thread Chris Venteicher

Quoting Michal Privoznik (2018-11-14 09:45:06)
> On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> > Make process code usable outside qemu_capabilities by moving code
> > from qemu_capabilities to qemu_process and exposing public functions.
> > 
> > The process code is used to activate a non domain QEMU process for QMP
> > message exchanges.
> > 
> > This patch set modifies capabilities to use the new public functions.
> > 
> > --
> > 
> > The process code is being decoupled from qemu_capabilities now to
> > support hypervisor baseline and comparison using QMP commands.
> > 
> > This patch set was originally submitted as part of the baseline patch set:
> >   [libvirt] [PATCH v4 00/37] BaselineHypervisorCPU using QEMU QMP exchanges
> >   https://www.redhat.com/archives/libvir-list/2018-November/msg00091.html
> 
> Okay, so you want to implement cpu-baseline for s390. But that doesn't
> really explain the code movement. Also, somehow the code movement makes
> the code bigger? I guess what I am saying is that I don't see much
> justification for these patches.
>

Here is the feedback from an earlier hypervisor baseline review that
resulted in this patch set.
https://www.redhat.com/archives/libvir-list/2018-July/msg00881.html

I think Jiri correctly identified capabilities, and now baseline and
comparison, are unrelated services that all independently need to start
a non-domain QEMU process for QMP messaging.

I am not sure, but it seems likely there could be other (S390...)
commands in the future that use QMP messages outside of a domain context
to get info or do work at the QEMU level.

All the baseline code I had in qemu_capabilities didn't make sense there
anymore once I moved the process code from qemu_capabilities to
qemu_process.

Here is the latest baseline patch set:
https://www.redhat.com/archives/libvir-list/2018-November/msg00091.html

In the latest baseline patch set, all the baseline code is in qemu_driver
and uses the process functions exposed now from qemu_process.

So as best I can tell there main choice is...

1) Leave process code in qemu_capabilities and make the 4 core
process functions (new, start, stop, free) and data strut public
so they can also be used by baseline and comparison from qemu_driver.

2) Move the process code from qemu_capabilities to qemu_process.
(this patch set) and expose the functions / data struct from
qemu_process.

In case 1 functions have the virQemuCaps prefix.
In case 2 functions have the qemuProcess prefix.

In either approach there are some changes needed to the process code to
decouple it from the capabilities code to support both capabilities and
baseline.

I did spend a few patches in this patch set breaking out the init,
process launch and monitor connection code into different static
functions in the style used elsewhere in qemu_process.  That could be
reversed if it doesn't add enough value if the decision is to move the
process code to qemu_process.

>
> >
> > The baseline and comparison requirements are described here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1511999
> > https://bugzilla.redhat.com/show_bug.cgi?id=1511996
> >
> >
> > I am extracting and resubmitting just the process changes as a stand
> > alone series to try to make review easier.
> >
> > The patch set shows capabilities using the public functions.
> > To see baseline using the public functions...
> > Look at the "qemu_driver:" patches at the end of
> > https://www.redhat.com/archives/libvir-list/2018-November/msg00091.html
> >
> > Also,
> > The "qemu_driver: Support feature expansion via QEMU when baselining cpu"
> > patch might be of particular interest because the same QEMU process is
> > used for both baseline and expansion using QMP commands.
> >
> > --
> >
> > Many patches were used to isolate code moves and name changes from other
> > actual implementation changes.
> >
> > The patches reuse the pattern of public qemuProcess{Start,Stop} functions
> > and internal static qemuProcess{Init,Launch,ConnectMonitor} functions
> > but adds a "Qmp" suffix to make them unique.
> >
> > A number of patches are about re-partitioning the code into static
> > functions for initialization, process launch and connection monitor
> > stuff.  This matches the established pattern in qemu_process and seemed
> > to make sense to do.
> >
> > For concurrency...
> > A thread safe library function creates a unique directory under libDir for 
> > each QEMU
> > process (for QMP messaging) to decouple processes in terms of sockets and
> > file system footprint.
> >
> > Every patch should compile independently if applied in sequence.
>
> Oh, but it doesn't. I'm running 'make -j10 all syntax-check check' and I
> am hitting compilation/syntax error occasionally.
> 
Yep.  My bad.

I thought I was careful about making and checking every patch... but
stuff got through.

At least one of the errors looks like a slip when I did a merge as part
of a rebase where I changed the patch order to make it easier to

[libvirt] [PATCH] rpc: Remove duplicate check from filter function return.

2018-11-14 Thread Julio Faracco

This is a simple removal of a duplicated check of the return of the
filter function. There is a nested conditional checking exactly the same
thing.

Signed-off-by: Julio Faracco 
---
 src/rpc/virnetserverclient.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/rpc/virnetserverclient.c b/src/rpc/virnetserverclient.c
index 97cf126f56..778cd1afc0 100644
--- a/src/rpc/virnetserverclient.c
+++ b/src/rpc/virnetserverclient.c
@@ -1288,8 +1288,7 @@ static virNetMessagePtr 
virNetServerClientDispatchRead(virNetServerClientPtr cli
 if (ret < 0) {
 virNetMessageFree(msg);
 msg = NULL;
-if (ret < 0)
-client->wantClose = true;
+client->wantClose = true;
 break;
 }
 if (ret > 0) {
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 3/5] qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
> Qemu 3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows

s/Qemu/QEMU/

Better than in v1 but not quite perfect yet ;)

[...]
> +  
> +
> +  qemu: Add Hyper-V PV IPI support
> +
> +
> +  The QEMU driver now has support for Hyper-V PV IPI enlightenment
> +  for Windows guests.
> +
> +  

Okay, not your fault at all, just something that I failed to
communicate properly: updates to the release notes are supposed to
always go in their own commit. The rationale for that is making it
easy for downstreams to cherry-pick the code changes without having
to worry about conflicts in the documentation.

Additionally, and again I'm at fault for not communicating it
adequately, I kinda expected to have a single entry in the release
notes covering both changes. Does that sound reasonable?

Since everything else looks good and I'd rather not have you go
through more trouble than you already have, if you're okay with it
I can just drop this hunk from the patch, slap a

  Reviewed-by: Andrea Bolognani 

on it and push it; you can then re-post the release note update
as a separate follow up patch. Let me know if that works for you.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 5/5] qemu: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
> Qemu 3.1 supports Hyper-V Enlightened VMCS feature which significantly

s/Qemu/QEMU/

[...]
> +  
> +
> +  qemu: Add Hyper-V Enlightened VMCS support
> +
> +
> +  The QEMU driver now has support for Hyper-V Enlightened VMCS
> +  enlightenment for Hyper-V guests.
> +
> +  

Assuming you're okay with this hunk being dropped as suggested in
my reply to 3/5, then

  Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 4/5] conf: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
> Support Hyper-V Enlightened VMCS in domain config. Qemu support will

s/Qemu/QEMU/

With that fixed,

  Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: Using virStringListFreeCount instead VIR_FREE to free tmpPaths.

2018-11-14 Thread Julio Faracco

The function qemuDomainGetHostdevPath() is using VIR_FREE to free the
paths stored in tmpPaths. Both syntax analyzer are reporting a warning
about this. Replacing the old method to function
virStringListFreeCount() fixes the warnings/errors.

Signed-off-by: Julio Faracco 
---
 src/qemu/qemu_domain.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 37926850b2..c374219aab 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -11132,9 +11132,7 @@ qemuDomainGetHostdevPath(virDomainDefPtr def,
 }
 ret = 0;
  cleanup:
-for (i = 0; i < tmpNpaths; i++)
-VIR_FREE(tmpPaths[i]);
-VIR_FREE(tmpPaths);
+virStringListFreeCount(tmpPaths, tmpNpaths);
 VIR_FREE(tmpPerms);
 virPCIDeviceFree(pci);
 virUSBDeviceFree(usb);
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 2/2] tests: Adding tests cases to cover rebased settings for LXC 3.0.

2018-11-14 Thread Julio Faracco

Do you have any other suggestion for this?

I tried to keep it as simple as possible. Without creating new XML files for V3.

--
Julio Cesar Faracco

Em qua, 14 de nov de 2018 às 15:26, Julio Faracco
 escreveu:
>
> This commit includes new test cases to cover LXC version 3.0 and higher.
> This LXC version rebased some settings entries and deprecated other ones.
> As we support both, we should include tests to minimize problems with
> integration between them.
>
> Signed-off-by: Julio Faracco 
> ---
>  .../lxcconf2xml-blkiotune-v3.config   | 11 
>  .../lxcconf2xml-cpusettune-v3.config  |  6 +++
>  .../lxcconf2xml-cputune-v3.config |  7 +++
>  .../lxcconf2xml-ethernet-v3.config| 44 
>  .../lxcconf2xml-fstab-v3.config   | 37 ++
>  .../lxcconf2xml-idmap-v3.config   |  5 ++
>  .../lxcconf2xml-macvlannetwork-v3.config  | 13 +
>  .../lxcconf2xml-memtune-v3.config | 10 
>  .../lxcconf2xml-nonenetwork-v3.config |  4 ++
>  .../lxcconf2xml-nonetwork-v3.config   |  3 ++
>  .../lxcconf2xml-physnetwork-v3.config | 11 
>  .../lxcconf2xml-simple-v3.config  | 45 
>  .../lxcconf2xml-vlannetwork-v3.config | 12 +
>  tests/lxcconf2xmltest.c   | 51 ++-
>  14 files changed, 257 insertions(+), 2 deletions(-)
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-fstab-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple-v3.config
>  create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork-v3.config
>
> diff --git a/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config 
> b/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
> new file mode 100644
> index 00..6d82ac74eb
> --- /dev/null
> +++ b/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
> @@ -0,0 +1,11 @@
> +lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
> +lxc.uts.name = migrate_test
> +lxc.autodev=1
> +
> +lxc.cgroup.blkio.weight = 500
> +lxc.cgroup.blkio.device_weight = 8:16  1000
> +lxc.cgroup.blkio.device_weight = 8:0300
> +lxc.cgroup.blkio.throttle.read_bps_device = 8:16 1234
> +lxc.cgroup.blkio.throttle.write_bps_device = 8:16 5678
> +lxc.cgroup.blkio.throttle.read_iops_device = 8:16 4321
> +lxc.cgroup.blkio.throttle.write_iops_device = 8:16 8765
> diff --git a/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config 
> b/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
> new file mode 100644
> index 00..248874b198
> --- /dev/null
> +++ b/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
> @@ -0,0 +1,6 @@
> +lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
> +lxc.uts.name = migrate_test
> +lxc.autodev=1
> +
> +lxc.cgroup.cpuset.cpus = 1,2,5-7
> +lxc.cgroup.cpuset.mems = 1-4
> diff --git a/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config 
> b/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
> new file mode 100644
> index 00..bd2da94ec2
> --- /dev/null
> +++ b/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
> @@ -0,0 +1,7 @@
> +lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
> +lxc.uts.name = migrate_test
> +lxc.autodev=1
> +
> +lxc.cgroup.cpu.shares = 1024
> +lxc.cgroup.cpu.cfs_quota_us = -1
> +lxc.cgroup.cpu.cfs_period_us = 50
> diff --git a/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config 
> b/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
> new file mode 100644
> index 00..630cb2ebb6
> --- /dev/null
> +++ b/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
> @@ -0,0 +1,44 @@
> +# Template used to create this container: opensuse
> +# Template script checksum (SHA-1): 27307e0a95bd81b2c0bd82d6f87fdbe83be075ef
> +
> +lxc.network.type = veth
> +lxc.network.flags = up
> +lxc.network.hwaddr = 02:00:15:8f:05:c1
> +lxc.network.name = eth0
> +lxc.network.ipv4 = 192.168.122.2/24
> +lxc.network.ipv4.gateway = 192.168.122.1
> +lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596/64
> +lxc.network.ipv6.gateway = 2003:db8:1:0:214:1234:fe0b:3595
> +
> +#remove next line if host DNS configuration should not be available to 
> container
> +lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
>

[libvirt] [PATCH v4 1/2] lxc: Include support to lxc version 3.0 or higher.

2018-11-14 Thread Julio Faracco

This patch introduce the new settings for LXC 3.0 or higher. The older
versions keep the compatibility to deprecated settings for LXC, but
after release 3.0, the compatibility was removed. This commit adds the
support to the refactored settings.

v1-v2: Michal's suggestions to handle differences between versions.
v2-v3: Adding suggestions from Pino and John too.
v3-v4: Appluing tests for LXC v3.

Signed-off-by: Julio Faracco 
---
 src/lxc/lxc_native.c | 52 
 1 file changed, 38 insertions(+), 14 deletions(-)

diff --git a/src/lxc/lxc_native.c b/src/lxc/lxc_native.c
index cbdec723dd..9f6d4b3de8 100644
--- a/src/lxc/lxc_native.c
+++ b/src/lxc/lxc_native.c
@@ -200,8 +200,13 @@ lxcSetRootfs(virDomainDefPtr def,
 int type = VIR_DOMAIN_FS_TYPE_MOUNT;
 VIR_AUTOFREE(char *) value = NULL;
 
-if (virConfGetValueString(properties, "lxc.rootfs", ) <= 0)
-return -1;
+if (virConfGetValueString(properties, "lxc.rootfs.path", ) <= 0) {
+virResetLastError();
+
+/* Check for pre LXC 3.0 legacy key */
+if (virConfGetValueString(properties, "lxc.rootfs", ) <= 0)
+return -1;
+}
 
 if (STRPREFIX(value, "/dev/"))
 type = VIR_DOMAIN_FS_TYPE_BLOCK;
@@ -684,8 +689,13 @@ lxcCreateConsoles(virDomainDefPtr def, virConfPtr 
properties)
 virDomainChrDefPtr console;
 size_t i;
 
-if (virConfGetValueString(properties, "lxc.tty", ) <= 0)
-return 0;
+if (virConfGetValueString(properties, "lxc.tty.max", ) <= 0) {
+virResetLastError();
+
+/* Check for pre LXC 3.0 legacy key */
+if (virConfGetValueString(properties, "lxc.tty", ) <= 0)
+return 0;
+}
 
 if (virStrToLong_i(value, NULL, 10, ) < 0) {
 virReportError(VIR_ERR_INTERNAL_ERROR, _("failed to parse int: '%s'"),
@@ -724,13 +734,16 @@ lxcIdmapWalkCallback(const char *name, virConfValuePtr 
value, void *data)
 char type;
 unsigned long start, target, count;
 
-if (STRNEQ(name, "lxc.id_map") || !value->str)
-return 0;
+/* LXC 3.0 uses "lxc.idmap", while legacy used "lxc.id_map" */
+if (STRNEQ(name, "lxc.idmap") || !value->str) {
+if (!value->str || STRNEQ(name, "lxc.id_map"))
+return 0;
+}
 
 if (sscanf(value->str, "%c %lu %lu %lu", ,
, , ) != 4) {
-virReportError(VIR_ERR_INTERNAL_ERROR, _("invalid lxc.id_map: '%s'"),
-   value->str);
+virReportError(VIR_ERR_INTERNAL_ERROR, _("invalid %s: '%s'"),
+   name, value->str);
 return -1;
 }
 
@@ -1041,19 +1054,30 @@ lxcParseConfigString(const char *config,
 if (VIR_STRDUP(vmdef->os.init, "/sbin/init") < 0)
 goto error;
 
-if (virConfGetValueString(properties, "lxc.utsname", ) <= 0 ||
-VIR_STRDUP(vmdef->name, value) < 0)
+if (virConfGetValueString(properties, "lxc.uts.name", ) <= 0) {
+virResetLastError();
+
+/* Check for pre LXC 3.0 legacy key */
+if (virConfGetValueString(properties, "lxc.utsname", ) <= 0)
+goto error;
+}
+
+if (VIR_STRDUP(vmdef->name, value) < 0)
 goto error;
+
 if (!vmdef->name && (VIR_STRDUP(vmdef->name, "unnamed") < 0))
 goto error;
 
 if (lxcSetRootfs(vmdef, properties) < 0)
 goto error;
 
-/* Look for fstab: we shouldn't have it */
-if (virConfGetValue(properties, "lxc.mount")) {
+/* LXC 3.0 uses "lxc.mount.fstab", while legacy used just "lxc.mount".
+ * In either case, generate the error to use "lxc.mount.entry" instead */
+if (virConfGetValue(properties, "lxc.mount.fstab") ||
+virConfGetValue(properties, "lxc.mount")) {
 virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
-   _("lxc.mount found, use lxc.mount.entry lines 
instead"));
+   _("lxc.mount.fstab or lxc.mount found, use "
+ "lxc.mount.entry lines instead"));
 goto error;
 }
 
@@ -1069,7 +1093,7 @@ lxcParseConfigString(const char *config,
 if (lxcCreateConsoles(vmdef, properties) < 0)
 goto error;
 
-/* lxc.id_map */
+/* lxc.idmap or legacy lxc.id_map */
 if (virConfWalk(properties, lxcIdmapWalkCallback, vmdef) < 0)
 goto error;
 
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 2/2] tests: Adding tests cases to cover rebased settings for LXC 3.0.

2018-11-14 Thread Julio Faracco

This commit includes new test cases to cover LXC version 3.0 and higher.
This LXC version rebased some settings entries and deprecated other ones.
As we support both, we should include tests to minimize problems with
integration between them.

Signed-off-by: Julio Faracco 
---
 .../lxcconf2xml-blkiotune-v3.config   | 11 
 .../lxcconf2xml-cpusettune-v3.config  |  6 +++
 .../lxcconf2xml-cputune-v3.config |  7 +++
 .../lxcconf2xml-ethernet-v3.config| 44 
 .../lxcconf2xml-fstab-v3.config   | 37 ++
 .../lxcconf2xml-idmap-v3.config   |  5 ++
 .../lxcconf2xml-macvlannetwork-v3.config  | 13 +
 .../lxcconf2xml-memtune-v3.config | 10 
 .../lxcconf2xml-nonenetwork-v3.config |  4 ++
 .../lxcconf2xml-nonetwork-v3.config   |  3 ++
 .../lxcconf2xml-physnetwork-v3.config | 11 
 .../lxcconf2xml-simple-v3.config  | 45 
 .../lxcconf2xml-vlannetwork-v3.config | 12 +
 tests/lxcconf2xmltest.c   | 51 ++-
 14 files changed, 257 insertions(+), 2 deletions(-)
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-fstab-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork-v3.config

diff --git a/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config 
b/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
new file mode 100644
index 00..6d82ac74eb
--- /dev/null
+++ b/tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
@@ -0,0 +1,11 @@
+lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
+lxc.uts.name = migrate_test
+lxc.autodev=1
+
+lxc.cgroup.blkio.weight = 500
+lxc.cgroup.blkio.device_weight = 8:16  1000
+lxc.cgroup.blkio.device_weight = 8:0300
+lxc.cgroup.blkio.throttle.read_bps_device = 8:16 1234
+lxc.cgroup.blkio.throttle.write_bps_device = 8:16 5678
+lxc.cgroup.blkio.throttle.read_iops_device = 8:16 4321
+lxc.cgroup.blkio.throttle.write_iops_device = 8:16 8765
diff --git a/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config 
b/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
new file mode 100644
index 00..248874b198
--- /dev/null
+++ b/tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
@@ -0,0 +1,6 @@
+lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
+lxc.uts.name = migrate_test
+lxc.autodev=1
+
+lxc.cgroup.cpuset.cpus = 1,2,5-7
+lxc.cgroup.cpuset.mems = 1-4
diff --git a/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config 
b/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
new file mode 100644
index 00..bd2da94ec2
--- /dev/null
+++ b/tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
@@ -0,0 +1,7 @@
+lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
+lxc.uts.name = migrate_test
+lxc.autodev=1
+
+lxc.cgroup.cpu.shares = 1024
+lxc.cgroup.cpu.cfs_quota_us = -1
+lxc.cgroup.cpu.cfs_period_us = 50
diff --git a/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config 
b/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
new file mode 100644
index 00..630cb2ebb6
--- /dev/null
+++ b/tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
@@ -0,0 +1,44 @@
+# Template used to create this container: opensuse
+# Template script checksum (SHA-1): 27307e0a95bd81b2c0bd82d6f87fdbe83be075ef
+
+lxc.network.type = veth
+lxc.network.flags = up
+lxc.network.hwaddr = 02:00:15:8f:05:c1
+lxc.network.name = eth0
+lxc.network.ipv4 = 192.168.122.2/24
+lxc.network.ipv4.gateway = 192.168.122.1
+lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596/64
+lxc.network.ipv6.gateway = 2003:db8:1:0:214:1234:fe0b:3595
+
+#remove next line if host DNS configuration should not be available to 
container
+lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
+lxc.mount.entry = sysfs sys sysfs defaults  0 0
+lxc.mount.entry = tmpfs run tmpfs size=8m,mode=0755,nodev,nosuid 0 0
+lxc.mount.entry = /etc/resolv.conf etc/resolv.conf none bind,ro 0 0
+lxc.rootfs.path = /var/lib/lxc/migrate_test/rootfs
+lxc.uts.name = migrate_test
+lxc.arch = x86
+lxc.autodev=1
+lxc.tty.max = 2
+lxc.pts = 1024
+lxc.cap.drop = sys_module mac_admin mac_override mknod
+
+# When using LXC with apparmor,

[libvirt] [PATCH v4 0/2] Adding partial support for LXC 3.0 rebased configs.

2018-11-14 Thread Julio Faracco

This series adds enhacements for LXC to cover rebased config settings
for version 3.0 without remove legacy ones. This serie includes some
test cases to cover new config files too. The title mentions the word
"partial" because there is a huge change with network settings which
this commit does not cover.

History:
  v1-v2: Michal's suggestions to handle differences between versions.
  v2-v3: Adding suggestions from Pino and John too.
  v3-v4: Appluing tests for LXC v3.

Julio Faracco (2):
  lxc: Include support to lxc version 3.0 or higher.
  tests: Adding tests cases to cover rebased settings for LXC 3.0.

 src/lxc/lxc_native.c  | 52 ++-
 .../lxcconf2xml-blkiotune-v3.config   | 11 
 .../lxcconf2xml-cpusettune-v3.config  |  6 +++
 .../lxcconf2xml-cputune-v3.config |  7 +++
 .../lxcconf2xml-ethernet-v3.config| 44 
 .../lxcconf2xml-fstab-v3.config   | 37 +
 .../lxcconf2xml-idmap-v3.config   |  5 ++
 .../lxcconf2xml-macvlannetwork-v3.config  | 13 +
 .../lxcconf2xml-memtune-v3.config | 10 
 .../lxcconf2xml-nonenetwork-v3.config |  4 ++
 .../lxcconf2xml-nonetwork-v3.config   |  3 ++
 .../lxcconf2xml-physnetwork-v3.config | 11 
 .../lxcconf2xml-simple-v3.config  | 45 
 .../lxcconf2xml-vlannetwork-v3.config | 12 +
 tests/lxcconf2xmltest.c   | 51 +-
 15 files changed, 295 insertions(+), 16 deletions(-)
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-ethernet-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-fstab-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple-v3.config
 create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork-v3.config

-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 1/5] docs: remove extra whitespate from Hyper-V enlightenments options

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
> Remove redundant leading whitespaces from " on, off".

In the subject: s/whitespate/whitespace/

With that fixed,

  Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 2/5] conf: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 17:27 +0100, Vitaly Kuznetsov wrote:
> Support Hyper-V PV IPI enlightenment in domain config. Qemu support will

s/Qemu/QEMU/

> be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI cases
> to src/qemu/* for now.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  docs/formatdomain.html.in | 7 +++
>  docs/schemas/domaincommon.rng | 5 +
>  src/conf/domain_conf.c| 7 ++-
>  src/conf/domain_conf.h| 1 +
>  src/cpu/cpu_x86.c | 3 +++
>  src/cpu/cpu_x86_data.h| 1 +
>  src/qemu/qemu_command.c   | 1 +
>  src/qemu/qemu_parse_command.c | 1 +
>  src/qemu/qemu_process.c   | 1 +
>  9 files changed, 26 insertions(+), 1 deletion(-)

So, personally I don't feel like splitting the patch into two really
improves the situation - actually the opposite, since now as you
mention in the commit message you have to go out of your way to add
placeholders only to remove them in the next commit.

But it's really not a big deal either way, so you can leave it as-is
and, with the commit message fixed, still get a

  Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-go PATCH] Add daemon shutdown reason to the list

2018-11-14 Thread John Ferlan

Signed-off-by: John Ferlan 
---
 Something I know even less about ;-)... Although I see Daniel has noted
 he'll take care of it - I figured I'd give it a "go" (sorry) anyway.

 domain.go | 1 +
 1 file changed, 1 insertion(+)

diff --git a/domain.go b/domain.go
index 3a3ef5b..e011980 100644
--- a/domain.go
+++ b/domain.go
@@ -593,6 +593,7 @@ const (
DOMAIN_SHUTOFF_SAVED = 
DomainShutoffReason(C.VIR_DOMAIN_SHUTOFF_SAVED)
DOMAIN_SHUTOFF_FAILED= 
DomainShutoffReason(C.VIR_DOMAIN_SHUTOFF_FAILED)
DOMAIN_SHUTOFF_FROM_SNAPSHOT = 
DomainShutoffReason(C.VIR_DOMAIN_SHUTOFF_FROM_SNAPSHOT)
+   DOMAIN_SHUTOFF_DAEMON= 
DomainShutoffReason(C.VIR_DOMAIN_SHUTOFF_DAEMON)
 )
 
 type DomainBlockCommitFlags int
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC 10/22] qemu_process: Introduce qemuProcessStartQmp

2018-11-14 Thread Chris Venteicher

Quoting Michal Privoznik (2018-11-14 09:45:07)
> On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> > Move a step closer to the function structure used elsewhere in
> > qemu_process where qemuProcessStart and qemuProcessStop are the exposed
> > functions.
> > 
> > qemuProcessStartQmp mirrors qemuProcessStart in calling sub functions to
> > intialize, launch the process and connect the monitor to the QEMU
> > process.
> > 
> > static functions qemuProcessInitQmp, qemuProcessLaunchQmp and
> > qemuConnectMonitorQmp are also introduced.
> > 
> > qemuProcessLaunchQmp is just renamed from qemuProcessRun and
> > encapsulates all of the original code.
> > 
> > qemuProcessInitQmp and qemuProcessMonitorQmp are introduced as empty
> > wrappers into which subsequent patches will partition code from
> > qemuProcessLaunchQmp.
> > 
> > Signed-off-by: Chris Venteicher 
> > ---
> >  src/qemu/qemu_capabilities.c |  4 +-
> >  src/qemu/qemu_process.c  | 96 +++-
> >  src/qemu/qemu_process.h  |  2 +-
> >  3 files changed, 97 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > index fbb4336201..7168c470f6 100644
> > --- a/src/qemu/qemu_capabilities.c
> > +++ b/src/qemu/qemu_capabilities.c
> > @@ -4230,7 +4230,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
> >  goto cleanup;
> >  
> >  
> > -if (qemuProcessRun(proc) < 0)
> > +if (qemuProcessStartQmp(proc) < 0)
> >  goto cleanup;
> >  
> >  if (!(mon = QEMU_PROCESS_MONITOR(proc))) {
> > @@ -4249,7 +4249,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
> >  forceTCG = true;
> >  proc_kvm = qemuProcessNew(qemuCaps->binary, libDir, runUid, 
> > runGid, forceTCG);
> >  
> > -if (qemuProcessRun(proc_kvm) < 0)
> > +if (qemuProcessStartQmp(proc_kvm) < 0)
> >  goto cleanup;
> >  
> >  if (!(mon_kvm = QEMU_PROCESS_MONITOR(proc_kvm))) {
> > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> > index 2640ec2b32..b6aa3a9af3 100644
> > --- a/src/qemu/qemu_process.c
> > +++ b/src/qemu/qemu_process.c
> > @@ -8148,8 +8148,29 @@ qemuProcessNew(const char *binary,
> >  }
> >  
> >  
> > -int
> > -qemuProcessRun(qemuProcessPtr proc){
> > +/* Initialize configuration and paths prior to starting QEMU
> > + */
> > +static int
> > +qemuProcessInitQmp(qemuProcessPtr proc)
> > +{
> > +int ret = -1;
> > +
> > +VIR_DEBUG("Beginning VM startup process"
> > +  "emulator=%s",
> > +  proc->binary);
> > +
> > +ret = 0;
> > +
> > +VIR_DEBUG("ret=%i", ret);
> > +return ret;
> > +}
> > +
> 
> I am sorry, but I'm failing to see the purpose of this function.
> 
> > +
> > +/* Launch QEMU Process
> > + */
> > +static int
> > +qemuProcessLaunchQmp(qemuProcessPtr proc)
> > +{
> >  virDomainXMLOptionPtr xmlopt = NULL;
> >  const char *machine;
> >  int status = 0;
> > @@ -8226,6 +8247,77 @@ qemuProcessRun(qemuProcessPtr proc){
> >  }
> >  
> >  
> > +/* Connect Monitor to QEMU Process
> > + */
> > +static int
> > +qemuConnectMonitorQmp(qemuProcessPtr proc)
> > +{
> > +int ret = -1;
> > +
> > +VIR_DEBUG("proc=%p, emulator=%s, proc->pid=%lld",
> > +  proc, NULLSTR(proc->binary), (long long) proc->pid);
> > +
> > +ret = 0;
> > +
> > +VIR_DEBUG("ret=%i", ret);
> > +return ret;
> > +}
> 
> Or this function. Looking into next patches I can see that you're
> extending them. Well, I still think it's not worth introducing empty
> functions, just do the rename as you're doing in next patches.

Yep, I was trying to make it easier to review but didn't explain well
enough from the start. Sorry I wasn't clear.

Patch 10 (this patch) and 12 are about making it possible to do simple
cut/paste moves on semi-complicated blocks of original code moved
within patches 11 and 13.

The goal was to make patches 11 and 13 easy to review because
I don't actually change the code.  It's just moved.

If this seems good with the better explanation I can just try to make
that clear in the commit message for patch 10 and 12.

If it's more confusing this way I can start out with qemuProcesStartQmp
only calling qemuProcessLaunchQmp and the add qemuProcessInitQmp and
qemuConnectMonitorQmp as individual commits with full contents and just
explain that the guts are cut/paste moves with no changes in the commit
message.

Please let me know which approach you think is best.
>
> > +
> > +
> > +/**
> > + * qemuProcessStartQmp:
> > + * @proc: Stores Process and Connection State
> > + *
> > + * Start and connect to QEMU binary so QMP queries can be made.
> > + *
> > + * Usage:
> > + *   proc = qemuProcessNew(binary, forceTCG, libDir, runUid, runGid);
> > + *   qemuProcessStartQmp(proc);
> > + *   mon = QEMU_PROCESS_MONITOR(proc);
> > + *   ** Send QMP Queries to QEMU using monitor **
> > + *   qemuProcessStopQmp(proc);
> > + *   qemuProcessFree(proc);
> > + *
> > + * Check monitor is

[libvirt] [libvirt-perl PATCH] Add daemon to list of shutdown reasons

2018-11-14 Thread John Ferlan

Add the support to work with libvirt commit 66a85cb13.

Signed-off-by: John Ferlan 
---
 Although it's a build breaker and this does fix the problem - I'll wait
 to push just to make sure the text used for the message passes muster.

 Changes| 2 +-
 lib/Sys/Virt.xs| 1 +
 lib/Sys/Virt/Domain.pm | 4 
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Changes b/Changes
index b85ac91..11eb906 100644
--- a/Changes
+++ b/Changes
@@ -2,7 +2,7 @@ Revision history for perl module Sys::Virt
 
 4.10.0 2018-00-00
 
- - XXX
+ - Add new domain shutdown reason
 
 4.8.0 2018-10-05
 
diff --git a/lib/Sys/Virt.xs b/lib/Sys/Virt.xs
index d27dd74..3398971 100644
--- a/lib/Sys/Virt.xs
+++ b/lib/Sys/Virt.xs
@@ -8717,6 +8717,7 @@ BOOT:
   REGISTER_CONSTANT(VIR_DOMAIN_SHUTOFF_SAVED, STATE_SHUTOFF_SAVED);
   REGISTER_CONSTANT(VIR_DOMAIN_SHUTOFF_FAILED, STATE_SHUTOFF_FAILED);
   REGISTER_CONSTANT(VIR_DOMAIN_SHUTOFF_FROM_SNAPSHOT, 
STATE_SHUTOFF_FROM_SNAPSHOT);
+  REGISTER_CONSTANT(VIR_DOMAIN_SHUTOFF_DAEMON, STATE_SHUTOFF_DAEMON);
 
   REGISTER_CONSTANT(VIR_DOMAIN_CRASHED_UNKNOWN, STATE_CRASHED_UNKNOWN);
   REGISTER_CONSTANT(VIR_DOMAIN_CRASHED_PANICKED, STATE_CRASHED_PANICKED);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index 481b4b5..afaf71c 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -438,6 +438,10 @@ The guest is shutdown due to admin request
 
 The guest is shutoff after a crash
 
+=item Sys::Virt::Domain::STATE_SHUTOFF_DAEMON
+
+The guest is shutoff during restart after reconnect due to daemon issue
+
 =item Sys::Virt::Domain::STATE_SHUTOFF_DESTROYED
 
 The guest is shutoff after being destroyed
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/3] Fix some errors around VIR_ACCESS_DENIED

2018-11-14 Thread Michal Privoznik

On 11/12/2018 02:50 PM, John Ferlan wrote:
> v1: https://www.redhat.com/archives/libvir-list/2018-November/msg00339.html
> 
> Changes since v1:
> 
>  * Do the right thing, revert the bad patch and rework it. Thus patch1 is
>the revert and patch2 is the rework.  If it's decided that patch2 is
>unnecessary or undesired, that's perfectly fine, but would then require
>a slight modification to the documentation from commit 4f1107614 to
>remove the reference about the access denied message.
> 
>  * From review - add the virObjectUnref for the data->identity for which
>a virIdentityGetCurrent reference was obtained.
> 
> v1 cover:
> 
> Patch 1 fixes my own error made in this release fortunately, but
> only seen because I was invesigating Patch 2
> 
> Patch 2 is perhaps a longer term issue, but perhaps coming more to
> light now that the nwfilter bindings have been separated and use
> a virConnectOpen for nwfilter:///system during reconnection processing;
> whereas, previously the filter bindings would have been "hidden" within
> various nwfilter, domain, and network driver callbacks and throughs.
> 
> John Ferlan (3):
>   Revert "access: Modify the VIR_ERR_ACCESS_DENIED to include
> driverName"
>   access: Modify the VIR_ERR_ACCESS_DENIED to include driverName
>   qemu: Set identity for the reconnect all thread
> 
>  src/access/viraccessmanager.c | 3 ++-
>  src/qemu/qemu_process.c   | 7 +++
>  src/rpc/gendispatch.pl| 3 ++-
>  src/util/virerror.c   | 4 ++--
>  4 files changed, 13 insertions(+), 4 deletions(-)
> 


ACK

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 4/5] conf: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Vitaly Kuznetsov

Support Hyper-V Enlightened VMCS in domain config. Qemu support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_EVMCS
cases to src/qemu/* for now.

Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 7 +++
 docs/schemas/domaincommon.rng | 5 +
 src/conf/domain_conf.c| 4 
 src/conf/domain_conf.h| 1 +
 src/cpu/cpu_x86.c | 3 +++
 src/cpu/cpu_x86_data.h| 1 +
 src/qemu/qemu_command.c   | 1 +
 src/qemu/qemu_parse_command.c | 1 +
 src/qemu/qemu_process.c   | 1 +
 9 files changed, 24 insertions(+)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 7592f13a84..1b1518f465 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1982,6 +1982,7 @@
 reenlightenment state='on'/
 tlbflush state='on'/
 ipi state='on'/
+evmcs state='on'/
   /hyperv
   kvm
 hidden state='on'/
@@ -2128,6 +2129,12 @@
   on, off
   4.10.0 (QEMU 3.1)
 
+
+  evmcs
+  Enable Enlightened VMCS
+  on, off
+  4.10.0 (QEMU 3.1)
+
   
   
   pvspinlock
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 26019b3279..ff57ce1015 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -5774,6 +5774,11 @@
 
   
 
+
+  
+
+  
+
   
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 24876994c5..18d235872f 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -174,6 +174,7 @@ VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
   "reenlightenment",
   "tlbflush",
   "ipi",
+  "evmcs",
 );
 
 VIR_ENUM_IMPL(virDomainKVM, VIR_DOMAIN_KVM_LAST,
@@ -19993,6 +19994,7 @@ virDomainDefParseXML(xmlDocPtr xml,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
@@ -22188,6 +22190,7 @@ virDomainDefFeaturesCheckABIStability(virDomainDefPtr 
src,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (src->hyperv_features[i] != dst->hyperv_features[i]) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("State of HyperV enlightenment "
@@ -27953,6 +27956,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 9eea75548d..061185e779 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1796,6 +1796,7 @@ typedef enum {
 VIR_DOMAIN_HYPERV_REENLIGHTENMENT,
 VIR_DOMAIN_HYPERV_TLBFLUSH,
 VIR_DOMAIN_HYPERV_IPI,
+VIR_DOMAIN_HYPERV_EVMCS,
 
 VIR_DOMAIN_HYPERV_LAST
 } virDomainHyperv;
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 33252e927e..ebfa74fccd 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -116,6 +116,8 @@ KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_TLBFLUSH,
 0x4004, 0x0004);
 KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_IPI,
 0x4004, 0x0400);
+KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_EVMCS,
+0x4004, 0x4000);
 
 static virCPUx86Feature x86_kvm_features[] =
 {
@@ -140,6 +142,7 @@ static virCPUx86Feature x86_kvm_features[] =
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_TLBFLUSH),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_IPI),
+KVM_FEATURE(VIR_CPU_x86_KVM_HV_EVMCS),
 };
 
 typedef struct _virCPUx86Model virCPUx86Model;
diff --git a/src/cpu/cpu_x86_data.h b/src/cpu/cpu_x86_data.h
index 8c51d88e1a..f52bba821f 100644
--- a/src/cpu/cpu_x86_data.h
+++ b/src/cpu/cpu_x86_data.h
@@ -66,6 +66,7 @@ struct _virCPUx86CPUID {
 # define VIR_CPU_x86_KVM_HV_REENLIGHTENMENT "__kvm_hv_reenlightenment"
 # define VIR_CPU_x86_KVM_HV_TLBFLUSH  "__kvm_hv_tlbflush"
 # define VIR_CPU_x86_KVM_HV_IPI   "__kvm_hv_ipi"
+# define VIR_CPU_x86_KVM_HV_EVMCS "__kvm_hv_evmcs"
 
 
 # define VIR_CPU_X86_DATA_INIT { 0 }
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6fc8deff00..27e77f7d66 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6900,6 +6900,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);
 break;
 
+case

[libvirt] [PATCH v2 5/5] qemu: add support for Hyper-V Enlightened VMCS

2018-11-14 Thread Vitaly Kuznetsov

Qemu 3.1 supports Hyper-V Enlightened VMCS feature which significantly
speeds up nested Hyper-V on KVM environments.

Signed-off-by: Vitaly Kuznetsov 
---
 docs/news.xml   | 9 +
 src/qemu/qemu_command.c | 2 +-
 src/qemu/qemu_parse_command.c   | 2 +-
 src/qemu/qemu_process.c | 2 +-
 tests/qemuxml2argvdata/hyperv-off.xml   | 1 +
 tests/qemuxml2argvdata/hyperv.args  | 2 +-
 tests/qemuxml2argvdata/hyperv.xml   | 1 +
 tests/qemuxml2xmloutdata/hyperv-off.xml | 1 +
 tests/qemuxml2xmloutdata/hyperv.xml | 1 +
 9 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/docs/news.xml b/docs/news.xml
index c826380a92..dc10cfe69b 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -44,6 +44,15 @@
   for Windows guests.
 
   
+  
+
+  qemu: Add Hyper-V Enlightened VMCS support
+
+
+  The QEMU driver now has support for Hyper-V Enlightened VMCS
+  enlightenment for Hyper-V guests.
+
+  
 
 
 
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 27e77f7d66..d543ada2a1 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6883,6 +6883,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (def->hyperv_features[i] == VIR_TRISTATE_SWITCH_ON)
 virBufferAsprintf(, ",hv_%s",
   virDomainHypervTypeToString(i));
@@ -6900,7 +6901,6 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);
 break;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_LAST:
 break;
diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
index a1f8369919..d91fc8d901 100644
--- a/src/qemu/qemu_parse_command.c
+++ b/src/qemu/qemu_parse_command.c
@@ -1540,6 +1540,7 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 if (value) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("HyperV feature '%s' should not "
@@ -1580,7 +1581,6 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 
 break;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 case VIR_DOMAIN_HYPERV_LAST:
 break;
 }
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index ed8bcf7f76..ebe8e244ae 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3954,12 +3954,12 @@ qemuProcessVerifyHypervFeatures(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
 case VIR_DOMAIN_HYPERV_IPI:
+case VIR_DOMAIN_HYPERV_EVMCS:
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("host doesn't support hyperv '%s' feature"),
virDomainHypervTypeToString(i));
 return -1;
 
-case VIR_DOMAIN_HYPERV_EVMCS:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_VENDOR_ID:
 case VIR_DOMAIN_HYPERV_LAST:
diff --git a/tests/qemuxml2argvdata/hyperv-off.xml 
b/tests/qemuxml2argvdata/hyperv-off.xml
index e51cca45b5..59c1e17ccd 100644
--- a/tests/qemuxml2argvdata/hyperv-off.xml
+++ b/tests/qemuxml2argvdata/hyperv-off.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2argvdata/hyperv.args 
b/tests/qemuxml2argvdata/hyperv.args
index 0800e4f79d..5d59788e14 100644
--- a/tests/qemuxml2argvdata/hyperv.args
+++ b/tests/qemuxml2argvdata/hyperv.args
@@ -10,7 +10,7 @@ QEMU_AUDIO_DRV=none \
 -machine pc,accel=tcg,usb=off,dump-guest-core=off \
 -cpu 'qemu32,hv_relaxed,hv_vapic,hv_spinlocks=0x2fff,hv_vpindex,hv_runtime,\
 hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv,hv_frequencies,\
-hv_reenlightenment,hv_tlbflush,hv_ipi' \
+hv_reenlightenment,hv_tlbflush,hv_ipi,hv_evmcs' \
 -m 214 \
 -smp 6,sockets=6,cores=1,threads=1 \
 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
diff --git a/tests/qemuxml2argvdata/hyperv.xml 
b/tests/qemuxml2argvdata/hyperv.xml
index 05c7d478f7..c6feaed528 100644
--- a/tests/qemuxml2argvdata/hyperv.xml
+++ b/tests/qemuxml2argvdata/hyperv.xml
@@ -24,6 +24,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv-off.xml 
b/tests/qemuxml2xmloutdata/hyperv-off.xml
index 2282b763b5..1b7d82b14a 100644
--- a/tests/qemuxml2xmloutdata/hyperv-off.xml
+++ b/tests/qemuxml2xmloutdata/hyperv-off.xml
@@ -24,6 +24,7

Re: [libvirt] [PATCHv2] libvirt: add daemon itself as shutdown reason

2018-11-14 Thread Daniel P . Berrangé

On Wed, Nov 14, 2018 at 05:19:35PM +0100, Andrea Bolognani wrote:
> On Tue, 2018-11-13 at 15:36 -0500, John Ferlan wrote:
> > From: Nikolay Shirokovskiy 
> > 
> > This patch introduces a new shutdown reason "daemon" in order
> > to indicate that the daemon needed to force shutdown the domain
> > as the best course of action to take at the moment.
> > 
> > This action would occur during reconnection when processing
> > encounters an error once the monitor reconnection is successful.
> > 
> > Signed-off-by: Nikolay Shirokovskiy 
> > Reviewed-by: John Ferlan 
> 
> This made language bindings sad:
> 
>   https://ci.centos.org/view/libvirt/job/libvirt-go-check/106/
>   https://ci.centos.org/view/libvirt/job/libvirt-perl-check/107/

This is normal - the check jobs are explicitly intended to fail
whenever public API additions are made to remind us (me) to add
support there.

> Interestingly, Python doesn't seem to be bothered at all.

python auto-generates some of its code.

> Anyway, it would be great if someone would add support for the new
> enum value to Go and Perl bindings and make CI happy again :)

I'm doing it..

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 3/5] qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

Qemu 3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows
guests to send an IPI, especially when it targets many CPUs.

Signed-off-by: Vitaly Kuznetsov 
---
 docs/news.xml   | 9 +
 src/qemu/qemu_command.c | 2 +-
 src/qemu/qemu_parse_command.c   | 2 +-
 src/qemu/qemu_process.c | 2 +-
 tests/qemuxml2argvdata/hyperv-off.xml   | 1 +
 tests/qemuxml2argvdata/hyperv.args  | 2 +-
 tests/qemuxml2argvdata/hyperv.xml   | 1 +
 tests/qemuxml2xmloutdata/hyperv-off.xml | 1 +
 tests/qemuxml2xmloutdata/hyperv.xml | 1 +
 9 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/docs/news.xml b/docs/news.xml
index 88774c55ae..c826380a92 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -35,6 +35,15 @@
 
   
 
+  
+
+  qemu: Add Hyper-V PV IPI support
+
+
+  The QEMU driver now has support for Hyper-V PV IPI enlightenment
+  for Windows guests.
+
+  
 
 
 
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index b4d3f1ee35..6fc8deff00 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6882,6 +6882,7 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (def->hyperv_features[i] == VIR_TRISTATE_SWITCH_ON)
 virBufferAsprintf(, ",hv_%s",
   virDomainHypervTypeToString(i));
@@ -6899,7 +6900,6 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
   def->hyperv_vendor_id);
 break;
 
-case VIR_DOMAIN_HYPERV_IPI:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_LAST:
 break;
diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
index ab418432af..a15f4d1121 100644
--- a/src/qemu/qemu_parse_command.c
+++ b/src/qemu/qemu_parse_command.c
@@ -1539,6 +1539,7 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (value) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("HyperV feature '%s' should not "
@@ -1579,7 +1580,6 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
 
 break;
 
-case VIR_DOMAIN_HYPERV_IPI:
 case VIR_DOMAIN_HYPERV_LAST:
 break;
 }
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 3291d3f439..85e2f7046b 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3953,12 +3953,12 @@ qemuProcessVerifyHypervFeatures(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("host doesn't support hyperv '%s' feature"),
virDomainHypervTypeToString(i));
 return -1;
 
-case VIR_DOMAIN_HYPERV_IPI:
 /* coverity[dead_error_begin] */
 case VIR_DOMAIN_HYPERV_VENDOR_ID:
 case VIR_DOMAIN_HYPERV_LAST:
diff --git a/tests/qemuxml2argvdata/hyperv-off.xml 
b/tests/qemuxml2argvdata/hyperv-off.xml
index dc5777355f..e51cca45b5 100644
--- a/tests/qemuxml2argvdata/hyperv-off.xml
+++ b/tests/qemuxml2argvdata/hyperv-off.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2argvdata/hyperv.args 
b/tests/qemuxml2argvdata/hyperv.args
index c55204b0c8..0800e4f79d 100644
--- a/tests/qemuxml2argvdata/hyperv.args
+++ b/tests/qemuxml2argvdata/hyperv.args
@@ -10,7 +10,7 @@ QEMU_AUDIO_DRV=none \
 -machine pc,accel=tcg,usb=off,dump-guest-core=off \
 -cpu 'qemu32,hv_relaxed,hv_vapic,hv_spinlocks=0x2fff,hv_vpindex,hv_runtime,\
 hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv,hv_frequencies,\
-hv_reenlightenment,hv_tlbflush' \
+hv_reenlightenment,hv_tlbflush,hv_ipi' \
 -m 214 \
 -smp 6,sockets=6,cores=1,threads=1 \
 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
diff --git a/tests/qemuxml2argvdata/hyperv.xml 
b/tests/qemuxml2argvdata/hyperv.xml
index 816adf6907..05c7d478f7 100644
--- a/tests/qemuxml2argvdata/hyperv.xml
+++ b/tests/qemuxml2argvdata/hyperv.xml
@@ -23,6 +23,7 @@
   
   
   
+  
 
   
   
diff --git a/tests/qemuxml2xmloutdata/hyperv-off.xml 
b/tests/qemuxml2xmloutdata/hyperv-off.xml
index 77a8dac810..2282b763b5 100644
--- a/tests/qemuxml2xmloutdata/hyperv-off.xml
+++ b/tests/qemuxml2xmloutdata/hyperv-off.xml
@@ -23,6 +23,7 @@
   
   
   
+

Re: [libvirt] [ocaml PATCH] Cast virError* enums to int for comparisons with 0

2018-11-14 Thread Richard W.M. Jones

On Fri, Nov 02, 2018 at 03:52:23PM +0100, Pino Toscano wrote:
> The actual type of an enum in C is implementation defined when there are
> no negative values, and thus it can be int, or uint.  This is the case
> of the virError* enums in libvirt, as they do not have negative values.
> 
> Hence, to avoid hitting tautological comparison errors when checking
> their rage, temporarly cast the enum values to int when checking they

s/rage/range/

The patch itself is fine:

ACK.

Rich.

> are not negative.  The check is there to ensure the value is within the
> range of the OCaml type used to represent it.
> 
> Signed-off-by: Pino Toscano 
> ---
>  libvirt/libvirt_c_epilogue.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libvirt/libvirt_c_epilogue.c b/libvirt/libvirt_c_epilogue.c
> index 29656a4..4e75d2f 100644
> --- a/libvirt/libvirt_c_epilogue.c
> +++ b/libvirt/libvirt_c_epilogue.c
> @@ -153,7 +153,7 @@ Val_err_number (virErrorNumber code)
>CAMLparam0 ();
>CAMLlocal1 (rv);
>  
> -  if (0 <= code && code <= MAX_VIR_CODE)
> +  if (0 <= (int) code && code <= MAX_VIR_CODE)
>  rv = Val_int (code);
>else {
>  rv = caml_alloc (1, 0);  /* VIR_ERR_UNKNOWN (code) */
> @@ -169,7 +169,7 @@ Val_err_domain (virErrorDomain code)
>CAMLparam0 ();
>CAMLlocal1 (rv);
>  
> -  if (0 <= code && code <= MAX_VIR_DOMAIN)
> +  if (0 <= (int) code && code <= MAX_VIR_DOMAIN)
>  rv = Val_int (code);
>else {
>  rv = caml_alloc (1, 0);  /* VIR_FROM_UNKNOWN (code) */
> @@ -185,7 +185,7 @@ Val_err_level (virErrorLevel code)
>CAMLparam0 ();
>CAMLlocal1 (rv);
>  
> -  if (0 <= code && code <= MAX_VIR_LEVEL)
> +  if (0 <= (int) code && code <= MAX_VIR_LEVEL)
>  rv = Val_int (code);
>else {
>  rv = caml_alloc (1, 0);  /* VIR_ERR_UNKNOWN_LEVEL (code) */
> -- 
> 2.17.2
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] docs: Add notes for VIR_DOMAIN_SNAPSHOT_LIST_NO_METADATA

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 15:19 +0800, Han Han wrote:
> When listing snapshot with VIR_DOMAIN_SNAPSHOT_LIST_NO_METADATA, it
> always returns 0 or no snapshot. Because we never implement funtions
> to list no-metadata snapshot in virDomainSnapshotObjListGetNames():
> 
> if ((data.flags & VIR_DOMAIN_SNAPSHOT_FILTERS_METADATA) ==
> VIR_DOMAIN_SNAPSHOT_LIST_NO_METADATA)
> return 0;
> 
> Add notes for that flag.
> 
> Please update the comment and man page of that flag when no-metadata
> snapshot list is implemented in the future.

I could be missing some information, but from a quick look at the
commit message and the patch it looks to me like you're documenting
a known limitation instead of, you know, addressing it :)

If you are able to fix the issue yourself, then please do so;
otherwise, filing a bug seems like it would be a more appropriate
course of action.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 2/5] conf: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

Support Hyper-V PV IPI enlightenment in domain config. Qemu support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI cases
to src/qemu/* for now.

Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 7 +++
 docs/schemas/domaincommon.rng | 5 +
 src/conf/domain_conf.c| 7 ++-
 src/conf/domain_conf.h| 1 +
 src/cpu/cpu_x86.c | 3 +++
 src/cpu/cpu_x86_data.h| 1 +
 src/qemu/qemu_command.c   | 1 +
 src/qemu/qemu_parse_command.c | 1 +
 src/qemu/qemu_process.c   | 1 +
 9 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 28246deb63..7592f13a84 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1981,6 +1981,7 @@
 frequencies state='on'/
 reenlightenment state='on'/
 tlbflush state='on'/
+ipi state='on'/
   /hyperv
   kvm
 hidden state='on'/
@@ -2121,6 +2122,12 @@
   on, off
   4.7.0 (QEMU 3.0)
 
+
+  ipi
+  Enable PV IPI support
+  on, off
+  4.10.0 (QEMU 3.1)
+
   
   
   pvspinlock
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index b9ac5df479..26019b3279 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -5769,6 +5769,11 @@
 
   
 
+
+  
+
+  
+
   
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e8e0adc819..24876994c5 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -172,7 +172,9 @@ VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
   "vendor_id",
   "frequencies",
   "reenlightenment",
-  "tlbflush")
+  "tlbflush",
+  "ipi",
+);
 
 VIR_ENUM_IMPL(virDomainKVM, VIR_DOMAIN_KVM_LAST,
   "hidden")
@@ -19990,6 +19992,7 @@ virDomainDefParseXML(xmlDocPtr xml,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
@@ -22184,6 +22187,7 @@ virDomainDefFeaturesCheckABIStability(virDomainDefPtr 
src,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 if (src->hyperv_features[i] != dst->hyperv_features[i]) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("State of HyperV enlightenment "
@@ -27948,6 +27952,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
 case VIR_DOMAIN_HYPERV_FREQUENCIES:
 case VIR_DOMAIN_HYPERV_REENLIGHTENMENT:
 case VIR_DOMAIN_HYPERV_TLBFLUSH:
+case VIR_DOMAIN_HYPERV_IPI:
 break;
 
 case VIR_DOMAIN_HYPERV_SPINLOCKS:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e30a4b2fe7..9eea75548d 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1795,6 +1795,7 @@ typedef enum {
 VIR_DOMAIN_HYPERV_FREQUENCIES,
 VIR_DOMAIN_HYPERV_REENLIGHTENMENT,
 VIR_DOMAIN_HYPERV_TLBFLUSH,
+VIR_DOMAIN_HYPERV_IPI,
 
 VIR_DOMAIN_HYPERV_LAST
 } virDomainHyperv;
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 69a0c8db28..33252e927e 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -114,6 +114,8 @@ KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT,
 0x4003, 0x2000);
 KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_TLBFLUSH,
 0x4004, 0x0004);
+KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_IPI,
+0x4004, 0x0400);
 
 static virCPUx86Feature x86_kvm_features[] =
 {
@@ -137,6 +139,7 @@ static virCPUx86Feature x86_kvm_features[] =
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_FREQUENCIES),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_REENLIGHTENMENT),
 KVM_FEATURE(VIR_CPU_x86_KVM_HV_TLBFLUSH),
+KVM_FEATURE(VIR_CPU_x86_KVM_HV_IPI),
 };
 
 typedef struct _virCPUx86Model virCPUx86Model;
diff --git a/src/cpu/cpu_x86_data.h b/src/cpu/cpu_x86_data.h
index e75b3a2d0d..8c51d88e1a 100644
--- a/src/cpu/cpu_x86_data.h
+++ b/src/cpu/cpu_x86_data.h
@@ -65,6 +65,7 @@ struct _virCPUx86CPUID {
 # define VIR_CPU_x86_KVM_HV_FREQUENCIES "__kvm_hv_frequencies"
 # define VIR_CPU_x86_KVM_HV_REENLIGHTENMENT "__kvm_hv_reenlightenment"
 # define VIR_CPU_x86_KVM_HV_TLBFLUSH  "__kvm_hv_tlbflush"
+# define VIR_CPU_x86_KVM_HV_IPI   "__kvm_hv_ipi"
 
 
 # define VIR_CPU_X86_DATA_INIT { 0 }
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f59cbf559e..b4d3f1ee35 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6899,6 +6899,7 @@

[libvirt] [PATCH v2 1/5] docs: remove extra whitespate from Hyper-V enlightenments options

2018-11-14 Thread Vitaly Kuznetsov

Remove redundant leading whitespaces from " on, off".

Suggested-by: Andrea Bolognani 
Signed-off-by: Vitaly Kuznetsov 
---
 docs/formatdomain.html.in | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 269741a690..28246deb63 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -2052,7 +2052,7 @@
 
   relaxed
   Relax constraints on timers
-   on, off
+  on, off
   1.0.0 (QEMU 2.0)
 
 
@@ -2070,31 +2070,31 @@
 
   vpindex
   Virtual processor index
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
   runtime
   Processor time spent on running guest code and on behalf of 
guest code
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
   synic
   Enable Synthetic Interrupt Controller (SyNIC)
-   on, off
+  on, off
   1.3.3 (QEMU 2.6)
 
 
   stimer
   Enable SyNIC timers
-   on, off
+  on, off
   1.3.3 (QEMU 2.6)
 
 
   reset
   Enable hypervisor reset
-   on, off
+  on, off
   1.3.3 (QEMU 2.5)
 
 
@@ -2106,19 +2106,19 @@
 
   frequencies
   Expose frequency MSRs
-   on, off
+  on, off
   4.7.0 (QEMU 2.12)
 
 
   reenlightenment
   Enable re-enlightenment notification on migration
-   on, off
+  on, off
   4.7.0 (QEMU 3.0)
 
 
   tlbflush
   Enable PV TLB flush support
-   on, off
+  on, off
   4.7.0 (QEMU 3.0)
 
   
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 0/5] conf: qemu: support new Hyper-V enlightenments in Qemu 3.1

2018-11-14 Thread Vitaly Kuznetsov

The upcoming Qemu-3.1 release will bring us two new Hyper-V enlightenments:
hv_ipi and hv_evmcs. Support these in libvirt.

Changes since v1:
- Split patches into 'conf' and 'qemu' [John Ferlan]
- Add entries to docs/news.xml [Andrea Bolognani]
- Add a cleanup PATCH1 removing extra whitespaces from
  docs/formatdomain.html.in [Andrea Bolognani]
- Minor tweaks [Andrea Bolognani]

Vitaly Kuznetsov (5):
  docs: remove extra whitespate from Hyper-V enlightenments options
  conf: add support for Hyper-V PV IPIs
  qemu: add support for Hyper-V PV IPIs
  conf: add support for Hyper-V Enlightened VMCS
  qemu: add support for Hyper-V Enlightened VMCS

 docs/formatdomain.html.in   | 32 ++---
 docs/news.xml   | 18 ++
 docs/schemas/domaincommon.rng   | 10 
 src/conf/domain_conf.c  | 11 -
 src/conf/domain_conf.h  |  2 ++
 src/cpu/cpu_x86.c   |  6 +
 src/cpu/cpu_x86_data.h  |  2 ++
 src/qemu/qemu_command.c |  2 ++
 src/qemu/qemu_parse_command.c   |  2 ++
 src/qemu/qemu_process.c |  2 ++
 tests/qemuxml2argvdata/hyperv-off.xml   |  2 ++
 tests/qemuxml2argvdata/hyperv.args  |  2 +-
 tests/qemuxml2argvdata/hyperv.xml   |  2 ++
 tests/qemuxml2xmloutdata/hyperv-off.xml |  2 ++
 tests/qemuxml2xmloutdata/hyperv.xml |  2 ++
 15 files changed, 86 insertions(+), 11 deletions(-)

-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv8 2/2] tools: Add help docs explaining 'domstats' cache monitor result

2018-11-14 Thread John Ferlan




On 11/13/18 10:25 PM, Wang Huaqiang wrote:
> Add help document in explaining the cache monitor related 'domstats'
> result.
> 
> This patch is written to address John's review comment regarding
> patch16-v7 and expected to be merged with previous patch and using
> that patch's committing message.
> 
> Signed-off-by: Wang Huaqiang 
> ---
>  src/libvirt-domain.c | 21 -
>  tools/virsh.pod  | 13 +
>  2 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
> index 4895f9f..67ff430 100644
> --- a/src/libvirt-domain.c
> +++ b/src/libvirt-domain.c
> @@ -11345,15 +11345,18 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
>   * "cpu.user" - user cpu time spent in nanoseconds as unsigned long long.
>   * "cpu.system" - system cpu time spent in nanoseconds as unsigned long
>   *long.
> - * "cpu.cache.monitor.count" - tocal cache monitoring groups
> - * "cpu.cache.monitor.M.name" - name of cache monitoring group 'M'
> - * "cpu.cache.monitor.M.vcpus" - vcpus for cache monitoring group 'M'
> - * "cpu.cache.monitor.M.bank.count" - total bank number of cache 
> monitoring
> - *group 'M'
> - * "cpu.cache.monitor.M.bank.N.id" - OS assigned cache bank id for cache
> - *'N' in cache monitoring group 'M'
> - * "cpu.cache.monitor.M.bank.N.bytes" - monitor's cache occupancy of 
> cache
> - *bank 'N' in cache monitoring group 'M'
> + * "cpu.cache.monitor.count" - number of cache monitors on this domain

for this domain

> + * "cpu.cache.monitor..name" - name of cache monitor 
> + * "cpu.cache.monitor..vcpus" - vcpu list of cache monitor 
> + * "cpu.cache.monitor..bank.count" - number of cache banks in cache
> + *monitor 
> + * "cpu.cache.monitor..bank..id" - host allocatd cache id for

allocated

> + * bank  in cache
> + * monitor 
> + * "cpu.cache.monitor..bank..bytes" - the amount of last 
> level
> + *cache that domain is
> + *using on cache bank 
> 
> + *(in Byte)

the number of bytes of last level cache that the domain is using on
cache bank 

(and likewise below although there was an extra type there)

>   *
>   * VIR_DOMAIN_STATS_BALLOON:
>   * Return memory balloon device information.
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index 86c041d..49d9ab6 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -1011,6 +1011,19 @@ I<--cpu-total> returns:
>   "cpu.time" - total cpu time spent for this domain in nanoseconds
>   "cpu.user" - user cpu time spent in nanoseconds
>   "cpu.system" - system cpu time spent in nanoseconds
> + "cpu.cache.monitor.count" - number of cache monitors on this domain
> + "cpu.cache.monitor..name" - name of cache monitor 
> + "cpu.cache.monitor..vcpus" - vcpu list of cache monitor 
> + "cpu.cache.monitor..bank.count" - number of cache banks in
> +cache monitor 
> + "cpu.cache.monitor..bank..id" - host allocatd cache id
> + for bank  in
> + caach monitor 

cache


John


> + "cpu.cache.monitor..bank..bytes" - the amount of last
> +level cache that
> +domain is using on
> +cache bank 
> +(in Byte)
>  
>  I<--balloon> returns:
>  
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ocaml PATCH] Cast virError* enums to int for comparisons with 0

2018-11-14 Thread Andrea Bolognani

On Fri, 2018-11-02 at 15:52 +0100, Pino Toscano wrote:
> The actual type of an enum in C is implementation defined when there are
> no negative values, and thus it can be int, or uint.  This is the case
> of the virError* enums in libvirt, as they do not have negative values.
> 
> Hence, to avoid hitting tautological comparison errors when checking
> their rage, temporarly cast the enum values to int when checking they
> are not negative.  The check is there to ensure the value is within the
> range of the OCaml type used to represent it.
> 
> Signed-off-by: Pino Toscano 
> ---
>  libvirt/libvirt_c_epilogue.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Looks sane to me.

If that's enough for you, then you can have my

  Reviewed-by: Andrea Bolognani 

and push. I just really want

  https://ci.centos.org/view/libvirt/job/libvirt-ocaml-build/

to turn green :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv2] libvirt: add daemon itself as shutdown reason

2018-11-14 Thread Andrea Bolognani

On Tue, 2018-11-13 at 15:36 -0500, John Ferlan wrote:
> From: Nikolay Shirokovskiy 
> 
> This patch introduces a new shutdown reason "daemon" in order
> to indicate that the daemon needed to force shutdown the domain
> as the best course of action to take at the moment.
> 
> This action would occur during reconnection when processing
> encounters an error once the monitor reconnection is successful.
> 
> Signed-off-by: Nikolay Shirokovskiy 
> Reviewed-by: John Ferlan 

This made language bindings sad:

  https://ci.centos.org/view/libvirt/job/libvirt-go-check/106/
  https://ci.centos.org/view/libvirt/job/libvirt-perl-check/107/

Interestingly, Python doesn't seem to be bothered at all.

Anyway, it would be great if someone would add support for the new
enum value to Go and Perl bindings and make CI happy again :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv8 17/17] docs: Updated news.xml about the CMT support

2018-11-14 Thread John Ferlan




On 11/12/18 8:31 AM, Wang Huaqiang wrote:
> Signed-off-by: Wang Huaqiang 
> ---
>  docs/news.xml | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 88774c5..3c84126 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -50,6 +50,17 @@
>pvops-based HVM domains.
>  
>
> +  
> +
> +  qemu: Added support for CMT (Cache Monitoring Technology)
> +
> +
> +  Introduced cache monitor by monitor element

s/monitor by/monitoring using the/

> +  in cachetune for vCPU threads, and added interface

s/threads, and added interface/threads. Added interfaces/

> +  to get the cache utilization information through command

s/to get/to get and display/
s/information/statistics/
s/through command/through the command/

> +  'virsh domstats'.
s/./ via the virConnectGetAllDomainStats API.

> +
> +  

This should be in the 'New features' section - this is definitely not a
bug fix!

John

>  
>
>
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv8 16/17] qemu: Report cache occupancy (CMT) with domstats

2018-11-14 Thread John Ferlan




On 11/12/18 8:31 AM, Wang Huaqiang wrote:
> Adding the interface in qemu to report CMT statistic information
> through command 'virsh domstats --cpu-total'.
> 
> Below is a typical output:
> 
>  # virsh domstats 1 --cpu-total
>  Domain: 'ubuntu16.04-base'
>...
>cpu.cache.monitor.count=2
>cpu.cache.monitor.0.name=vcpus_1
>cpu.cache.monitor.0.vcpus=1
>cpu.cache.monitor.0.bank.count=2
>cpu.cache.monitor.0.bank.0.id=0
>cpu.cache.monitor.0.bank.0.bytes=4505600
>cpu.cache.monitor.0.bank.1.id=1
>cpu.cache.monitor.0.bank.1.bytes=5586944
>cpu.cache.monitor.1.name=vcpus_4-6
>cpu.cache.monitor.1.vcpus=4,5,6
>cpu.cache.monitor.1.bank.count=2
>cpu.cache.monitor.1.bank.0.id=0
>cpu.cache.monitor.1.bank.0.bytes=17571840
>cpu.cache.monitor.1.bank.1.id=1
>cpu.cache.monitor.1.bank.1.bytes=29106176
> 
> Signed-off-by: Wang Huaqiang 
> ---
>  src/libvirt-domain.c   |   9 +++
>  src/qemu/qemu_driver.c | 198 
> +
>  2 files changed, 207 insertions(+)
> 
> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
> index 7690339..4895f9f 100644
> --- a/src/libvirt-domain.c
> +++ b/src/libvirt-domain.c
> @@ -11345,6 +11345,15 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
>   * "cpu.user" - user cpu time spent in nanoseconds as unsigned long long.
>   * "cpu.system" - system cpu time spent in nanoseconds as unsigned long
>   *long.
> + * "cpu.cache.monitor.count" - tocal cache monitoring groups
> + * "cpu.cache.monitor.M.name" - name of cache monitoring group 'M'
> + * "cpu.cache.monitor.M.vcpus" - vcpus for cache monitoring group 'M'
> + * "cpu.cache.monitor.M.bank.count" - total bank number of cache 
> monitoring
> + *group 'M'
> + * "cpu.cache.monitor.M.bank.N.id" - OS assigned cache bank id for cache
> + *'N' in cache monitoring group 'M'
> + * "cpu.cache.monitor.M.bank.N.bytes" - monitor's cache occupancy of 
> cache
> + *bank 'N' in cache monitoring group 'M'

I'll comment on these in your update...

>   *
>   * VIR_DOMAIN_STATS_BALLOON:
>   * Return memory balloon device information.
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 89d46ee..d41ae66 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -19698,6 +19698,199 @@ typedef enum {
>  #define HAVE_JOB(flags) ((flags) & QEMU_DOMAIN_STATS_HAVE_JOB)
>  
>  
> +typedef struct _virQEMUCpuResMonitorData virQEMUCpuResMonitorData;
> +typedef virQEMUCpuResMonitorData *virQEMUCpuResMonitorDataPtr;
> +struct _virQEMUCpuResMonitorData{

Data {

> +const char *name;
> +char *vcpus;
> +virResctrlMonitorType tag;
> +virResctrlMonitorStatsPtr stats;
> +size_t nstats;
> +};
> +
> +
> +static int
> +qemuDomainGetCpuResMonitorData(virDomainObjPtr dom,
> +   virQEMUCpuResMonitorDataPtr mondata)
> +{
> +virDomainResctrlDefPtr resctrl = NULL;
> +size_t i = 0;
> +size_t j = 0;
> +size_t l = 0;
> +
> +for (i = 0; i < dom->def->nresctrls; i++) {
> +resctrl = dom->def->resctrls[i];
> +
> +for (j = 0; j < resctrl->nmonitors; j++) {
> +virDomainResctrlMonDefPtr domresmon = NULL;
> +virResctrlMonitorPtr monitor = resctrl->monitors[j]->instance;
> +
> +domresmon = resctrl->monitors[j];
> +mondata[l].tag = domresmon->tag;

Why "l" (BTW: 'k' would be preferred because '1' and 'l' are very
difficult to delineate).

> +
> +/* If virBitmapFormat successfully returns an vcpu string, then
> + * mondata[l].vcpus is assigned with an memory space holding it,
> + * let this newly allocated memory buffer to be freed along with
> + * the free of 'mondata' */
> +if (!(mondata[l].vcpus = virBitmapFormat(domresmon->vcpus)))
> +return -1;
> +
> +if (!(mondata[l].name = virResctrlMonitorGetID(monitor))) {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +   _("Could not get monitor ID"));
> +return -1;
> +}
> +
> +if (domresmon->tag == VIR_RESCTRL_MONITOR_TYPE_CACHE) {

Something doesn't quite add up with this... Since we're only filling in
types with 'cache' types and erroring out otherwise ... see [1] data
points below...

> +if (virResctrlMonitorGetCacheOccupancy(monitor,
> +   [l].stats,
> +   [l].nstats) < 
> 0)
> +return -1;
> +} else {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +   _("Invalid

Re: [libvirt] [PATCH RFC 09/22] qemu_capabilities: Detect caps probe failure by checking monitor ptr

2018-11-14 Thread Michal Privoznik

On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> Failure to connect to QEMU to probe capabilities is not considered a error 
> case
> and does not result in a negative return value.
> 
> Check for a NULL monitor connection pointer before trying to send capabilities
> commands to QEMU rather than depending on a special positive return value.
> 
> This simplifies logic and is more consistent with the operation of existing
> qemu_process functions.
> 
> A macro is introduced to easily obtain the monitor pointer from the
> qemuProcess structure.
> 
> Signed-off-by: Chris Venteicher 
> ---
>  src/qemu/qemu_capabilities.c | 28 ++--
>  src/qemu/qemu_process.c  |  9 +
>  src/qemu/qemu_process.h  |  3 +++
>  3 files changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index f5e327097e..fbb4336201 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -4220,43 +4220,51 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
>  {
>  qemuProcessPtr proc = NULL;
>  qemuProcessPtr proc_kvm = NULL;
> +qemuMonitorPtr mon = NULL;
> +qemuMonitorPtr mon_kvm = NULL;
>  int ret = -1;
> -int rc;
>  bool forceTCG = false;
>  
>  if (!(proc = qemuProcessNew(qemuCaps->binary, libDir,
>  runUid, runGid, forceTCG)))
>  goto cleanup;
>  
> -if ((rc = qemuProcessRun(proc)) != 0) {
> -if (rc == 1)
> -ret = 0;
> +
> +if (qemuProcessRun(proc) < 0)
> +goto cleanup;
> +
> +if (!(mon = QEMU_PROCESS_MONITOR(proc))) {
> +ret = 0; /* Failure probing QEMU not considered error case */
>  goto cleanup;
>  }
>  
> -if (virQEMUCapsInitQMPMonitor(qemuCaps, proc->mon) < 0)
> +/* Pull capabilities from QEMU */
> +if (virQEMUCapsInitQMPMonitor(qemuCaps, mon) < 0)
>  goto cleanup;
>  
> +/* Pull capabilities again if KVM supported */
>  if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
>  qemuProcessStopQmp(proc);
>  
>  forceTCG = true;
>  proc_kvm = qemuProcessNew(qemuCaps->binary, libDir, runUid, runGid, 
> forceTCG);
>  
> -if ((rc = qemuProcessRun(proc_kvm)) != 0) {
> -if (rc == 1)
> -ret = 0;
> +if (qemuProcessRun(proc_kvm) < 0)
> +goto cleanup;
> +
> +if (!(mon_kvm = QEMU_PROCESS_MONITOR(proc_kvm))) {
> +ret = 0; /* Failure probing QEMU not considered error case */
>  goto cleanup;
>  }
>  
> -if (virQEMUCapsInitQMPMonitorTCG(qemuCaps, proc_kvm->mon) < 0)
> +if (virQEMUCapsInitQMPMonitorTCG(qemuCaps, mon_kvm) < 0)
>  goto cleanup;
>  }
>  
>  ret = 0;
>  
>   cleanup:
> -if (proc && !proc->mon) {
> +if (!mon) {
>  char *err = QEMU_PROCESS_ERROR(proc) ? QEMU_PROCESS_ERROR(proc) : 
> _("unknown error");
>  
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index a741d1cf91..2640ec2b32 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -8148,10 +8148,6 @@ qemuProcessNew(const char *binary,
>  }
>  
>  
> -/* Returns -1 on fatal error,
> - *  0 on success,
> - *  1 when probing QEMU failed
> - */
>  int
>  qemuProcessRun(qemuProcessPtr proc){
>  virDomainXMLOptionPtr xmlopt = NULL;
> @@ -8218,6 +8214,7 @@ qemuProcessRun(qemuProcessPtr proc){
>  
>  virObjectLock(proc->mon);
>  
> + ignore:

How about removing this label completely? I mean, s/goto ignore;/ret =
0; goto cleanup;/

>  ret = 0;
>  
>   cleanup:
> @@ -8226,10 +8223,6 @@ qemuProcessRun(qemuProcessPtr proc){
>  virObjectUnref(xmlopt);
>  
>  return ret;
> -
> - ignore:
> -ret = 1;
> -goto cleanup;
>  }
>  
>  
> diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h
> index abd80baf5c..37194e2501 100644
> --- a/src/qemu/qemu_process.h
> +++ b/src/qemu/qemu_process.h
> @@ -235,6 +235,9 @@ struct _qemuProcess {
>  #define QEMU_PROCESS_ERROR(proc) \
> ((char *) (proc ? proc->qmperr: NULL))
>  
> +#define QEMU_PROCESS_MONITOR(proc) \
> +   ((qemuMonitorPtr) (proc ? proc->mon : NULL))

This looks like an overkill to me. At the only two points where this is
used @proc/@proc_kvm can't be NULL so proc->mon/proc_kvm->mon can be
accessed directly.

> +
>  qemuProcessPtr qemuProcessNew(const char *binary,
>const char *libDir,
>uid_t runUid,
> 

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC 10/22] qemu_process: Introduce qemuProcessStartQmp

2018-11-14 Thread Michal Privoznik

On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> Move a step closer to the function structure used elsewhere in
> qemu_process where qemuProcessStart and qemuProcessStop are the exposed
> functions.
> 
> qemuProcessStartQmp mirrors qemuProcessStart in calling sub functions to
> intialize, launch the process and connect the monitor to the QEMU
> process.
> 
> static functions qemuProcessInitQmp, qemuProcessLaunchQmp and
> qemuConnectMonitorQmp are also introduced.
> 
> qemuProcessLaunchQmp is just renamed from qemuProcessRun and
> encapsulates all of the original code.
> 
> qemuProcessInitQmp and qemuProcessMonitorQmp are introduced as empty
> wrappers into which subsequent patches will partition code from
> qemuProcessLaunchQmp.
> 
> Signed-off-by: Chris Venteicher 
> ---
>  src/qemu/qemu_capabilities.c |  4 +-
>  src/qemu/qemu_process.c  | 96 +++-
>  src/qemu/qemu_process.h  |  2 +-
>  3 files changed, 97 insertions(+), 5 deletions(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index fbb4336201..7168c470f6 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -4230,7 +4230,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
>  goto cleanup;
>  
>  
> -if (qemuProcessRun(proc) < 0)
> +if (qemuProcessStartQmp(proc) < 0)
>  goto cleanup;
>  
>  if (!(mon = QEMU_PROCESS_MONITOR(proc))) {
> @@ -4249,7 +4249,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
>  forceTCG = true;
>  proc_kvm = qemuProcessNew(qemuCaps->binary, libDir, runUid, runGid, 
> forceTCG);
>  
> -if (qemuProcessRun(proc_kvm) < 0)
> +if (qemuProcessStartQmp(proc_kvm) < 0)
>  goto cleanup;
>  
>  if (!(mon_kvm = QEMU_PROCESS_MONITOR(proc_kvm))) {
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 2640ec2b32..b6aa3a9af3 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -8148,8 +8148,29 @@ qemuProcessNew(const char *binary,
>  }
>  
>  
> -int
> -qemuProcessRun(qemuProcessPtr proc){
> +/* Initialize configuration and paths prior to starting QEMU
> + */
> +static int
> +qemuProcessInitQmp(qemuProcessPtr proc)
> +{
> +int ret = -1;
> +
> +VIR_DEBUG("Beginning VM startup process"
> +  "emulator=%s",
> +  proc->binary);
> +
> +ret = 0;
> +
> +VIR_DEBUG("ret=%i", ret);
> +return ret;
> +}
> +

I am sorry, but I'm failing to see the purpose of this function.

> +
> +/* Launch QEMU Process
> + */
> +static int
> +qemuProcessLaunchQmp(qemuProcessPtr proc)
> +{
>  virDomainXMLOptionPtr xmlopt = NULL;
>  const char *machine;
>  int status = 0;
> @@ -8226,6 +8247,77 @@ qemuProcessRun(qemuProcessPtr proc){
>  }
>  
>  
> +/* Connect Monitor to QEMU Process
> + */
> +static int
> +qemuConnectMonitorQmp(qemuProcessPtr proc)
> +{
> +int ret = -1;
> +
> +VIR_DEBUG("proc=%p, emulator=%s, proc->pid=%lld",
> +  proc, NULLSTR(proc->binary), (long long) proc->pid);
> +
> +ret = 0;
> +
> +VIR_DEBUG("ret=%i", ret);
> +return ret;
> +}

Or this function. Looking into next patches I can see that you're
extending them. Well, I still think it's not worth introducing empty
functions, just do the rename as you're doing in next patches.

> +
> +
> +/**
> + * qemuProcessStartQmp:
> + * @proc: Stores Process and Connection State
> + *
> + * Start and connect to QEMU binary so QMP queries can be made.
> + *
> + * Usage:
> + *   proc = qemuProcessNew(binary, forceTCG, libDir, runUid, runGid);
> + *   qemuProcessStartQmp(proc);
> + *   mon = QEMU_PROCESS_MONITOR(proc);
> + *   ** Send QMP Queries to QEMU using monitor **
> + *   qemuProcessStopQmp(proc);
> + *   qemuProcessFree(proc);
> + *
> + * Check monitor is not NULL before using.
> + *
> + * QEMU probing failure results in monitor being NULL but is not considered
> + * an error case and does not result in a negative return value.
> + *
> + * Both qemuProcessStopQmp and qemuProcessFree must be called to cleanup and
> + * free resources, even in activation failure cases.
> + *
> + * Process error output (proc->qmperr) remains available in qemuProcess 
> struct
> + * until qemuProcessFree is called.
> + */
> +int
> +qemuProcessStartQmp(qemuProcessPtr proc)
> +{
> +int ret = -1;
> +
> +VIR_DEBUG("emulator=%s",
> +  proc->binary);
> +
> +if (qemuProcessInitQmp(proc) < 0)
> +goto cleanup;
> +
> +if (qemuProcessLaunchQmp(proc) < 0)
> +goto stop;
> +
> +if (qemuConnectMonitorQmp(proc) < 0)
> +goto stop;
> +
> +ret = 0;
> +
> + cleanup:
> +VIR_DEBUG("ret=%i", ret);
> +return ret;
> +
> + stop:
> +qemuProcessStopQmp(proc);
> +goto cleanup;
> +}
> +
> +
>  void
>  qemuProcessStopQmp(qemuProcessPtr proc)
>  {
> diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h
> index 37194e2501..c34ca52ef5 100644
> --- a/src/qemu/qemu_process.h
>

Re: [libvirt] [PATCH RFC 00/22] Move process code to qemu_process

2018-11-14 Thread Michal Privoznik

On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> Make process code usable outside qemu_capabilities by moving code
> from qemu_capabilities to qemu_process and exposing public functions.
> 
> The process code is used to activate a non domain QEMU process for QMP
> message exchanges.
> 
> This patch set modifies capabilities to use the new public functions.
> 
> --
> 
> The process code is being decoupled from qemu_capabilities now to
> support hypervisor baseline and comparison using QMP commands.
> 
> This patch set was originally submitted as part of the baseline patch set:
>   [libvirt] [PATCH v4 00/37] BaselineHypervisorCPU using QEMU QMP exchanges
>   https://www.redhat.com/archives/libvir-list/2018-November/msg00091.html

Okay, so you want to implement cpu-baseline for s390. But that doesn't
really explain the code movement. Also, somehow the code movement makes
the code bigger? I guess what I am saying is that I don't see much
justification for these patches.

> 
> The baseline and comparison requirements are described here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1511999
> https://bugzilla.redhat.com/show_bug.cgi?id=1511996
> 
> 
> I am extracting and resubmitting just the process changes as a stand
> alone series to try to make review easier.
> 
> The patch set shows capabilities using the public functions.
> To see baseline using the public functions...
> Look at the "qemu_driver:" patches at the end of
> https://www.redhat.com/archives/libvir-list/2018-November/msg00091.html
> 
> Also,
> The "qemu_driver: Support feature expansion via QEMU when baselining cpu"
> patch might be of particular interest because the same QEMU process is
> used for both baseline and expansion using QMP commands.
> 
> --
> 
> Many patches were used to isolate code moves and name changes from other
> actual implementation changes.
> 
> The patches reuse the pattern of public qemuProcess{Start,Stop} functions
> and internal static qemuProcess{Init,Launch,ConnectMonitor} functions
> but adds a "Qmp" suffix to make them unique.
> 
> A number of patches are about re-partitioning the code into static
> functions for initialization, process launch and connection monitor
> stuff.  This matches the established pattern in qemu_process and seemed
> to make sense to do.
> 
> For concurrency...
> A thread safe library function creates a unique directory under libDir for 
> each QEMU
> process (for QMP messaging) to decouple processes in terms of sockets and
> file system footprint.
> 
> Every patch should compile independently if applied in sequence.

Oh, but it doesn't. I'm running 'make -j10 all syntax-check check' and I
am hitting compilation/syntax error occasionally.


> 
> 
> Chris Venteicher (22):
>   qemu_process: Move process code from qemu_capabilities to qemu_process
>   qemu_process: Use qemuProcess prefix
>   qemu_process: Limit qemuProcessNew to const input strings
>   qemu_process: Refer to proc not cmd in process code
>   qemu_process: Use consistent name for stop process function
>   qemu_capabilities: Stop QEMU process before freeing
>   qemu_process: Use qemuProcess struct for a single process
>   qemu_process: Persist stderr in qemuProcess struct
>   qemu_capabilities: Detect caps probe failure by checking monitor ptr
>   qemu_process: Introduce qemuProcessStartQmp
>   qemu_process: Collect monitor code in single function
>   qemu_process: Store libDir in qemuProcess struct
>   qemu_process: Setup paths within qemuProcessInitQmp
>   qemu_process: Stop retaining Qemu Monitor config in qemuProcess
>   qemu_process: Don't open monitor if process failed
>   qemu_process: Cleanup qemuProcess alloc function
>   qemu_process: Cleanup qemuProcessStopQmp function
>   qemu_process: Catch process free before process stop
>   qemu_monitor: Make monitor callbacks optional
>   qemu_process: Enter QMP command mode when starting QEMU Process
>   qemu_process: Use unique directories for QMP processes
>   qemu_process: Stop locking QMP process monitor immediately
> 
>  src/qemu/qemu_capabilities.c | 300 +
>  src/qemu/qemu_monitor.c  |   4 +-
>  src/qemu/qemu_process.c  | 356 +++
>  src/qemu/qemu_process.h  |  37 
>  tests/qemucapabilitiestest.c |   7 +
>  5 files changed, 444 insertions(+), 260 deletions(-)
> 

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Daniel P . Berrangé

On Wed, Nov 14, 2018 at 03:48:16PM +0100, Andrea Bolognani wrote:
> flake8 3.5.0 doesn't work with pyflakes 2.0.0, and since those
> are the versions available through ports there's currently no
> way to successfully run flake8 on FreeBSD.
> 
> We will be able to revert this once flake8 3.6.0 is available
> through ports.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/playbooks/build/projects/libvirt-dbus.yml | 7 +++
>  projects/libvirt-dbus.yaml   | 7 +++
>  2 files changed, 6 insertions(+), 8 deletions(-)

Reviewed-by: Daniel P. Berrangé 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH v2] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Andrea Bolognani

flake8 3.5.0 doesn't work with pyflakes 2.0.0, and since those
are the versions available through ports there's currently no
way to successfully run flake8 on FreeBSD.

We will be able to revert this once flake8 3.6.0 is available
through ports.

Signed-off-by: Andrea Bolognani 
---
 guests/playbooks/build/projects/libvirt-dbus.yml | 7 +++
 projects/libvirt-dbus.yaml   | 7 +++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml 
b/guests/playbooks/build/projects/libvirt-dbus.yml
index 1d4ecbd..41e670c 100644
--- a/guests/playbooks/build/projects/libvirt-dbus.yml
+++ b/guests/playbooks/build/projects/libvirt-dbus.yml
@@ -21,16 +21,15 @@
 - include: '{{ playbook_base }}/jobs/autotools-build-job.yml'
 - include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml'
   vars:
-# CentOS 7 doesn't include Python 3 and the version of pyflakes
-# in FreeBSD CURRENT is too new to be used by flake8
+# CentOS 7 doesn't include Python 3, while the versions of flake8
+# and pyflakes currently available on FreeBSD (3.5.0 and 2.0.0
+# respectively) are not compatible
 machines:
   - libvirt-debian-9
   - libvirt-debian-sid
   - libvirt-fedora-28
   - libvirt-fedora-29
   - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - libvirt-freebsd-11
   - libvirt-ubuntu-16
   - libvirt-ubuntu-18
 - include: '{{ playbook_base }}/jobs/autotools-check-job.yml'
diff --git a/projects/libvirt-dbus.yaml b/projects/libvirt-dbus.yaml
index 48bbdaa..3d1ed9c 100644
--- a/projects/libvirt-dbus.yaml
+++ b/projects/libvirt-dbus.yaml
@@ -18,15 +18,14 @@
   parent_jobs: 'libvirt-glib-build'
   - autotools-syntax-check-job:
   parent_jobs: 'libvirt-dbus-build'
-  # CentOS 7 doesn't include Python 3 and the version of pyflakes
-  # in FreeBSD CURRENT is too new to be used by flake8
+  # CentOS 7 doesn't include Python 3, while the versions of flake8
+  # and pyflakes currently available on FreeBSD (3.5.0 and 2.0.0
+  # respectively) are not compatible
   machines:
 - libvirt-debian-9
 - libvirt-fedora-28
 - libvirt-fedora-29
 - libvirt-fedora-rawhide
-- libvirt-freebsd-10
-- libvirt-freebsd-11
   - autotools-check-job:
   parent_jobs: 'libvirt-dbus-syntax-check'
   # CentOS 7 doesn't include Python 3 and the version in Ubuntu
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 14:25 +, Daniel P. Berrangé wrote:
> On Wed, Nov 14, 2018 at 03:12:19PM +0100, Andrea Bolognani wrote:
> > So we can either merge this patch to make the failures go away for
> > the time being and re-introduce the job once flake8 3.6.0 is
> > available in FreeBSD, or endure the failure a bit longer and just
> > wait for it to go away on its own. In the latter case, re-adding
> > FreeBSD -CURRENT as a target for the job would make as well.
> > 
> > Let me know which one of the two solutions you prefer.
> 
> I'm fine taking this patch for now, if you just clarify the
> commit message a little about the problem being flake8
> <= 3.5.0

Fair enough. v2 here:

  https://www.redhat.com/archives/libvir-list/2018-November/msg00553.html

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Daniel P . Berrangé

On Wed, Nov 14, 2018 at 03:12:19PM +0100, Andrea Bolognani wrote:
> On Wed, 2018-11-14 at 13:12 +, Daniel P. Berrangé wrote:
> > On Wed, Nov 14, 2018 at 01:43:10PM +0100, Andrea Bolognani wrote:
> > > flake8 wants 'pyflakes<1.7.0,>=1.5.0', but all FreeBSD
> > > releases ship pyflakes 2.0.0 these days.
> > 
> > This rationale doesn't make sense given that I see Fedora has
> > flake8 which is happily using pyflakes 2.0.0
> > 
> ># rpm -q python3-flake8 python3-pyflakes
> >python3-flake8-3.5.0-6.fc29.noarch
> >python3-pyflakes-2.0.0-7.fc29.noarch
> > 
> > Something else must be happening on FreeBSD.
> 
> Looks like Fedora is carrying a patch[1] that introduces pyflakes
> 2.0.0 compatibility, which has been backported from flake8 3.6.0.
> I don't expect FreeBSD will backport the patch, they're probably
> going to jump straight to the newer upstream release instead.
> 
> So we can either merge this patch to make the failures go away for
> the time being and re-introduce the job once flake8 3.6.0 is
> available in FreeBSD, or endure the failure a bit longer and just
> wait for it to go away on its own. In the latter case, re-adding
> FreeBSD -CURRENT as a target for the job would make as well.
> 
> Let me know which one of the two solutions you prefer.

I'm fine taking this patch for now, if you just clarify the
commit message a little about the problem being flake8
<= 3.5.0

> 
> 
> [1] 
> https://src.fedoraproject.org/rpms/python-flake8/blob/f29/f/python-flake8-3.5.0-pyflakes-2.0.0.patch

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] conf: qemu: support new Hyper-V enlightenments in Qemu-3.1

2018-11-14 Thread John Ferlan

On 11/14/18 8:24 AM, Vitaly Kuznetsov wrote:
> John Ferlan  writes:
> 
>> On 11/14/18 4:04 AM, Andrea Bolognani wrote:
>>> On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
 The upcoming Qemu-3.1 release will bring us two new Hyper-V enlightenments:
 hv_ipi and hv_evmcs. Support these in libvirt.

 Vitaly Kuznetsov (2):
   conf: qemu: add support for Hyper-V PV IPIs
   conf: qemu: add support for Hyper-V Enlightened VMCS
>>>
>>> I have pointed out a few very minor issues with the patches, as
>>> well as a couple areas where pre-existing issues could be fixed,
>>> although I don't consider the latter a requirement for merging
>>> the series ;)
>>>
>>> One thing that I would like to see, though, is the change being
>>> documented properly in the release notes (docs/news.xml). Please
>>> include that and respin.
>>>
>>
>> One other thing that I've really tried to see done is splitting the
>> "conf" and "qemu" patches.
>>
>> That way one deals with conf, docs, conf, util, xml2xmltest, while the
>> other deals with the qemu specific changes qemu, xml2argv.
>>
>> Sometimes it's "harder" to do that - such as may be the case with
>> various switches when a new case is added; however, in that case the
>> added case in the conf/docs/etc patch would go with the "default:" or
>> "last" case and then be moved with the subsequent qemu patch.
>>
> 
> I have to admit my overall knowledge of libvirt pretty limited, probably
> because of that I'm failing to see benefits of doing such split for
> Qemu/KVM-only features (as the whole Hyper-V emulation is

Generally speaking it's to keep conf/docs/XML changes separate from
hypervisor specific to make bisecting easier and patches smaller for
reviews.

I see I didn't ask the last time (commit f4c39db736 for PV TLB flush
support in Aug 2018), so either I had a lapse there or I was just
feeling it wasn't that important since things are so tightly coupled. I
look at a lot of patches and just try to be consistent in asks.

> Qemu/KVM-only). How is the first patch going to be tested? Compile-only?

Since you've updated tests/qemuxml2xmloutdata/hyperv.xml (and the
output). That means the XML parsing is being tested. So that's testing
that the newly added XML/RNG field can be parsed and output as expected.
There are cases I've reviewed where the formatting was wrong, but there
was no xml2xml to test that.

> Also, which of these patches should src/cpu/* hunks go to?

I would think the conf/docs/xml2xml since it seems they are defining
supported bits.

> 
> Would realy appreciate some guidance here) Thanks!
> 

In the long run it may not matter much - I'm not here to NAK something
because the split isn't done. Again, I'm trying to be consistent in how
I look at things.

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 13:12 +, Daniel P. Berrangé wrote:
> On Wed, Nov 14, 2018 at 01:43:10PM +0100, Andrea Bolognani wrote:
> > flake8 wants 'pyflakes<1.7.0,>=1.5.0', but all FreeBSD
> > releases ship pyflakes 2.0.0 these days.
> 
> This rationale doesn't make sense given that I see Fedora has
> flake8 which is happily using pyflakes 2.0.0
> 
># rpm -q python3-flake8 python3-pyflakes
>python3-flake8-3.5.0-6.fc29.noarch
>python3-pyflakes-2.0.0-7.fc29.noarch
> 
> Something else must be happening on FreeBSD.

Looks like Fedora is carrying a patch[1] that introduces pyflakes
2.0.0 compatibility, which has been backported from flake8 3.6.0.
I don't expect FreeBSD will backport the patch, they're probably
going to jump straight to the newer upstream release instead.

So we can either merge this patch to make the failures go away for
the time being and re-introduce the job once flake8 3.6.0 is
available in FreeBSD, or endure the failure a bit longer and just
wait for it to go away on its own. In the latter case, re-adding
FreeBSD -CURRENT as a target for the job would make as well.

Let me know which one of the two solutions you prefer.

[1] 
https://src.fedoraproject.org/rpms/python-flake8/blob/f29/f/python-flake8-3.5.0-pyflakes-2.0.0.patch
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] conf: qemu: support new Hyper-V enlightenments in Qemu-3.1

2018-11-14 Thread Vitaly Kuznetsov

John Ferlan  writes:

> On 11/14/18 4:04 AM, Andrea Bolognani wrote:
>> On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
>>> The upcoming Qemu-3.1 release will bring us two new Hyper-V enlightenments:
>>> hv_ipi and hv_evmcs. Support these in libvirt.
>>>
>>> Vitaly Kuznetsov (2):
>>>   conf: qemu: add support for Hyper-V PV IPIs
>>>   conf: qemu: add support for Hyper-V Enlightened VMCS
>> 
>> I have pointed out a few very minor issues with the patches, as
>> well as a couple areas where pre-existing issues could be fixed,
>> although I don't consider the latter a requirement for merging
>> the series ;)
>> 
>> One thing that I would like to see, though, is the change being
>> documented properly in the release notes (docs/news.xml). Please
>> include that and respin.
>> 
>
> One other thing that I've really tried to see done is splitting the
> "conf" and "qemu" patches.
>
> That way one deals with conf, docs, conf, util, xml2xmltest, while the
> other deals with the qemu specific changes qemu, xml2argv.
>
> Sometimes it's "harder" to do that - such as may be the case with
> various switches when a new case is added; however, in that case the
> added case in the conf/docs/etc patch would go with the "default:" or
> "last" case and then be moved with the subsequent qemu patch.
>

I have to admit my overall knowledge of libvirt pretty limited, probably
because of that I'm failing to see benefits of doing such split for
Qemu/KVM-only features (as the whole Hyper-V emulation is
Qemu/KVM-only). How is the first patch going to be tested? Compile-only?
Also, which of these patches should src/cpu/* hunks go to?

Would realy appreciate some guidance here) Thanks!

-- 
Vitaly

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Daniel P . Berrangé

On Wed, Nov 14, 2018 at 01:43:10PM +0100, Andrea Bolognani wrote:
> flake8 wants 'pyflakes<1.7.0,>=1.5.0', but all FreeBSD
> releases ship pyflakes 2.0.0 these days.

This rationale doesn't make sense given that I see Fedora has
flake8 which is happily using pyflakes 2.0.0

   # rpm -q python3-flake8 python3-pyflakes
   python3-flake8-3.5.0-6.fc29.noarch
   python3-pyflakes-2.0.0-7.fc29.noarch

Something else must be happening on FreeBSD.

> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/playbooks/build/projects/libvirt-dbus.yml | 4 +---
>  projects/libvirt-dbus.yaml   | 4 +---
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml 
> b/guests/playbooks/build/projects/libvirt-dbus.yml
> index 1d4ecbd..61ece63 100644
> --- a/guests/playbooks/build/projects/libvirt-dbus.yml
> +++ b/guests/playbooks/build/projects/libvirt-dbus.yml
> @@ -22,15 +22,13 @@
>  - include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml'
>vars:
>  # CentOS 7 doesn't include Python 3 and the version of pyflakes
> -# in FreeBSD CURRENT is too new to be used by flake8
> +# in FreeBSD is too new to be used by flake8
>  machines:
>- libvirt-debian-9
>- libvirt-debian-sid
>- libvirt-fedora-28
>- libvirt-fedora-29
>- libvirt-fedora-rawhide
> -  - libvirt-freebsd-10
> -  - libvirt-freebsd-11
>- libvirt-ubuntu-16
>- libvirt-ubuntu-18
>  - include: '{{ playbook_base }}/jobs/autotools-check-job.yml'
> diff --git a/projects/libvirt-dbus.yaml b/projects/libvirt-dbus.yaml
> index 48bbdaa..49f5366 100644
> --- a/projects/libvirt-dbus.yaml
> +++ b/projects/libvirt-dbus.yaml
> @@ -19,14 +19,12 @@
>- autotools-syntax-check-job:
>parent_jobs: 'libvirt-dbus-build'
># CentOS 7 doesn't include Python 3 and the version of pyflakes
> -  # in FreeBSD CURRENT is too new to be used by flake8
> +  # in FreeBSD is too new to be used by flake8
>machines:
>  - libvirt-debian-9
>  - libvirt-fedora-28
>  - libvirt-fedora-29
>  - libvirt-fedora-rawhide
> -- libvirt-freebsd-10
> -- libvirt-freebsd-11
>- autotools-check-job:
>parent_jobs: 'libvirt-dbus-syntax-check'
># CentOS 7 doesn't include Python 3 and the version in Ubuntu
> -- 
> 2.19.1
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 14/15] Revert "lock_driver_lockd: Introduce VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA flag"

2018-11-14 Thread Michal Privoznik

This reverts commit 21c34b86be5233634eb38f77be64e2263bfc4e48.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_daemon_dispatch.c | 10 ++
 src/locking/lock_driver_lockd.c|  3 +--
 src/locking/lock_driver_lockd.h|  1 -
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/src/locking/lock_daemon_dispatch.c 
b/src/locking/lock_daemon_dispatch.c
index a683ad3d6b..10248ec0b5 100644
--- a/src/locking/lock_daemon_dispatch.c
+++ b/src/locking/lock_daemon_dispatch.c
@@ -37,9 +37,6 @@ VIR_LOG_INIT("locking.lock_daemon_dispatch");
 
 #include "lock_daemon_dispatch_stubs.h"
 
-#define DEFAULT_OFFSET 0
-#define METADATA_OFFSET 1
-
 static int
 virLockSpaceProtocolDispatchAcquireResource(virNetServerPtr server 
ATTRIBUTE_UNUSED,
 virNetServerClientPtr client,
@@ -53,14 +50,13 @@ virLockSpaceProtocolDispatchAcquireResource(virNetServerPtr 
server ATTRIBUTE_UNU
 virNetServerClientGetPrivateData(client);
 virLockSpacePtr lockspace;
 unsigned int newFlags;
-off_t start = DEFAULT_OFFSET;
+off_t start = 0;
 off_t len = 1;
 
 virMutexLock(>lock);
 
 virCheckFlagsGoto(VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA, 
cleanup);
+  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE, 
cleanup);
 
 if (priv->restricted) {
 virReportError(VIR_ERR_OPERATION_DENIED, "%s",
@@ -86,8 +82,6 @@ virLockSpaceProtocolDispatchAcquireResource(virNetServerPtr 
server ATTRIBUTE_UNU
 newFlags |= VIR_LOCK_SPACE_ACQUIRE_SHARED;
 if (flags & VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE)
 newFlags |= VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE;
-if (flags & VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA)
-start = METADATA_OFFSET;
 
 if (virLockSpaceAcquireResource(lockspace,
 args->name,
diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index ca825e6026..16fce551c3 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -723,8 +723,7 @@ static int 
virLockManagerLockDaemonRelease(virLockManagerPtr lock,
 
 args.flags &=
 ~(VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA);
+  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE);
 
 if (virNetClientProgramCall(program,
 client,
diff --git a/src/locking/lock_driver_lockd.h b/src/locking/lock_driver_lockd.h
index bebd804365..6931fe7425 100644
--- a/src/locking/lock_driver_lockd.h
+++ b/src/locking/lock_driver_lockd.h
@@ -25,7 +25,6 @@
 enum virLockSpaceProtocolAcquireResourceFlags {
 VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = (1 << 0),
 VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = (1 << 1),
-VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA = (1 << 2),
 };
 
 #endif /* __VIR_LOCK_DRIVER_LOCKD_H__ */
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 09/15] Revert "lock_manager: Allow disabling configFile for virLockManagerPluginNew"

2018-11-14 Thread Michal Privoznik

This reverts commit 35b5b244da825fb41e35e4dc62e740d716214ec9.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_driver.h |  4 
 src/locking/lock_driver_lockd.c   |  4 +---
 src/locking/lock_driver_sanlock.c |  4 +---
 src/locking/lock_manager.c| 10 +++---
 4 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/src/locking/lock_driver.h b/src/locking/lock_driver.h
index ae30abda7d..7c8f744be3 100644
--- a/src/locking/lock_driver.h
+++ b/src/locking/lock_driver.h
@@ -124,7 +124,6 @@ struct _virLockManagerParam {
 /**
  * virLockDriverInit:
  * @version: the libvirt requested plugin ABI version
- * @configFile: path to config file
  * @flags: the libvirt requested plugin optional extras
  *
  * Allow the plugin to validate the libvirt requested
@@ -132,9 +131,6 @@ struct _virLockManagerParam {
  * to block its use in versions of libvirtd which are
  * too old to support key features.
  *
- * The @configFile variable points to config file that the driver
- * should load. If NULL, no config file should be loaded.
- *
  * NB: A plugin may be loaded multiple times, for different
  * libvirt drivers (eg QEMU, LXC, UML)
  *
diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index 0c672b05b1..85cdcf97be 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -371,10 +371,8 @@ static int virLockManagerLockDaemonInit(unsigned int 
version,
 driver->requireLeaseForDisks = true;
 driver->autoDiskLease = true;
 
-if (configFile &&
-virLockManagerLockDaemonLoadConfig(configFile) < 0) {
+if (virLockManagerLockDaemonLoadConfig(configFile) < 0)
 goto error;
-}
 
 if (driver->autoDiskLease) {
 if (driver->fileLockSpaceDir &&
diff --git a/src/locking/lock_driver_sanlock.c 
b/src/locking/lock_driver_sanlock.c
index 3ad0dc9bed..b10d8197c5 100644
--- a/src/locking/lock_driver_sanlock.c
+++ b/src/locking/lock_driver_sanlock.c
@@ -446,10 +446,8 @@ static int virLockManagerSanlockInit(unsigned int version,
 goto error;
 }
 
-if (configFile &&
-virLockManagerSanlockLoadConfig(driver, configFile) < 0) {
+if (virLockManagerSanlockLoadConfig(driver, configFile) < 0)
 goto error;
-}
 
 if (driver->autoDiskLease && !driver->hostID) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
diff --git a/src/locking/lock_manager.c b/src/locking/lock_manager.c
index 9067f5a01a..d421b6acfc 100644
--- a/src/locking/lock_manager.c
+++ b/src/locking/lock_manager.c
@@ -104,8 +104,6 @@ static void virLockManagerLogParams(size_t nparams,
 /**
  * virLockManagerPluginNew:
  * @name: the name of the plugin
- * @driverName: the hypervisor driver that loads the plugin
- * @configDir: path to dir where config files are stored
  * @flag: optional plugin flags
  *
  * Attempt to load the plugin $(libdir)/libvirt/lock-driver/@name.so
@@ -131,13 +129,11 @@ virLockManagerPluginPtr virLockManagerPluginNew(const 
char *name,
 char *configFile = NULL;
 
 VIR_DEBUG("name=%s driverName=%s configDir=%s flags=0x%x",
-  name, NULLSTR(driverName), NULLSTR(configDir), flags);
+  name, driverName, configDir, flags);
 
-if (driverName && configDir &&
-virAsprintf(, "%s/%s-%s.conf",
-configDir, driverName, name) < 0) {
+if (virAsprintf(, "%s/%s-%s.conf",
+configDir, driverName, name) < 0)
 return NULL;
-}
 
 if (STREQ(name, "nop")) {
 driver = 
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 07/15] Revert "security_manager: Load lock plugin on init"

2018-11-14 Thread Michal Privoznik

This reverts commit 3e26b476b5f322353bf0dcd8e3f037ca672b8c62.

Signed-off-by: Michal Privoznik 
---
 cfg.mk   |  4 +---
 src/lxc/lxc_controller.c |  3 +--
 src/lxc/lxc_driver.c |  2 +-
 src/qemu/qemu_driver.c   |  3 ---
 src/security/security_manager.c  | 25 +
 src/security/security_manager.h  |  2 --
 tests/seclabeltest.c |  2 +-
 tests/securityselinuxlabeltest.c |  2 +-
 tests/securityselinuxtest.c  |  2 +-
 tests/testutilsqemu.c|  2 +-
 10 files changed, 8 insertions(+), 39 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index d0183c02ff..c83b152fda 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -787,10 +787,8 @@ sc_prohibit_cross_inclusion:
  case $$dir in \
util/) safe="util";; \
access/ | conf/) safe="($$dir|conf|util)";; \
-   cpu/| network/| node_device/| rpc/| storage/) \
+   cpu/| network/| node_device/| rpc/| security/| storage/) \
  safe="($$dir|util|conf|storage)";; \
-   security/) \
- safe="($$dir|util|conf|storage|locking)";; \
xenapi/ | xenconfig/ ) safe="($$dir|util|conf|xen|cpu)";; \
*) safe="($$dir|$(mid_dirs)|util)";; \
  esac; \
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 62dfd09473..e853d02d65 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -2624,8 +2624,7 @@ int main(int argc, char *argv[])
 ctrl->handshakeFd = handshakeFd;
 
 if (!(ctrl->securityManager = virSecurityManagerNew(securityDriver,
-LXC_DRIVER_NAME,
-NULL, 0)))
+LXC_DRIVER_NAME, 0)))
 goto cleanup;
 
 if (ctrl->def->seclabels) {
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index f732305649..990871d9b3 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -1531,7 +1531,7 @@ lxcSecurityInit(virLXCDriverConfigPtr cfg)
 flags |= VIR_SECURITY_MANAGER_REQUIRE_CONFINED;
 
 virSecurityManagerPtr mgr = virSecurityManagerNew(cfg->securityDriverName,
-  LXC_DRIVER_NAME, NULL, 
flags);
+  LXC_DRIVER_NAME, flags);
 if (!mgr)
 goto error;
 
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 09e04b8544..e387c831d4 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -350,7 +350,6 @@ qemuSecurityInit(virQEMUDriverPtr driver)
 while (names && *names) {
 if (!(mgr = qemuSecurityNew(*names,
 QEMU_DRIVER_NAME,
-cfg->metadataLockManagerName,
 flags)))
 goto error;
 if (!stack) {
@@ -366,7 +365,6 @@ qemuSecurityInit(virQEMUDriverPtr driver)
 } else {
 if (!(mgr = qemuSecurityNew(NULL,
 QEMU_DRIVER_NAME,
-cfg->metadataLockManagerName,
 flags)))
 goto error;
 if (!(stack = qemuSecurityNewStack(mgr)))
@@ -383,7 +381,6 @@ qemuSecurityInit(virQEMUDriverPtr driver)
cfg->user,
cfg->group,
flags,
-   cfg->metadataLockManagerName,
qemuSecurityChownCallback)))
 goto error;
 if (!stack) {
diff --git a/src/security/security_manager.c b/src/security/security_manager.c
index f527e6b5b3..a049382c7b 100644
--- a/src/security/security_manager.c
+++ b/src/security/security_manager.c
@@ -32,7 +32,6 @@
 #include "viralloc.h"
 #include "virobject.h"
 #include "virlog.h"
-#include "locking/lock_manager.h"
 #include "virfile.h"
 
 #define VIR_FROM_THIS VIR_FROM_SECURITY
@@ -46,8 +45,6 @@ struct _virSecurityManager {
 unsigned int flags;
 const char *virtDriver;
 void *privateData;
-
-virLockManagerPluginPtr lockPlugin;
 };
 
 static virClassPtr virSecurityManagerClass;
@@ -58,12 +55,8 @@ void virSecurityManagerDispose(void *obj)
 {
 virSecurityManagerPtr mgr = obj;
 
-if (mgr->drv &&
-mgr->drv->close)
+if (mgr->drv->close)
 mgr->drv->close(mgr);
-
-virObjectUnref(mgr->lockPlugin);
-
 VIR_FREE(mgr->privateData);
 }
 
@@ -83,7 +76,6 @@ VIR_ONCE_GLOBAL_INIT(virSecurityManager);
 static virSecurityManagerPtr
 virSecurityManagerNewDriver(virSecurityDriverPtr drv,
 const char *virtDriver,
-const char *lockManagerPluginName,
 unsigned int flags)
 {
 virSecurityManagerPtr mgr = NULL;
@@ -103,14 +95,6 @@

[libvirt] [PATCH v4 06/15] security_manager: Rework metadata locking

2018-11-14 Thread Michal Privoznik

Trying to use virlockd to lock metadata turns out to be too big
gun. Since we will always spawn a separate process for relabeling
we are safe to use thread unsafe POSIX locks and take out
virtlockd completely out of the picture.

Signed-off-by: Michal Privoznik 
---
 src/security/security_dac.c |  12 +-
 src/security/security_manager.c | 225 +---
 src/security/security_manager.h |  17 ++-
 src/security/security_selinux.c |  11 +-
 4 files changed, 141 insertions(+), 124 deletions(-)

diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index 0e100f7895..6b64d2c07a 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -205,6 +205,7 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
  void *opaque)
 {
 virSecurityDACChownListPtr list = opaque;
+virSecurityManagerMetadataLockStatePtr state;
 const char **paths = NULL;
 size_t npaths = 0;
 size_t i;
@@ -218,14 +219,10 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
 for (i = 0; i < list->nItems; i++) {
 const char *p = list->items[i]->path;
 
-if (!p ||
-virFileIsDir(p))
-continue;
-
 VIR_APPEND_ELEMENT_COPY_INPLACE(paths, npaths, p);
 }
 
-if (virSecurityManagerMetadataLock(list->manager, paths, npaths) < 0)
+if (!(state = virSecurityManagerMetadataLock(list->manager, paths, 
npaths)))
 goto cleanup;
 }
 
@@ -249,9 +246,8 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
 break;
 }
 
-if (list->lock &&
-virSecurityManagerMetadataUnlock(list->manager, paths, npaths) < 0)
-goto cleanup;
+if (list->lock)
+virSecurityManagerMetadataUnlock(list->manager, );
 
 if (rv < 0)
 goto cleanup;
diff --git a/src/security/security_manager.c b/src/security/security_manager.c
index 712b785ae9..f527e6b5b3 100644
--- a/src/security/security_manager.c
+++ b/src/security/security_manager.c
@@ -21,6 +21,10 @@
  */
 #include 
 
+#include 
+#include 
+#include 
+
 #include "security_driver.h"
 #include "security_stack.h"
 #include "security_dac.h"
@@ -30,14 +34,11 @@
 #include "virlog.h"
 #include "locking/lock_manager.h"
 #include "virfile.h"
-#include "virtime.h"
 
 #define VIR_FROM_THIS VIR_FROM_SECURITY
 
 VIR_LOG_INIT("security.security_manager");
 
-virMutex lockManagerMutex = VIR_MUTEX_INITIALIZER;
-
 struct _virSecurityManager {
 virObjectLockable parent;
 
@@ -47,10 +48,6 @@ struct _virSecurityManager {
 void *privateData;
 
 virLockManagerPluginPtr lockPlugin;
-/* This is a FD that represents a connection to virtlockd so
- * that connection is kept open in between MetdataLock() and
- * MetadataUnlock() calls. */
-int clientfd;
 };
 
 static virClassPtr virSecurityManagerClass;
@@ -66,7 +63,6 @@ void virSecurityManagerDispose(void *obj)
 mgr->drv->close(mgr);
 
 virObjectUnref(mgr->lockPlugin);
-VIR_FORCE_CLOSE(mgr->clientfd);
 
 VIR_FREE(mgr->privateData);
 }
@@ -119,7 +115,6 @@ virSecurityManagerNewDriver(virSecurityDriverPtr drv,
 mgr->flags = flags;
 mgr->virtDriver = virtDriver;
 VIR_STEAL_PTR(mgr->privateData, privateData);
-mgr->clientfd = -1;
 
 if (drv->open(mgr) < 0)
 goto error;
@@ -1281,129 +1276,153 @@ 
virSecurityManagerRestoreTPMLabels(virSecurityManagerPtr mgr,
 }
 
 
-static virLockManagerPtr
-virSecurityManagerNewLockManager(virSecurityManagerPtr mgr,
- const char * const *paths,
- size_t npaths)
+struct _virSecurityManagerMetadataLockState {
+size_t nfds;
+int *fds;
+};
+
+
+static int
+cmpstringp(const void *p1, const void *p2)
 {
-virLockManagerPtr lock;
-virLockManagerParam params[] = {
-{ .type = VIR_LOCK_MANAGER_PARAM_TYPE_UUID,
-.key = "uuid",
-},
-{ .type = VIR_LOCK_MANAGER_PARAM_TYPE_STRING,
-.key = "name",
-.value = { .cstr = "libvirtd-sec" },
-},
-{ .type = VIR_LOCK_MANAGER_PARAM_TYPE_UINT,
-.key = "pid",
-.value = { .iv = getpid() },
-},
-};
-const unsigned int flags = 0;
-size_t i;
+const char *s1 = *(char * const *) p1;
+const char *s2 = *(char * const *) p2;
 
-if (virGetHostUUID(params[0].value.uuid) < 0)
-return NULL;
+if (!s1 && !s2)
+return 0;
 
-if (!(lock = 
virLockManagerNew(virLockManagerPluginGetDriver(mgr->lockPlugin),
-   VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON,
-   ARRAY_CARDINALITY(params),
-   params,
-   flags)))
-return NULL;
+if (!s1 || !s2)
+return s2 ? -1 : 1;
 
-for (i = 0; i < npaths; i++) {
-if (virLockManagerAddResource(lock,
-

[libvirt] [PATCH v4 05/15] virSecurityManagerTransactionCommit: Do metadata locking iff enabled in config

2018-11-14 Thread Michal Privoznik

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_security.c| 73 -
 src/security/security_dac.c | 56 -
 src/security/security_driver.h  |  3 +-
 src/security/security_manager.c |  9 +++-
 src/security/security_manager.h |  3 +-
 src/security/security_selinux.c | 54 
 src/security/security_stack.c   |  5 ++-
 7 files changed, 140 insertions(+), 63 deletions(-)

diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c
index bf45abf93a..372bc53396 100644
--- a/src/qemu/qemu_security.c
+++ b/src/qemu/qemu_security.c
@@ -53,7 +53,8 @@ qemuSecuritySetAllLabel(virQEMUDriverPtr driver,
   priv->chardevStdioLogd) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto cleanup;
 
 ret = 0;
@@ -86,7 +87,8 @@ qemuSecurityRestoreAllLabel(virQEMUDriverPtr driver,
   priv->chardevStdioLogd);
 
 if (transactionStarted &&
-virSecurityManagerTransactionCommit(driver->securityManager, -1) < 0)
+virSecurityManagerTransactionCommit(driver->securityManager,
+-1, priv->rememberOwner) < 0)
 VIR_WARN("Unable to run security manager transaction");
 
 virSecurityManagerTransactionAbort(driver->securityManager);
@@ -98,6 +100,7 @@ qemuSecuritySetDiskLabel(virQEMUDriverPtr driver,
  virDomainObjPtr vm,
  virDomainDiskDefPtr disk)
 {
+qemuDomainObjPrivatePtr priv = vm->privateData;
 pid_t pid = -1;
 int ret = -1;
 
@@ -112,7 +115,8 @@ qemuSecuritySetDiskLabel(virQEMUDriverPtr driver,
disk) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto cleanup;
 
 ret = 0;
@@ -127,6 +131,7 @@ qemuSecurityRestoreDiskLabel(virQEMUDriverPtr driver,
  virDomainObjPtr vm,
  virDomainDiskDefPtr disk)
 {
+qemuDomainObjPrivatePtr priv = vm->privateData;
 pid_t pid = -1;
 int ret = -1;
 
@@ -141,7 +146,8 @@ qemuSecurityRestoreDiskLabel(virQEMUDriverPtr driver,
disk) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto cleanup;
 
 ret = 0;
@@ -156,6 +162,7 @@ qemuSecuritySetImageLabel(virQEMUDriverPtr driver,
   virDomainObjPtr vm,
   virStorageSourcePtr src)
 {
+qemuDomainObjPrivatePtr priv = vm->privateData;
 pid_t pid = -1;
 int ret = -1;
 
@@ -170,7 +177,8 @@ qemuSecuritySetImageLabel(virQEMUDriverPtr driver,
 src) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto cleanup;
 
 ret = 0;
@@ -185,6 +193,7 @@ qemuSecurityRestoreImageLabel(virQEMUDriverPtr driver,
   virDomainObjPtr vm,
   virStorageSourcePtr src)
 {
+qemuDomainObjPrivatePtr priv = vm->privateData;
 pid_t pid = -1;
 int ret = -1;
 
@@ -199,7 +208,8 @@ qemuSecurityRestoreImageLabel(virQEMUDriverPtr driver,
 src) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto cleanup;
 
 ret = 0;
@@ -214,6 +224,7 @@ qemuSecuritySetHostdevLabel(virQEMUDriverPtr driver,
 virDomainObjPtr vm,
 virDomainHostdevDefPtr hostdev)
 {
+qemuDomainObjPrivatePtr priv = vm->privateData;
 pid_t pid = -1;
 int ret = -1;
 
@@ -229,7 +240,8 @@ qemuSecuritySetHostdevLabel(virQEMUDriverPtr driver,
   NULL) < 0)
 goto cleanup;
 
-if (virSecurityManagerTransactionCommit(driver->securityManager, pid) < 0)
+if (virSecurityManagerTransactionCommit(driver->securityManager,
+pid, priv->rememberOwner) < 0)
 goto

[libvirt] [PATCH v4 13/15] Revert "lock_driver: Introduce new VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON"

2018-11-14 Thread Michal Privoznik

This reverts commit 22baf6e08c65d9174b24f66370724ce961ce9576.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_driver.h |   2 -
 src/locking/lock_driver_lockd.c   | 297 +++---
 src/locking/lock_driver_sanlock.c |  37 ++--
 3 files changed, 116 insertions(+), 220 deletions(-)

diff --git a/src/locking/lock_driver.h b/src/locking/lock_driver.h
index a9d2041c30..8b7521 100644
--- a/src/locking/lock_driver.h
+++ b/src/locking/lock_driver.h
@@ -42,8 +42,6 @@ typedef enum {
 typedef enum {
 /* The managed object is a virtual guest domain */
 VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN = 0,
-/* The managed object is a daemon (e.g. libvirtd) */
-VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON = 1,
 } virLockManagerObjectType;
 
 typedef enum {
diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index 22a5a97913..ca825e6026 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -56,21 +56,10 @@ struct _virLockManagerLockDaemonResource {
 };
 
 struct _virLockManagerLockDaemonPrivate {
-virLockManagerObjectType type;
-union {
-struct {
-unsigned char uuid[VIR_UUID_BUFLEN];
-char *name;
-int id;
-pid_t pid;
-} dom;
-
-struct {
-unsigned char uuid[VIR_UUID_BUFLEN];
-char *name;
-pid_t pid;
-} daemon;
-} t;
+unsigned char uuid[VIR_UUID_BUFLEN];
+char *name;
+int id;
+pid_t pid;
 
 size_t nresources;
 virLockManagerLockDaemonResourcePtr resources;
@@ -167,30 +156,10 @@ 
virLockManagerLockDaemonConnectionRegister(virLockManagerPtr lock,
 memset(, 0, sizeof(args));
 
 args.flags = 0;
-
-switch (priv->type) {
-case VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN:
-memcpy(args.owner.uuid, priv->t.dom.uuid, VIR_UUID_BUFLEN);
-args.owner.name = priv->t.dom.name;
-args.owner.id = priv->t.dom.id;
-args.owner.pid = priv->t.dom.pid;
-break;
-
-case VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON:
-memcpy(args.owner.uuid, priv->t.daemon.uuid, VIR_UUID_BUFLEN);
-args.owner.name = priv->t.daemon.name;
-args.owner.pid = priv->t.daemon.pid;
-/* This one should not be needed. However, virtlockd
- * checks for ID because not every domain has a PID. */
-args.owner.id = priv->t.daemon.pid;
-break;
-
-default:
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("Unknown lock manager object type %d"),
-   priv->type);
-return -1;
-}
+memcpy(args.owner.uuid, priv->uuid, VIR_UUID_BUFLEN);
+args.owner.name = priv->name;
+args.owner.id = priv->id;
+args.owner.pid = priv->pid;
 
 if (virNetClientProgramCall(program,
 client,
@@ -422,18 +391,7 @@ 
virLockManagerLockDaemonPrivateFree(virLockManagerLockDaemonPrivatePtr priv)
 }
 VIR_FREE(priv->resources);
 
-switch (priv->type) {
-case VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN:
-VIR_FREE(priv->t.dom.name);
-break;
-
-case VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON:
-VIR_FREE(priv->t.daemon.name);
-break;
-
-default:
-break;
-}
+VIR_FREE(priv->name);
 VIR_FREE(priv);
 }
 
@@ -462,82 +420,46 @@ static int virLockManagerLockDaemonNew(virLockManagerPtr 
lock,
 if (VIR_ALLOC(priv) < 0)
 return -1;
 
-priv->type = type;
-
-switch ((virLockManagerObjectType) type) {
+switch (type) {
 case VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN:
 for (i = 0; i < nparams; i++) {
 if (STREQ(params[i].key, "uuid")) {
-memcpy(priv->t.dom.uuid, params[i].value.uuid, 
VIR_UUID_BUFLEN);
+memcpy(priv->uuid, params[i].value.uuid, VIR_UUID_BUFLEN);
 } else if (STREQ(params[i].key, "name")) {
-if (VIR_STRDUP(priv->t.dom.name, params[i].value.str) < 0)
+if (VIR_STRDUP(priv->name, params[i].value.str) < 0)
 goto cleanup;
 } else if (STREQ(params[i].key, "id")) {
-priv->t.dom.id = params[i].value.iv;
+priv->id = params[i].value.iv;
 } else if (STREQ(params[i].key, "pid")) {
-priv->t.dom.pid = params[i].value.iv;
+priv->pid = params[i].value.iv;
 } else if (STREQ(params[i].key, "uri")) {
 /* ignored */
 } else {
 virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("Unexpected parameter %s for domain object"),
+   _("Unexpected parameter %s for object"),
params[i].key);
 goto cleanup;
 }
 }
-if (priv->t.dom.id == 0) {
+if (priv->id == 0) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",

[libvirt] [PATCH v4 12/15] Revert "_virLockManagerLockDaemonPrivate: Move @hasRWDisks into dom union"

2018-11-14 Thread Michal Privoznik

This reverts commit aaf34cb9013d6d746f4edf9807408cb9dfbcf01d.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_driver_lockd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index 268676c407..22a5a97913 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -63,8 +63,6 @@ struct _virLockManagerLockDaemonPrivate {
 char *name;
 int id;
 pid_t pid;
-
-bool hasRWDisks;
 } dom;
 
 struct {
@@ -76,6 +74,8 @@ struct _virLockManagerLockDaemonPrivate {
 
 size_t nresources;
 virLockManagerLockDaemonResourcePtr resources;
+
+bool hasRWDisks;
 };
 
 
@@ -585,7 +585,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 if (!driver->autoDiskLease) {
 if (!(flags & (VIR_LOCK_MANAGER_RESOURCE_SHARED |
VIR_LOCK_MANAGER_RESOURCE_READONLY)))
-priv->t.dom.hasRWDisks = true;
+priv->hasRWDisks = true;
 return 0;
 }
 
@@ -731,7 +731,7 @@ static int 
virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
 
 if (priv->type == VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN &&
 priv->nresources == 0 &&
-priv->t.dom.hasRWDisks &&
+priv->hasRWDisks &&
 driver->requireLeaseForDisks) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("Read/write, exclusive access, disks were present, 
but no leases specified"));
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 15/15] Revert "virlockspace: Allow caller to specify start and length offset in virLockSpaceAcquireResource"

2018-11-14 Thread Michal Privoznik

This reverts commit afd5a27575e8b6a494d2728552fe0e89c71e32b4.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_daemon_dispatch.c |  3 ---
 src/util/virlockspace.c| 15 +--
 src/util/virlockspace.h|  4 
 tests/virlockspacetest.c   | 29 +
 4 files changed, 10 insertions(+), 41 deletions(-)

diff --git a/src/locking/lock_daemon_dispatch.c 
b/src/locking/lock_daemon_dispatch.c
index 10248ec0b5..1b479db55d 100644
--- a/src/locking/lock_daemon_dispatch.c
+++ b/src/locking/lock_daemon_dispatch.c
@@ -50,8 +50,6 @@ virLockSpaceProtocolDispatchAcquireResource(virNetServerPtr 
server ATTRIBUTE_UNU
 virNetServerClientGetPrivateData(client);
 virLockSpacePtr lockspace;
 unsigned int newFlags;
-off_t start = 0;
-off_t len = 1;
 
 virMutexLock(>lock);
 
@@ -86,7 +84,6 @@ virLockSpaceProtocolDispatchAcquireResource(virNetServerPtr 
server ATTRIBUTE_UNU
 if (virLockSpaceAcquireResource(lockspace,
 args->name,
 priv->ownerPid,
-start, len,
 newFlags) < 0)
 goto cleanup;
 
diff --git a/src/util/virlockspace.c b/src/util/virlockspace.c
index 79fa48d365..0736b4b85b 100644
--- a/src/util/virlockspace.c
+++ b/src/util/virlockspace.c
@@ -115,10 +115,8 @@ static void 
virLockSpaceResourceFree(virLockSpaceResourcePtr res)
 static virLockSpaceResourcePtr
 virLockSpaceResourceNew(virLockSpacePtr lockspace,
 const char *resname,
-pid_t owner,
-off_t start,
-off_t len,
-unsigned int flags)
+unsigned int flags,
+pid_t owner)
 {
 virLockSpaceResourcePtr res;
 bool shared = !!(flags & VIR_LOCK_SPACE_ACQUIRE_SHARED);
@@ -159,7 +157,7 @@ virLockSpaceResourceNew(virLockSpacePtr lockspace,
 goto error;
 }
 
-if (virFileLock(res->fd, shared, start, len, false) < 0) {
+if (virFileLock(res->fd, shared, 0, 1, false) < 0) {
 if (errno == EACCES || errno == EAGAIN) {
 virReportError(VIR_ERR_RESOURCE_BUSY,
_("Lockspace resource '%s' is locked"),
@@ -206,7 +204,7 @@ virLockSpaceResourceNew(virLockSpacePtr lockspace,
 goto error;
 }
 
-if (virFileLock(res->fd, shared, start, len, false) < 0) {
+if (virFileLock(res->fd, shared, 0, 1, false) < 0) {
 if (errno == EACCES || errno == EAGAIN) {
 virReportError(VIR_ERR_RESOURCE_BUSY,
_("Lockspace resource '%s' is locked"),
@@ -614,8 +612,6 @@ int virLockSpaceDeleteResource(virLockSpacePtr lockspace,
 int virLockSpaceAcquireResource(virLockSpacePtr lockspace,
 const char *resname,
 pid_t owner,
-off_t start,
-off_t len,
 unsigned int flags)
 {
 int ret = -1;
@@ -645,8 +641,7 @@ int virLockSpaceAcquireResource(virLockSpacePtr lockspace,
 goto cleanup;
 }
 
-if (!(res = virLockSpaceResourceNew(lockspace, resname,
-owner, start, len, flags)))
+if (!(res = virLockSpaceResourceNew(lockspace, resname, flags, owner)))
 goto cleanup;
 
 if (virHashAddEntry(lockspace->resources, resname, res) < 0) {
diff --git a/src/util/virlockspace.h b/src/util/virlockspace.h
index 24f2c89be6..041cf20396 100644
--- a/src/util/virlockspace.h
+++ b/src/util/virlockspace.h
@@ -22,8 +22,6 @@
 #ifndef __VIR_LOCK_SPACE_H__
 # define __VIR_LOCK_SPACE_H__
 
-# include 
-
 # include "internal.h"
 # include "virjson.h"
 
@@ -52,8 +50,6 @@ typedef enum {
 int virLockSpaceAcquireResource(virLockSpacePtr lockspace,
 const char *resname,
 pid_t owner,
-off_t start,
-off_t len,
 unsigned int flags);
 
 int virLockSpaceReleaseResource(virLockSpacePtr lockspace,
diff --git a/tests/virlockspacetest.c b/tests/virlockspacetest.c
index 3c621e7eb0..93353be285 100644
--- a/tests/virlockspacetest.c
+++ b/tests/virlockspacetest.c
@@ -98,8 +98,6 @@ static int testLockSpaceResourceLockExcl(const void *args 
ATTRIBUTE_UNUSED)
 {
 virLockSpacePtr lockspace;
 int ret = -1;
-const off_t start = 0;
-const off_t len = 1;
 
 rmdir(LOCKSPACE_DIR);
 
@@ -112,13 +110,13 @@ static int testLockSpaceResourceLockExcl(const void *args 
ATTRIBUTE_UNUSED)
 if (virLockSpaceCreateResource(lockspace, "foo") < 0)
 goto cleanup;
 
-if (virLockSpaceAcquireResource(lockspace, "foo", geteuid(), start, len, 
0)

[libvirt] [PATCH v4 10/15] Revert "lock_driver: Introduce VIR_LOCK_MANAGER_ACQUIRE_ROLLBACK"

2018-11-14 Thread Michal Privoznik

This reverts commit 385eb8399bdb1610447c2857abfe99cee4a9fb9e.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_driver.h   |  4 --
 src/locking/lock_driver_lockd.c | 82 ++---
 2 files changed, 24 insertions(+), 62 deletions(-)

diff --git a/src/locking/lock_driver.h b/src/locking/lock_driver.h
index 7c8f744be3..9be0abcfba 100644
--- a/src/locking/lock_driver.h
+++ b/src/locking/lock_driver.h
@@ -67,10 +67,6 @@ typedef enum {
 VIR_LOCK_MANAGER_ACQUIRE_REGISTER_ONLY = (1 << 0),
 /* Prevent further lock/unlock calls from this process */
 VIR_LOCK_MANAGER_ACQUIRE_RESTRICT = (1 << 1),
-/* Used when acquiring more resources in which one of them
- * can't be acquired, perform a rollback and release all
- * resources acquired so far. */
-VIR_LOCK_MANAGER_ACQUIRE_ROLLBACK = (1 << 2),
 } virLockManagerAcquireFlags;
 
 typedef enum {
diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index 85cdcf97be..d6551e125c 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -735,34 +735,6 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 }
 
 
-static int virLockManagerLockDaemonReleaseImpl(virNetClientPtr client,
-   virNetClientProgramPtr program,
-   int counter,
-   
virLockManagerLockDaemonResourcePtr res)
-{
-virLockSpaceProtocolReleaseResourceArgs args;
-
-memset(, 0, sizeof(args));
-
-args.path = res->lockspace;
-args.name = res->name;
-args.flags = res->flags;
-
-args.flags &=
-~(VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE |
-  VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA);
-
-return virNetClientProgramCall(program,
-   client,
-   counter,
-   
VIR_LOCK_SPACE_PROTOCOL_PROC_RELEASE_RESOURCE,
-   0, NULL, NULL, NULL,
-   
(xdrproc_t)xdr_virLockSpaceProtocolReleaseResourceArgs, ,
-   (xdrproc_t)xdr_void, NULL);
-}
-
-
 static int virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
const char *state ATTRIBUTE_UNUSED,
unsigned int flags,
@@ -773,13 +745,10 @@ static int 
virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
 virNetClientProgramPtr program = NULL;
 int counter = 0;
 int rv = -1;
-ssize_t i;
-ssize_t lastGood = -1;
 virLockManagerLockDaemonPrivatePtr priv = lock->privateData;
 
 virCheckFlags(VIR_LOCK_MANAGER_ACQUIRE_REGISTER_ONLY |
-  VIR_LOCK_MANAGER_ACQUIRE_RESTRICT |
-  VIR_LOCK_MANAGER_ACQUIRE_ROLLBACK, -1);
+  VIR_LOCK_MANAGER_ACQUIRE_RESTRICT, -1);
 
 if (priv->type == VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN &&
 priv->nresources == 0 &&
@@ -798,6 +767,7 @@ static int 
virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
 goto cleanup;
 
 if (!(flags & VIR_LOCK_MANAGER_ACQUIRE_REGISTER_ONLY)) {
+size_t i;
 for (i = 0; i < priv->nresources; i++) {
 virLockSpaceProtocolAcquireResourceArgs args;
 
@@ -815,7 +785,6 @@ static int 
virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
 
(xdrproc_t)xdr_virLockSpaceProtocolAcquireResourceArgs, ,
 (xdrproc_t)xdr_void, NULL) < 0)
 goto cleanup;
-lastGood = i;
 }
 }
 
@@ -826,28 +795,8 @@ static int 
virLockManagerLockDaemonAcquire(virLockManagerPtr lock,
 rv = 0;
 
  cleanup:
-if (rv < 0) {
-int saved_errno = errno;
-virErrorPtr origerr;
-
-virErrorPreserveLast();
-if (fd)
-VIR_FORCE_CLOSE(*fd);
-
-if (flags & VIR_LOCK_MANAGER_ACQUIRE_ROLLBACK) {
-for (i = lastGood; i >= 0; i--) {
-virLockManagerLockDaemonResourcePtr res = >resources[i];
-
-if (virLockManagerLockDaemonReleaseImpl(client, program,
-counter++, res) < 0)
-VIR_WARN("Unable to release resource lockspace=%s name=%s",
- res->lockspace, res->name);
-}
-}
-
-virErrorRestore();
-errno = saved_errno;
-}
+if (rv != 0 && fd)
+VIR_FORCE_CLOSE(*fd);
 virNetClientClose(client);
 virObjectUnref(client);
 virObjectUnref(program);
@@ -875,10 +824,27 @@ static int 
virLockManagerLockDaemonRelease(virLockManagerPtr lock,
 goto cleanup;
 
 for (i = 0; i < priv->nresources; i++) {
-

[libvirt] [PATCH v4 08/15] Revert "qemu_conf: Introduce metadata_lock_manager"

2018-11-14 Thread Michal Privoznik

This reverts commit 8b8aefb3d6ae2139ea3d4ef6d7dd2c06f57f6075.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_conf.c | 1 -
 src/qemu/qemu_conf.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 17b7e11e02..32da9a7351 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -426,7 +426,6 @@ static void virQEMUDriverConfigDispose(void *obj)
 virStringListFree(cfg->securityDriverNames);
 
 VIR_FREE(cfg->lockManagerName);
-VIR_FREE(cfg->metadataLockManagerName);
 
 virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
 
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 0b5b5a314f..8986350fad 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -187,7 +187,6 @@ struct _virQEMUDriverConfig {
 bool autoStartBypassCache;
 
 char *lockManagerName;
-char *metadataLockManagerName;
 
 int keepAliveInterval;
 unsigned int keepAliveCount;
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 00/15] Implement alternative metadata locking

2018-11-14 Thread Michal Privoznik

v4 of:

https://www.redhat.com/archives/libvir-list/2018-October/msg00861.html

diff to v3:
- Introduced a config knob to enable/disable metadata locking (except
  not really). We want to have a knob that enables/disables remembering
  of original owner. This knob in turn enables metadata locking. The
  reason is that metadata locking on its own doesn't make any sense.
  Anyway, the qemu.conf change is not done (it'll be done in upcoming
  patch set that implements original owner remembering), so if you want
  to see these patches in action you'll need to apply the following
  patch:

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 32da9a7351..0080b0d021 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -347,6 +347,8 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
privileged)
 if (!(cfg->namespaces = virBitmapNew(QEMU_DOMAIN_NS_LAST)))
 goto error;
 
+cfg->rememberOwner = true;
+
 if (privileged &&
 qemuDomainNamespaceAvailable(QEMU_DOMAIN_NS_MOUNT) &&
 virBitmapSetBit(cfg->namespaces, QEMU_DOMAIN_NS_MOUNT) < 0)


- I've fixed small issues raised in review of v3.
Note that patches 01 and 02 are ACKed already but I'm sending them for
completeness (probably doesn't make much sense to merge them while this
is still under review, does it?).


Michal Prívozník (15):
  virprocess: Introduce virProcessRunInFork
  virprocess: Make virProcessRunInMountNamespace use virProcessRunInFork
  qemu_tpm: Pass virDomainObjPtr instead of virDomainDefPtr
  qemu_domain: Track if domain remembers original owner
  virSecurityManagerTransactionCommit: Do metadata locking iff enabled
in config
  security_manager: Rework metadata locking
  Revert "security_manager: Load lock plugin on init"
  Revert "qemu_conf: Introduce metadata_lock_manager"
  Revert "lock_manager: Allow disabling configFile for
virLockManagerPluginNew"
  Revert "lock_driver: Introduce VIR_LOCK_MANAGER_ACQUIRE_ROLLBACK"
  Revert "lock_driver: Introduce
VIR_LOCK_MANAGER_RESOURCE_TYPE_METADATA"
  Revert "_virLockManagerLockDaemonPrivate: Move @hasRWDisks into dom
union"
  Revert "lock_driver: Introduce new
VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON"
  Revert "lock_driver_lockd: Introduce
VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA flag"
  Revert "virlockspace: Allow caller to specify start and length offset
in virLockSpaceAcquireResource"

 cfg.mk |   4 +-
 src/libvirt_private.syms   |   1 +
 src/locking/lock_daemon_dispatch.c |  11 +-
 src/locking/lock_driver.h  |  12 -
 src/locking/lock_driver_lockd.c| 421 ++---
 src/locking/lock_driver_lockd.h|   1 -
 src/locking/lock_driver_sanlock.c  |  44 +--
 src/locking/lock_manager.c |  10 +-
 src/lxc/lxc_controller.c   |   3 +-
 src/lxc/lxc_driver.c   |   2 +-
 src/qemu/qemu_conf.c   |   1 -
 src/qemu/qemu_conf.h   |   2 +-
 src/qemu/qemu_domain.c |   7 +
 src/qemu/qemu_domain.h |   3 +
 src/qemu/qemu_driver.c |   3 -
 src/qemu/qemu_extdevice.c  |  16 +-
 src/qemu/qemu_extdevice.h  |   4 +-
 src/qemu/qemu_process.c|   9 +-
 src/qemu/qemu_security.c   |  87 --
 src/qemu/qemu_security.h   |   4 +-
 src/qemu/qemu_tpm.c|  24 +-
 src/qemu/qemu_tpm.h|   4 +-
 src/security/security_dac.c|  54 ++--
 src/security/security_driver.h |   3 +-
 src/security/security_manager.c| 259 +-
 src/security/security_manager.h|  22 +-
 src/security/security_selinux.c|  53 ++--
 src/security/security_stack.c  |   5 +-
 src/util/virlockspace.c|  15 +-
 src/util/virlockspace.h|   4 -
 src/util/virprocess.c  |  82 --
 src/util/virprocess.h  |  16 ++
 tests/seclabeltest.c   |   2 +-
 tests/securityselinuxlabeltest.c   |   2 +-
 tests/securityselinuxtest.c|   2 +-
 tests/testutilsqemu.c  |   2 +-
 tests/virlockspacetest.c   |  29 +-
 37 files changed, 573 insertions(+), 650 deletions(-)

-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 11/15] Revert "lock_driver: Introduce VIR_LOCK_MANAGER_RESOURCE_TYPE_METADATA"

2018-11-14 Thread Michal Privoznik

This reverts commit 997283b54b0e1f599aed3085ceba027eb8110acb.

Signed-off-by: Michal Privoznik 
---
 src/locking/lock_driver.h |  2 --
 src/locking/lock_driver_lockd.c   | 47 +--
 src/locking/lock_driver_sanlock.c |  3 +-
 3 files changed, 14 insertions(+), 38 deletions(-)

diff --git a/src/locking/lock_driver.h b/src/locking/lock_driver.h
index 9be0abcfba..a9d2041c30 100644
--- a/src/locking/lock_driver.h
+++ b/src/locking/lock_driver.h
@@ -51,8 +51,6 @@ typedef enum {
 VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK = 0,
 /* A lease against an arbitrary resource */
 VIR_LOCK_MANAGER_RESOURCE_TYPE_LEASE = 1,
-/* The resource to be locked is a metadata */
-VIR_LOCK_MANAGER_RESOURCE_TYPE_METADATA = 2,
 } virLockManagerResourceType;
 
 typedef enum {
diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c
index d6551e125c..268676c407 100644
--- a/src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -563,7 +563,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 virLockManagerLockDaemonPrivatePtr priv = lock->privateData;
 char *newName = NULL;
 char *newLockspace = NULL;
-int newFlags = 0;
+bool autoCreate = false;
 int ret = -1;
 
 virCheckFlags(VIR_LOCK_MANAGER_RESOURCE_READONLY |
@@ -575,7 +575,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 switch (priv->type) {
 case VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN:
 
-switch ((virLockManagerResourceType) type) {
+switch (type) {
 case VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK:
 if (params || nparams) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
@@ -602,7 +602,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 VIR_DEBUG("Got an LVM UUID %s for %s", newName, name);
 if (VIR_STRDUP(newLockspace, driver->lvmLockSpaceDir) < 0)
 goto cleanup;
-newFlags |= 
VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE;
+autoCreate = true;
 break;
 }
 virResetLastError();
@@ -619,7 +619,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 VIR_DEBUG("Got an SCSI ID %s for %s", newName, name);
 if (VIR_STRDUP(newLockspace, driver->scsiLockSpaceDir) < 0)
 goto cleanup;
-newFlags |= 
VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE;
+autoCreate = true;
 break;
 }
 virResetLastError();
@@ -631,7 +631,7 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 goto cleanup;
 if (virCryptoHashString(VIR_CRYPTO_HASH_SHA256, name, 
) < 0)
 goto cleanup;
-newFlags |= 
VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE;
+autoCreate = true;
 VIR_DEBUG("Using indirect lease %s for %s", newName, name);
 } else {
 if (VIR_STRDUP(newLockspace, "") < 0)
@@ -676,8 +676,6 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 goto cleanup;
 
 }   break;
-
-case VIR_LOCK_MANAGER_RESOURCE_TYPE_METADATA:
 default:
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("Unknown lock manager object type %d for domain 
lock object"),
@@ -687,29 +685,6 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 break;
 
 case VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON:
-switch ((virLockManagerResourceType) type) {
-case VIR_LOCK_MANAGER_RESOURCE_TYPE_METADATA:
-if (params || nparams) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("Unexpected parameters for metadata 
resource"));
-goto cleanup;
-}
-if (VIR_STRDUP(newLockspace, "") < 0 ||
-VIR_STRDUP(newName, name) < 0)
-goto cleanup;
-newFlags |= VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_METADATA;
-break;
-
-case VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK:
-case VIR_LOCK_MANAGER_RESOURCE_TYPE_LEASE:
-default:
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("Unknown lock manager object type %d for daemon 
lock object"),
-   type);
-goto cleanup;
-}
-break;
-
 default:
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("Unknown lock manager object type %d"),
@@ -717,15 +692,19 @@ static int 
virLockManagerLockDaemonAddResource(virLockManagerPtr lock,
 goto cleanup;
 }
 
-if (flags &

[libvirt] [PATCH v4 03/15] qemu_tpm: Pass virDomainObjPtr instead of virDomainDefPtr

2018-11-14 Thread Michal Privoznik

The TPM code currently accepts pointer to a domain definition.
This is okay for now, but in near future the security driver APIs
it calls will require domain object. Therefore, change the TPM
code to accept the domain object pointer.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_extdevice.c | 16 
 src/qemu/qemu_extdevice.h |  4 ++--
 src/qemu/qemu_process.c   |  6 +++---
 src/qemu/qemu_security.c  | 14 +++---
 src/qemu/qemu_security.h  |  4 ++--
 src/qemu/qemu_tpm.c   | 24 
 src/qemu/qemu_tpm.h   |  4 ++--
 7 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
index d982922470..27cf118c14 100644
--- a/src/qemu/qemu_extdevice.c
+++ b/src/qemu/qemu_extdevice.c
@@ -129,16 +129,16 @@ qemuExtDevicesCleanupHost(virQEMUDriverPtr driver,
 
 int
 qemuExtDevicesStart(virQEMUDriverPtr driver,
-virDomainDefPtr def,
+virDomainObjPtr vm,
 qemuDomainLogContextPtr logCtxt)
 {
 int ret = 0;
 
-if (qemuExtDevicesInitPaths(driver, def) < 0)
+if (qemuExtDevicesInitPaths(driver, vm->def) < 0)
 return -1;
 
-if (def->tpm)
-ret = qemuExtTPMStart(driver, def, logCtxt);
+if (vm->def->tpm)
+ret = qemuExtTPMStart(driver, vm, logCtxt);
 
 return ret;
 }
@@ -146,13 +146,13 @@ qemuExtDevicesStart(virQEMUDriverPtr driver,
 
 void
 qemuExtDevicesStop(virQEMUDriverPtr driver,
-   virDomainDefPtr def)
+   virDomainObjPtr vm)
 {
-if (qemuExtDevicesInitPaths(driver, def) < 0)
+if (qemuExtDevicesInitPaths(driver, vm->def) < 0)
 return;
 
-if (def->tpm)
-qemuExtTPMStop(driver, def);
+if (vm->def->tpm)
+qemuExtTPMStop(driver, vm);
 }
 
 
diff --git a/src/qemu/qemu_extdevice.h b/src/qemu/qemu_extdevice.h
index c557778ddb..c26cdd50b2 100644
--- a/src/qemu/qemu_extdevice.h
+++ b/src/qemu/qemu_extdevice.h
@@ -41,13 +41,13 @@ void qemuExtDevicesCleanupHost(virQEMUDriverPtr driver,
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 int qemuExtDevicesStart(virQEMUDriverPtr driver,
-virDomainDefPtr def,
+virDomainObjPtr vm,
 qemuDomainLogContextPtr logCtxt)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3)
 ATTRIBUTE_RETURN_CHECK;
 
 void qemuExtDevicesStop(virQEMUDriverPtr driver,
-virDomainDefPtr def)
+virDomainObjPtr vm)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 bool qemuExtDevicesHasDevice(virDomainDefPtr def);
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 1850923914..2c9e605047 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -6392,7 +6392,7 @@ qemuProcessLaunch(virConnectPtr conn,
 if (qemuProcessGenID(vm, flags) < 0)
 goto cleanup;
 
-if (qemuExtDevicesStart(driver, vm->def, logCtxt) < 0)
+if (qemuExtDevicesStart(driver, vm, logCtxt) < 0)
 goto cleanup;
 
 VIR_DEBUG("Building emulator command line");
@@ -6648,7 +6648,7 @@ qemuProcessLaunch(virConnectPtr conn,
 
  cleanup:
 if (ret < 0)
-qemuExtDevicesStop(driver, vm->def);
+qemuExtDevicesStop(driver, vm);
 qemuDomainSecretDestroy(vm);
 virCommandFree(cmd);
 virObjectUnref(logCtxt);
@@ -7079,7 +7079,7 @@ void qemuProcessStop(virQEMUDriverPtr driver,
 
 qemuDomainCleanupRun(driver, vm);
 
-qemuExtDevicesStop(driver, vm->def);
+qemuExtDevicesStop(driver, vm);
 
 /* Stop autodestroy in case guest is restarted */
 qemuProcessAutoDestroyRemove(driver, vm);
diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c
index 34921b4046..bf45abf93a 100644
--- a/src/qemu/qemu_security.c
+++ b/src/qemu/qemu_security.c
@@ -453,7 +453,7 @@ qemuSecurityRestoreChardevLabel(virQEMUDriverPtr driver,
  * qemuSecurityStartTPMEmulator:
  *
  * @driver: the QEMU driver
- * @def: the domain definition
+ * @vm: the domain object
  * @cmd: the command to run
  * @uid: the uid to run the emulator
  * @gid: the gid to run the emulator
@@ -469,7 +469,7 @@ qemuSecurityRestoreChardevLabel(virQEMUDriverPtr driver,
  */
 int
 qemuSecurityStartTPMEmulator(virQEMUDriverPtr driver,
- virDomainDefPtr def,
+ virDomainObjPtr vm,
  virCommandPtr cmd,
  uid_t uid,
  gid_t gid,
@@ -484,7 +484,7 @@ qemuSecurityStartTPMEmulator(virQEMUDriverPtr driver,
 transactionStarted = true;
 
 if (virSecurityManagerSetTPMLabels(driver->securityManager,
-   def) < 0) {
+   vm->def) < 0) {
 virSecurityManagerTransactionAbort(driver->securityManager);
 return -1;
 }
@@ -494,7 +494,7 @@ qemuSecurityStartTPMEmulator(virQEMUDriverPtr

[libvirt] [PATCH v4 02/15] virprocess: Make virProcessRunInMountNamespace use virProcessRunInFork

2018-11-14 Thread Michal Privoznik

Both virProcessRunInMountNamespace() and virProcessRunInFork()
look very similar. De-duplicate the code and make
virProcessRunInMountNamespace() call virProcessRunInFork().

Signed-off-by: Michal Privoznik 
Reviewed-by: John Ferlan 
---
 src/util/virprocess.c | 64 +--
 1 file changed, 13 insertions(+), 51 deletions(-)

diff --git a/src/util/virprocess.c b/src/util/virprocess.c
index 17e7cfa4ee..87f32464db 100644
--- a/src/util/virprocess.c
+++ b/src/util/virprocess.c
@@ -1073,16 +1073,22 @@ int virProcessGetStartTime(pid_t pid,
 #endif
 
 
-static int virProcessNamespaceHelper(int errfd,
- pid_t pid,
- virProcessNamespaceCallback cb,
+typedef struct _virProcessNamespaceHelperData virProcessNamespaceHelperData;
+struct _virProcessNamespaceHelperData {
+pid_t pid;
+virProcessNamespaceCallback cb;
+void *opaque;
+};
+
+static int virProcessNamespaceHelper(pid_t pid ATTRIBUTE_UNUSED,
  void *opaque)
 {
+virProcessNamespaceHelperData *data = opaque;
 int fd = -1;
 int ret = -1;
 VIR_AUTOFREE(char *) path = NULL;
 
-if (virAsprintf(, "/proc/%lld/ns/mnt", (long long) pid) < 0)
+if (virAsprintf(, "/proc/%lld/ns/mnt", (long long) data->pid) < 0)
 goto cleanup;
 
 if ((fd = open(path, O_RDONLY)) < 0) {
@@ -1097,16 +1103,9 @@ static int virProcessNamespaceHelper(int errfd,
 goto cleanup;
 }
 
-ret = cb(pid, opaque);
+ret = data->cb(data->pid, data->opaque);
 
  cleanup:
-if (ret < 0) {
-virErrorPtr err = virGetLastError();
-if (err) {
-size_t len = strlen(err->message) + 1;
-ignore_value(safewrite(errfd, err->message, len));
-}
-}
 VIR_FORCE_CLOSE(fd);
 return ret;
 }
@@ -1122,46 +1121,9 @@ virProcessRunInMountNamespace(pid_t pid,
   virProcessNamespaceCallback cb,
   void *opaque)
 {
-int ret = -1;
-pid_t child = -1;
-int errfd[2] = { -1, -1 };
+virProcessNamespaceHelperData data = {.pid = pid, .cb = cb, .opaque = 
opaque};
 
-if (pipe2(errfd, O_CLOEXEC) < 0) {
-virReportSystemError(errno, "%s",
- _("Cannot create pipe for child"));
-return -1;
-}
-
-if ((child = virFork()) < 0)
-goto cleanup;
-
-if (child == 0) {
-VIR_FORCE_CLOSE(errfd[0]);
-ret = virProcessNamespaceHelper(errfd[1], pid,
-cb, opaque);
-VIR_FORCE_CLOSE(errfd[1]);
-_exit(ret < 0 ? EXIT_CANCELED : ret);
-} else {
-int status;
-VIR_AUTOFREE(char *) buf = NULL;
-
-VIR_FORCE_CLOSE(errfd[1]);
-ignore_value(virFileReadHeaderFD(errfd[0], 1024, ));
-ret = virProcessWait(child, , false);
-if (!ret) {
-ret = status == EXIT_CANCELED ? -1 : status;
-if (ret) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("child reported: %s"),
-   NULLSTR(buf));
-}
-}
-}
-
- cleanup:
-VIR_FORCE_CLOSE(errfd[0]);
-VIR_FORCE_CLOSE(errfd[1]);
-return ret;
+return virProcessRunInFork(virProcessNamespaceHelper, );
 }
 
 
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH] Don't run libvirt-dbus-syntax-check on FreeBSD

2018-11-14 Thread Andrea Bolognani

flake8 wants 'pyflakes<1.7.0,>=1.5.0', but all FreeBSD
releases ship pyflakes 2.0.0 these days.

Signed-off-by: Andrea Bolognani 
---
 guests/playbooks/build/projects/libvirt-dbus.yml | 4 +---
 projects/libvirt-dbus.yaml   | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml 
b/guests/playbooks/build/projects/libvirt-dbus.yml
index 1d4ecbd..61ece63 100644
--- a/guests/playbooks/build/projects/libvirt-dbus.yml
+++ b/guests/playbooks/build/projects/libvirt-dbus.yml
@@ -22,15 +22,13 @@
 - include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml'
   vars:
 # CentOS 7 doesn't include Python 3 and the version of pyflakes
-# in FreeBSD CURRENT is too new to be used by flake8
+# in FreeBSD is too new to be used by flake8
 machines:
   - libvirt-debian-9
   - libvirt-debian-sid
   - libvirt-fedora-28
   - libvirt-fedora-29
   - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - libvirt-freebsd-11
   - libvirt-ubuntu-16
   - libvirt-ubuntu-18
 - include: '{{ playbook_base }}/jobs/autotools-check-job.yml'
diff --git a/projects/libvirt-dbus.yaml b/projects/libvirt-dbus.yaml
index 48bbdaa..49f5366 100644
--- a/projects/libvirt-dbus.yaml
+++ b/projects/libvirt-dbus.yaml
@@ -19,14 +19,12 @@
   - autotools-syntax-check-job:
   parent_jobs: 'libvirt-dbus-build'
   # CentOS 7 doesn't include Python 3 and the version of pyflakes
-  # in FreeBSD CURRENT is too new to be used by flake8
+  # in FreeBSD is too new to be used by flake8
   machines:
 - libvirt-debian-9
 - libvirt-fedora-28
 - libvirt-fedora-29
 - libvirt-fedora-rawhide
-- libvirt-freebsd-10
-- libvirt-freebsd-11
   - autotools-check-job:
   parent_jobs: 'libvirt-dbus-syntax-check'
   # CentOS 7 doesn't include Python 3 and the version in Ubuntu
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 01/15] virprocess: Introduce virProcessRunInFork

2018-11-14 Thread Michal Privoznik

This new helper can be used to spawn a child process and run
passed callback from it. This will come handy esp. if the
callback is not thread safe.

Signed-off-by: Michal Privoznik 
Reviewed-by: John Ferlan 
---
 src/libvirt_private.syms |  1 +
 src/util/virprocess.c| 86 
 src/util/virprocess.h| 16 
 3 files changed, 103 insertions(+)

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 2343a757c1..7906d90f24 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2626,6 +2626,7 @@ virProcessKill;
 virProcessKillPainfully;
 virProcessKillPainfullyDelay;
 virProcessNamespaceAvailable;
+virProcessRunInFork;
 virProcessRunInMountNamespace;
 virProcessSchedPolicyTypeFromString;
 virProcessSchedPolicyTypeToString;
diff --git a/src/util/virprocess.c b/src/util/virprocess.c
index 3883c708fc..17e7cfa4ee 100644
--- a/src/util/virprocess.c
+++ b/src/util/virprocess.c
@@ -1165,6 +1165,92 @@ virProcessRunInMountNamespace(pid_t pid,
 }
 
 
+static int
+virProcessRunInForkHelper(int errfd,
+  pid_t ppid,
+  virProcessForkCallback cb,
+  void *opaque)
+{
+if (cb(ppid, opaque) < 0) {
+virErrorPtr err = virGetLastError();
+if (err) {
+size_t len = strlen(err->message) + 1;
+ignore_value(safewrite(errfd, err->message, len));
+}
+
+return -1;
+}
+
+return 0;
+}
+
+
+/**
+ * virProcessRunInFork:
+ * @cb: callback to run
+ * @opaque: opaque data to @cb
+ *
+ * Do the fork and run @cb in the child. This can be used when
+ * @cb does something thread unsafe, for instance.  All signals
+ * will be reset to have their platform default handlers and
+ * unmasked. @cb must only use async signal safe functions. In
+ * particular no mutexes should be used in @cb, unless steps were
+ * taken before forking to guarantee a predictable state. @cb
+ * must not exec any external binaries, instead
+ * virCommand/virExec should be used for that purpose.
+ *
+ * On return, the returned value is either -1 with error message
+ * reported if something went bad in the parent, if child has
+ * died from a signal or if the child returned EXIT_CANCELED.
+ * Otherwise the returned value is the exit status of the child.
+ */
+int
+virProcessRunInFork(virProcessForkCallback cb,
+void *opaque)
+{
+int ret = -1;
+pid_t child = -1;
+pid_t parent = getpid();
+int errfd[2] = { -1, -1 };
+
+if (pipe2(errfd, O_CLOEXEC) < 0) {
+virReportSystemError(errno, "%s",
+ _("Cannot create pipe for child"));
+return -1;
+}
+
+if ((child = virFork()) < 0)
+goto cleanup;
+
+if (child == 0) {
+VIR_FORCE_CLOSE(errfd[0]);
+ret = virProcessRunInForkHelper(errfd[1], parent, cb, opaque);
+VIR_FORCE_CLOSE(errfd[1]);
+_exit(ret < 0 ? EXIT_CANCELED : ret);
+} else {
+int status;
+VIR_AUTOFREE(char *) buf = NULL;
+
+VIR_FORCE_CLOSE(errfd[1]);
+ignore_value(virFileReadHeaderFD(errfd[0], 1024, ));
+ret = virProcessWait(child, , false);
+if (ret == 0) {
+ret = status == EXIT_CANCELED ? -1 : status;
+if (ret) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("child reported (status=%d): %s"),
+   status, NULLSTR(buf));
+}
+}
+}
+
+ cleanup:
+VIR_FORCE_CLOSE(errfd[0]);
+VIR_FORCE_CLOSE(errfd[1]);
+return ret;
+}
+
+
 #if defined(HAVE_SYS_MOUNT_H) && defined(HAVE_UNSHARE)
 int
 virProcessSetupPrivateMountNS(void)
diff --git a/src/util/virprocess.h b/src/util/virprocess.h
index 5faa0892fe..b1166902f0 100644
--- a/src/util/virprocess.h
+++ b/src/util/virprocess.h
@@ -93,6 +93,22 @@ int virProcessRunInMountNamespace(pid_t pid,
   virProcessNamespaceCallback cb,
   void *opaque);
 
+/**
+ * virProcessForkCallback:
+ * @ppid: parent's pid
+ * @opaque: opaque data
+ *
+ * Callback to run in fork()-ed process.
+ *
+ * Returns: 0 on success,
+ * -1 on error (treated as EXIT_CANCELED)
+ */
+typedef int (*virProcessForkCallback)(pid_t ppid,
+  void *opaque);
+
+int virProcessRunInFork(virProcessForkCallback cb,
+void *opaque);
+
 int virProcessSetupPrivateMountNS(void);
 
 int virProcessSetScheduler(pid_t pid,
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 04/15] qemu_domain: Track if domain remembers original owner

2018-11-14 Thread Michal Privoznik

For metadata locking we might need an extra fork() which given
latest attempts to do fewer fork()-s is suboptimal. Therefore,
there will be a qemu.conf knob to enable or this feature. But
since the feature is actually not metadata locking itself rather
than remembering of the original owner of the file this is named
as 'rememberOwner'. But patches for that feature are not even
posted yet so there is actually no qemu.conf entry in this patch
nor a way to enable this feature.

Even though this is effectively a dead code for now it is still
desired.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_conf.h| 1 +
 src/qemu/qemu_domain.c  | 7 +++
 src/qemu/qemu_domain.h  | 3 +++
 src/qemu/qemu_process.c | 3 +++
 4 files changed, 14 insertions(+)

diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index f876f9117c..0b5b5a314f 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -92,6 +92,7 @@ struct _virQEMUDriverConfig {
 bool dynamicOwnership;
 
 virBitmapPtr namespaces;
+bool rememberOwner;
 
 int cgroupControllers;
 char **cgroupDeviceACL;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 37926850b2..558c97ad36 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1963,6 +1963,8 @@ qemuDomainObjPrivateDataClear(qemuDomainObjPrivatePtr 
priv)
 virBitmapFree(priv->namespaces);
 priv->namespaces = NULL;
 
+priv->rememberOwner = false;
+
 priv->reconnectBlockjobs = VIR_TRISTATE_BOOL_ABSENT;
 priv->allowReboot = VIR_TRISTATE_BOOL_ABSENT;
 
@@ -2480,6 +2482,9 @@ qemuDomainObjPrivateXMLFormat(virBufferPtr buf,
 if (priv->chardevStdioLogd)
 virBufferAddLit(buf, "\n");
 
+if (priv->rememberOwner)
+virBufferAddLit(buf, "\n");
+
 qemuDomainObjPrivateXMLFormatAllowReboot(buf, priv->allowReboot);
 
 qemuDomainObjPrivateXMLFormatPR(buf, priv);
@@ -2891,6 +2896,8 @@ qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt,
 priv->namespaces = NULL;
 }
 
+priv->rememberOwner = virXPathBoolean("count(./rememberOwner) > 0", ctxt);
+
 if ((n = virXPathNodeSet("./vcpus/vcpu", ctxt, )) < 0)
 goto error;
 
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index 87de433b22..53b5ea1678 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -369,6 +369,9 @@ struct _qemuDomainObjPrivate {
 /* qemuProcessStartCPUs stores the reason for starting vCPUs here for the
  * RESUME event handler to use it */
 virDomainRunningReason runningReason;
+
+/* true if libvirt remembers the original owner for files */
+bool rememberOwner;
 };
 
 # define QEMU_DOMAIN_PRIVATE(vm) \
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 2c9e605047..44bf55bfb2 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5916,6 +5916,9 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver,
 priv->chardevStdioLogd = true;
 }
 
+/* Track if this domain remembers original owner */
+priv->rememberOwner = cfg->rememberOwner;
+
 qemuProcessPrepareAllowReboot(vm);
 
 /* clear the 'blockdev' capability for VMs which have disks that need
-- 
2.18.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] conf: qemu: support new Hyper-V enlightenments in Qemu-3.1

2018-11-14 Thread John Ferlan

On 11/14/18 4:04 AM, Andrea Bolognani wrote:
> On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
>> The upcoming Qemu-3.1 release will bring us two new Hyper-V enlightenments:
>> hv_ipi and hv_evmcs. Support these in libvirt.
>>
>> Vitaly Kuznetsov (2):
>>   conf: qemu: add support for Hyper-V PV IPIs
>>   conf: qemu: add support for Hyper-V Enlightened VMCS
> 
> I have pointed out a few very minor issues with the patches, as
> well as a couple areas where pre-existing issues could be fixed,
> although I don't consider the latter a requirement for merging
> the series ;)
> 
> One thing that I would like to see, though, is the change being
> documented properly in the release notes (docs/news.xml). Please
> include that and respin.
> 

One other thing that I've really tried to see done is splitting the
"conf" and "qemu" patches.

That way one deals with conf, docs, conf, util, xml2xmltest, while the
other deals with the qemu specific changes qemu, xml2argv.

Sometimes it's "harder" to do that - such as may be the case with
various switches when a new case is added; however, in that case the
added case in the conf/docs/etc patch would go with the "default:" or
"last" case and then be moved with the subsequent qemu patch.

Tks,

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] conf: qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 11:13 +0100, Vitaly Kuznetsov wrote:
> Andrea Bolognani  writes:
> ...
> > > +  4.10.0 (QEMU 3.1)
> > 
> > Again pre-existing: what does the first version number refer to? It
> > would be nice to have it spelled out.
> 
> My understanding is that this is libvirt version. We can, of course,
> spell it out but:
> 
> $ git grep -c 'class="since"' docs/formatdomain.html.in  
> docs/formatdomain.html.in:400
> 
> $ git grep -c 'class="since".*libvirt' docs/formatdomain.html.in  
> docs/formatdomain.html.in:10
> 
> Do you want a patch changing the remaining 390 entries? :-)

Of course it is! Not sure why I got confused in the first place :/

Never mind then, just address the remaining points and respin.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] conf: qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Vitaly Kuznetsov

Andrea Bolognani  writes:

...
>
>> +  4.10.0 (QEMU 3.1)
>
> Again pre-existing: what does the first version number refer to? It
> would be nice to have it spelled out.
>

My understanding is that this is libvirt version. We can, of course,
spell it out but:

$ git grep -c 'class="since"' docs/formatdomain.html.in  
docs/formatdomain.html.in:400

$ git grep -c 'class="since".*libvirt' docs/formatdomain.html.in  
docs/formatdomain.html.in:10

Do you want a patch changing the remaining 390 entries? :-)

(Thanks for the review btw!)

-- 
Vitaly

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC 1/3] qemu: Add check for whether nesting was enabled

2018-11-14 Thread Marc Hartmayer

On Tue, Nov 13, 2018 at 09:21 PM +0100, John Ferlan  wrote:
> Support for nested kvm is handled via a kernel module configuration
> adjustment which if done after libvirtd is started and/or the last
> QEMU capabilities adjustment can result in the inability to start a
> guest and use nested kvm until the capabilities cache is invalidated.
>
> Thus, let's fetch and save the setting during initialization and then
> when the capabilities are checked for various host related adjustments
> that could affect whether the capabilities cache is updated add a check
> whether the nested value was set for either kvm_intel or kvm_amd to
> force a refetch of the capabilities.
>
> Signed-off-by: John Ferlan 
> ---
>  src/qemu/qemu_capabilities.c | 43 
>  src/qemu/qemu_capspriv.h |  2 ++
>  tests/qemucapabilitiestest.c |  3 +++
>  3 files changed, 48 insertions(+)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 2ca5af3297..ebe0c0c7df 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -40,6 +40,7 @@
>  #include "virnodesuspend.h"
>  #include "virnuma.h"
>  #include "virhostcpu.h"
> +#include "virkmod.h"
>  #include "qemu_monitor.h"
>  #include "virstring.h"
>  #include "qemu_hostdev.h"
> @@ -551,6 +552,7 @@ struct _virQEMUCaps {
>  virObject parent;
>
>  bool usedQMP;
> +bool isNested;
>
>  char *binary;
>  time_t ctime;
> @@ -1512,6 +1514,7 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
> qemuCaps)
>  return NULL;
>
>  ret->usedQMP = qemuCaps->usedQMP;
> +ret->isNested = qemuCaps->isNested;
>
>  if (VIR_STRDUP(ret->binary, qemuCaps->binary) < 0)
>  goto error;
> @@ -3567,6 +3570,9 @@ virQEMUCapsLoadCache(virArch hostArch,
>  virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
>  virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
>
> +qemuCaps->isNested = virXPathBoolean("count(./isNested) > 0",
> + ctxt) > 0;
> +
>  ret = 0;
>   cleanup:
>  VIR_FREE(str);
> @@ -3786,6 +3792,9 @@ virQEMUCapsFormatCache(virQEMUCapsPtr qemuCaps)
>  if (qemuCaps->sevCapabilities)
>  virQEMUCapsFormatSEVInfo(qemuCaps, );
>
> +if (qemuCaps->isNested)
> +virBufferAddLit(, "\n");
> +
>  virBufferAdjustIndent(, -2);
>  virBufferAddLit(, "\n");
>
> @@ -3826,6 +3835,28 @@ virQEMUCapsSaveFile(void *data,
>  }
>
>
> +static bool
> +virQEMUCapsIsNested(void)

Not sure if “isNested” is the best wording… Since we’re talking about
nested KVM support here.

> +{
> +VIR_AUTOFREE(char *) kConfig = NULL;
> +
> +if ((kConfig = virKModConfig()) &&
> +(strstr(kConfig, "kvm_intel nested=1") ||
> + strstr(kConfig, "kvm_amd nested=1")))

Please add a check for "kvm nested=1" here since this is used by s390x :)

> +return true;
> +return false;
> +}
> +
> +
> +void
> +virQEMUCapsClearIsNested(virQEMUCapsPtr qemuCaps)
> +{
> +/* For qemucapabilitiestest to avoid printing the  on
> + * hosts with nested set in the kernel */
> +qemuCaps->isNested = false;
> +}
> +
> +
>  static bool
>  virQEMUCapsIsValid(void *data,
> void *privData)
> @@ -3834,6 +3865,7 @@ virQEMUCapsIsValid(void *data,
>  virQEMUCapsCachePrivPtr priv = privData;
>  bool kvmUsable;
>  struct stat sb;
> +bool isNested;
>
>  if (!qemuCaps->binary)
>  return true;
> @@ -3866,6 +3898,15 @@ virQEMUCapsIsValid(void *data,
>  return false;
>  }
>
> +/* Check if someone changed the nested={0|1} value for the kernel from
> + * the previous time we checked. If so, then refresh the capabilities. */
> +isNested = virQEMUCapsIsNested();
> +if (isNested != qemuCaps->isNested) {
> +VIR_WARN("changed kernel nested kvm value was %d", 
> qemuCaps->isNested);
> +qemuCaps->isNested = isNested;
> +return false;
> +}
> +
>  if (!virQEMUCapsGuestIsNative(priv->hostArch, qemuCaps->arch)) {
>  VIR_DEBUG("Guest arch (%s) is not native to host arch (%s), "
>"skipping KVM-related checks",
> @@ -4452,6 +4493,8 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
>  if (virQEMUCapsInitQMPMonitor(qemuCaps, cmd->mon) < 0)
>  goto cleanup;
>
> +qemuCaps->isNested = virQEMUCapsIsNested();
> +
>  if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
>  virQEMUCapsInitQMPCommandAbort(cmd);
>  if ((rc = virQEMUCapsInitQMPCommandRun(cmd, true)) != 0) {
> diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h
> index 8d1a40fe74..b5d6aae2e5 100644
> --- a/src/qemu/qemu_capspriv.h
> +++ b/src/qemu/qemu_capspriv.h
> @@ -48,6 +48,8 @@ int
>  virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
>qemuMonitorPtr mon);
>
> +void virQEMUCapsClearIsNested(virQEMUCapsPtr qemuCaps);
> +
>  int
>

Re: [libvirt] [PATCH 1/2] conf: qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Wed, 2018-11-14 at 10:00 +0100, Andrea Bolognani wrote:
> On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
> > Qemu-3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows
> 
> s/Qemu-3.1/QEMU 3.1/
> 
> [...]
> > +
> > +  ipi
> > +  Enable PV IPI support
> > +   on, off
> 
> s/ on,/on,/
> 
> Everything else looks good.

Oops, these comments were supposed to be for 2/2 instead of 1/2,
of course O:-)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 03/13] security: Always spawn process for transactions

2018-11-14 Thread Daniel P . Berrangé

On Tue, Nov 13, 2018 at 03:52:17PM -0500, John Ferlan wrote:
> [...]
> >>
> >> I understand (generically) why we need the lock. I'm OK with it being
> >> enabled by default. That's not the question/ask. Building in a way to
> >> allow disabling usage of virFork and/or metadata lock knowing the
> >> "penalty" or downside to doing so goes beyond bug free or performance,
> >> it's just that "choice" we allow someone to make. You know there are
> >> those out there that will bemoan "choosing" this is as the default. If
> >> they want to disable in order to gain whatever at the cost of something
> >> else, then so be it. In some ways it's a CYA exercise.
> > 
> > Just an idea that I got, what if there won't be any config knob but this
> > would use namespaces? I mean, if namespaces are on then metadata locking
> > is happening and if they are off then no metadata locking is happening.
> > 
> > Since namespaces do mean extra fork(), doing things this way there won't
> > be any extra fork() if namespaces are off.
> > 
> 
> I'd prefer to not make metadata locking (files) rely on namespaces
> (devices).  I get the relationship though.

In particular the needs for metadata locking applies to all platforms
that libvirt QEMU driver runs on (*BSD, OSX), but namespaces only
work on Linux.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC 0/3] Add mechanisms to force QEMU capabilities refetches

2018-11-14 Thread Daniel P . Berrangé

On Tue, Nov 13, 2018 at 03:21:03PM -0500, John Ferlan wrote:
> Sending as an RFC primarily because I'm looking for whether either
> or both mechanisms in the series is more or less desired. Likewise,
> if it's felt that the current process of telling customers to just
> delete the cache is acceptible, then so be it. If there's other ideas
> I'm willing to give them a go too. I did consider adding a virsh
> option to "virsh capabilities" (still possible) and/or a virt-admin
> option to force the refresh. These just were "easier" and didn't
> require an API adjustment to implement.
> 
> Patch1 is essentially a means to determine if the kernel config
> was changed to allow nested virtualization and to force a refresh
> of the capabilities in that case. Without doing so the CPU settings
> for a guest may not add the vmx=on depending on configuration and
> for the user that doesn't make sense. There is a private bz on this
> so I won't bother posting it.
> 
> Patch2 and Patch3 make use of the 'service libvirtd reload' function
> in order to invalidate all the entries in the internal QEMU capabilities
> hash table and then to force a reread. This perhaps has downsides related
> to guest usage and previous means to use reload and not refresh if a guest
> was running. On the other hand, we tell people to just clear the QEMU
> capabilities cache (e.g. rm /var/cache/libvirt/qemu/capabilities/*.xml)
> and restart libvirtd, so in essence, the same result. It's not clear
> how frequently this is used (it's essentially a SIGHUP to libvirtd).

IMHO the fact that we cache stuff should be completely invisible outside
of libvirt. Sure we've had some bugs in this area, but they are not very
frequent so I'm not enthusiastic to expose any knob to force rebuild beyond
just deleting files.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] conf: qemu: support new Hyper-V enlightenments in Qemu-3.1

2018-11-14 Thread Andrea Bolognani

On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
> The upcoming Qemu-3.1 release will bring us two new Hyper-V enlightenments:
> hv_ipi and hv_evmcs. Support these in libvirt.
> 
> Vitaly Kuznetsov (2):
>   conf: qemu: add support for Hyper-V PV IPIs
>   conf: qemu: add support for Hyper-V Enlightened VMCS

I have pointed out a few very minor issues with the patches, as
well as a couple areas where pre-existing issues could be fixed,
although I don't consider the latter a requirement for merging
the series ;)

One thing that I would like to see, though, is the change being
documented properly in the release notes (docs/news.xml). Please
include that and respin.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] conf: qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
> Qemu-3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows

s/Qemu-3.1/QEMU 3.1/

[...]
> +
> +  ipi
> +  Enable PV IPI support
> +   on, off

s/ on,/on,/

Everything else looks good.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] conf: qemu: add support for Hyper-V PV IPIs

2018-11-14 Thread Andrea Bolognani

On Tue, 2018-11-13 at 18:53 +0100, Vitaly Kuznetsov wrote:
> Qemu-3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows

s/Qemu-3.1/QEMU 3.1/

[...]
> +
> +  ipi
> +  Enable PV IPI support
> +   on, off

No whitespace before "on", please.

Pre-existing: several entires in the section have the same issue,
feel free to fix them (in a separate patch).

> +  4.10.0 (QEMU 3.1)

Again pre-existing: what does the first version number refer to? It
would be nice to have it spelled out.

[...]
> @@ -172,7 +172,8 @@ VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
>"vendor_id",
>"frequencies",
>"reenlightenment",
> -  "tlbflush")
> +  "tlbflush",
> +  "ipi")

Since you're touching this anyway, you can take the opportunity to
rewrite it as

  VIR_ENUM_IMPL(virDomainHyperv, VIR_DOMAIN_HYPERV_LAST,
...
"tlbflush",
"ipi",
  );

so that the next patch and any subsequent ones will look nicer.

[...]
> +KVM_FEATURE_DEF(VIR_CPU_x86_KVM_HV_IPI,
> +0x4004, 0x0400);

I'm going to assume the magic numbers here are correct :)

Everything else looks good.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] build: Fix uninstall when WITH_APPARMOR_PROFILES is defined

2018-11-14 Thread Andrea Bolognani

On Tue, 2018-11-13 at 12:04 -0700, Jim Fehlig wrote:
> On 11/13/18 10:14 AM, Andrea Bolognani wrote:
> > > +uninstall-apparmor-local:
> > > + rm -f "$(APPARMOR_LOCAL_DIR)/usr.lib.libvirt.virt-aa-helper"
> > > + rmdir $(APPARMOR_LOCAL_DIR) || :
> > 
> > Missing quotes here as well. Once you fix that,
> > 
> >Reviewed-by: Andrea Bolognani 
> 
> I've fixed it and pushed. While doing so I noticed a lot of pre-existing lack 
> of 
> quoting throughout the various Makefile.am :-). I'm not sure these are worth 
> fixing given the lack problem reports...

I'd say fixing them is worthwhile, so if you feel like putting time
into doing so I'll very happily review the resulting patches.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] examples: Add missing quotes

2018-11-14 Thread Andrea Bolognani

Signed-off-by: Andrea Bolognani 
---
Pushed as trivial.

 examples/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/Makefile.am b/examples/Makefile.am
index 7069d74e74..8a9c118858 100644
--- a/examples/Makefile.am
+++ b/examples/Makefile.am
@@ -94,7 +94,7 @@ install-apparmor-local:
$(MKDIR_P) "$(APPARMOR_LOCAL_DIR)"
echo "# Site-specific additions and overrides for \
'usr.lib.libvirt.virt-aa-helper'" \
-   >$(APPARMOR_LOCAL_DIR)/usr.lib.libvirt.virt-aa-helper
+   >"$(APPARMOR_LOCAL_DIR)/usr.lib.libvirt.virt-aa-helper"
 
 INSTALL_DATA_LOCAL += install-apparmor-local
 UNINSTALL_LOCAL += uninstall-apparmor-local
-- 
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

93 matches

Mail list logo